I’ve seen quite a few teams (and not just newbie teams) grapple with this problem. The team has come up a bit short on available effort and can’t hit the release date at the end of the iteration. Just another day will do it, really. Extending your iteration a day to hit the release is a very tempting idea, but it is the very last thing you want to do. That decision simply leads the team down a road of pain. I forgot that lessen a couple months back and allowed a team to travel that road. It went something like this:

Friday the 5th

Advocate for the extension: “We’re just a little too tight this iteration. If we move the retro and planning meeting from Tuesday morning to Tuesday afternoon then we can release in the morning and hit our iteration goal.”

Me: “Okay, is there anything we can take out of the iteration backlog so that the team can still deploy on Monday?”

Advocate for the extension: “No. Everything has to go in.”

In retrospect, that statement should have set off alarm bells, but I had been stretched too far over too many responsibilities and had begun to ignore alarm bells since I was hearing them everywhere. (As discussed in an earlier post, I was thrashing.)

Me: “And the team really believes all they need is this extra few hours to be able to release Tuesday morning?”

Advocate for the extension: “Yes. Definitely.”

I must have been deaf to have not heard the alarm bells here. How much difference are a few hours really going to make in a two-week iteration?

Me: “Well … okay.”

Monday Morning the 8th

Advocate for the extension: “We didn’t get as much done on Friday as we thought we would and we are still not in QA. Can we move the planning meeting from Tuesday to Wednesday?”

Me: “How much time do you really need?”

Advocate for the extension: “A day, really. Just one more day.”

Me: “What does the iteration burndown chart say?”

I was beginning to cop on. We should have looked at the metrics in the first place to see if they lined up with the team’s gut feel.

Advocate for the extension: “We haven’t been updating our tasks. We’ve been too busy trying to complete the work for the release.”

Okay. We’re lost in the woods and it’s cold so we are going to burn the map in order to warm our hands for two minutes. I get it.

Me: You’ll really have the work done and be able to release on Wednesday?

Advocate for the extension: “Yes.”

Me: “Okay.”

Tuesday the 9th

Advocate for the extension: “We didn’t get as much done on Monday as we thought we would … “

The team finally deployed the release Thursday evening.  In the end they moved that planning meeting four times. It took half an hour for the project manager to schedule the meeting on Friday morning because there were no rooms available and many people had other meetings. The team was worn out from a week of frantically trying hit the release. The Friday morning planning meeting went off like a collective hangover.

There are lots of other options to deal with a slipping release that incur less risk than the extend-the-iteration strategy. These options include:

  1. Drop enough work out of the iteration so you can still make the release (this is the typical agile approach).
  2. Complete the iteration with a demo instead of a release and deliver the demoed functionality at the end of the next iteration.
  3. Complete the iteration with a demo instead of a release and plan two releases in the next iteration (one at the beginning to release the functionality from the previous iteration and one at the end for the work completed in that iteration).
  4. Complete the iteration with a demo (assuming there is enough accomplished to demo) and plan the next iteration as a short iteration focused solely on completing and releasing the work from the previous iteration).
  5. Terminate the iteration early and plan a new iteration with a reasonable set of work and feasible end date (another common agile approach).

All these options force the team to asses the amount of work remaining in the release and confirm that they have adequate capacity to complete that work within a set period of time. This is exactly what does not happen when the team decides to slip the iteration end date. In this scenario, too often, the team simply stops tracking progress and simply steps on the gas–fast as they can go. Well intentioned, yes. But we all know what the proverbial road to hell is paved with.

Leave a Reply

To prove that you're not a bot, enter this code
Anti-Spam Image