Thursday, June 17, 2010

Filling an iteration too well

I want to stick with the theme of “how do I fill an iteration?” for a couple more entries. There are a lot of little nuances here, and what works for one team at one time might not be the best thing for another team, or even the same team at a different time.

I appreciated Ed’s comments on my last entry, I think they go to show how small variations work well for individual teams. However, sometimes variations hold problems.

Sometimes you come across a team that completes exactly the amount of work (measured in abstract points) during an iteration as they forecast they would at the start. For example: a team says it will do 10 points of work in the next iteration, and two weeks later they count up and they did 10 points of work.

Occasionally this happens, thats not unusual. Over time I’d expect it to happen more often but I don’t expect it to happen every iteration. When it does then something is probably wrong.

Statistically this is just very unlikely to happen. Yes a team will do roughly the same amount of work but exactly No. They are not doing the same work, the same tasks, the same events will not occur, the same people won’t work on the same things - and if they did we would expect them to get more done.

So when a team regularly scores the same points, week after week, as they expect to (and by implication the same number they did the previous iteration) then some force is making it happen. The real number should be higher or lower.

If the real number should be lower it means the team is busting a gut to do the work. Maybe they are working long hours, or maybe they are cutting on quality. Either way the work pace is unsustainable and problems are being stored up.

If the real number should be higher it means the team is satisficing. That is, they have the capacity to do more work but they are not taking it on so there is spare capacity. Sustainable yes, but not as productive as they could be.

I recently worked with a team led by a manager who would not allow the team to take on more work than they could guarantee doing. He did this because he didn’t want to explain to the project manager running the project that the team hadn’t done as much as they had scheduled.

The project managers in this company wanted predictability. If that is important to you then that’s a reasonable thing to do. But this company was trying to “go faster”. The managers were making a trade off: less work for more consistency week-on-week.

My preferred method is to always schedule slightly more work than the team expects to do. This way there is more work to do if the team find things go well. And if they don’t go well, or if they go badly, then nobody should have been expecting everything to get done anyway.

No comments:

Post a Comment