Most of us have had to move ourselves at least once in our lives. We think we have it all planned out, but the true test is when the movers show up (or your friends who were lucky enough to show up and provide free labour). I got to be one of the lucky ones this weekend and I couldn’t help noticing that everything was running exactly like a new team trying to work in an agile development process.

Then again, maybe I’m just starting to see sprints everywhere and need to take  a break from scrum. 🙂

In any case, this move had it all: impediments, timeboxed delivery, unknown backlog size, and a new group working together to determine their velocity.

Why wasn’t everything ready before we showed up?

I missed the beginning of the move, but even then not everything had been packed up yet. Like most developers joining an iteration, I was annoyed that the backlog was not fully complete and ready. The ‘product owner’ in this case was madly getting things into boxes and bags as folks were tackling whatever had already been completed.

Sound familiar?

Even though we don’t want to do all the backlog work ahead of time, it is human nature to expect that things will be ready for the execution team at the point of execution. Even if you have super-hero capabilities and can keep up with the execution team, during the retrospective, you’ll probably hear from the team that things weren’t “ready enough”. For this reason, always make sure that you have your sprint backlog  defined and ready (or your boxes packed) before the team begins to execute the sprint.

Who has the keys? And where’s the elevator?

It’s one thing to look at what has to be done and start carrying boxes and beds and couches. It all has to go somewhere though. We had the fun situation where the building manager decided not to provide my friends with keys to their new apartment on moving day and forgot to set the elevator to service mode. A few workarounds later, we had the ability to start moving things in, but the experience was already damaged by the impediments.

During your pre-execution sprint (Sprint Zero) the team needs to work out things like access credentials, infrastructure procurement, and other finer details that will be in your way once it comes time to execute. Nothing is more annoying to a developer than being told “please build this functionality and deploy to our servers and source repository. Account access? No, we didn’t make you accounts. Can’t you just push it through the cloud?”

*shudder*

Who is doing what?

When folks show up to help with a move they each bring different capabilities to the team. Sure, everybody can lift something, but some folks have the experience and have executed dozens of moves. Some folks are stronger, while others have bad backs.  And some folks are 8 years old and want to enjoy pushing the elevator buttons and carrying a bongo.

Yes, that happened.

Your ‘cross-functional’ team has specialties with a few folks who have enough experience to do almost any of the jobs required. The team needs to be able to identify these capabilities and take on tasks appropriately.  However, if the group doesn’t know each other well enough it is going to take a little bit of time to optimize the efficiency of the team.

The rest of the group needs to identify specialty knowledge and put it to use. If somebody knows what the layout of the new apartment should be, they should be directing incoming movers to the appropriate destinations. If somebody knows what is breakable, they should be writing “FRAGILE” on all the appropriate boxes. If somebody knows the correct way to back up a moving truck into an ill-designed laneway, they should get behind the wheel. Self-organizing is a great place to start.

How are we going to finish on time?

I needed to be gone by noon because I had an afternoon appointment, as did another one of the group who was helping with the move. We now had a hard and fixed deadline to this endeavour that had to be met for the majority of the work. A time piece was helpful for us to know how much time we had left, but how would we know if we were tracking to complete on time? As time dwindled down, stress levels went up as we realized how much we had to do in the remaining time. We started refining our process to maximize efficient use of the service elevator. We began delegating certain folks to specific tasks to reduce waiting time for execution.

Sound like the last 3 days of your two-week development sprint?

If you look at any Scrum burndown chart, you will usually see the same thing: average execution at the beginning, some refinements in the middle that cause a deviation in performance, and then a sudden increase in output to complete the remaining tasks at the end. We are human and there is nothing like a deadline to make us more efficient! Just like with sprint retrospectives, we are meeting daily and trying to adjust what we are doing to optimize delivery. Over the course of the release, we will refine even more to bring us to a high performance state.

The key here is to measure. With a move, we can measure visually by seeing what is remaining to be done and how much time we have. As we move, we learn how fast our team can transport a certain amount of cargo and the team begins to get a sense of how much time it will take to do the rest of the work. If it seems like the work won’t be done on time, we need to adjust what we are doing as a team in order to move more efficiently. Our agile development teams need to do the same 4 things:

1. Determine time box/deadline
2. Measure velocity
3. Forecast completion
4. Revise processes to optimize execution

That was the fun I had this weekend. What about you? Anything you’ve done in a move that you could translate to development?