Avoid Death Marches
Death marches, the end of the project when people work too much overtime, try to finish everything so they can get to a release, are still with us. It doesn't matter if you're trying to use agile or not, you may still have a death march.
One of the big problems when people transition to agile is the issue of how long to make an iteration, how to estimate what goes into the iteration, and how to finish what the team thought they could do in an iteration.
Some teams don't estimate their iteration backlogs that well, so they have more features to finish before the end of the iteration. In order to finish the iteration and everything they committed to, they start death march mode: work too many hours, shortcut testing, avoid asking for review, anything to make sure the iteration is done on time with all the content.
That's not a good idea. I don't know of a time when a death march is a good idea, but I don't know your project. Maybe you have that one exception to the rule.
For the rest of us, who want to avoid death marches, here are some ideas to avoiding death marches at the end of an iteration:
- Do a retrospective at the end of this iteration. Make sure you do some root cause analysis about why the team committed to more than they could complete. Once you know the root cause, you can start to manage the problem.
- If you are missing any tools, such as fast-enough builds or automated smoke tests, this is the time to influence the product owner or customer to put that work on the backlog for the next iteration.
- If you can't get that work on the backlog, increase your estimates for the remaining work. The work takes longer than you thought it would. Fine. Admit it, and re-estimate what you can do in an iteration.
- Consider reducing the size of your iterations. If you are using four week iterations, start with a two-week iteration. If nothing else, the shorter timebox will make the obstacles more obvious.
For those of you not working in an agile way, look at your project. Do you have a death march now or are you headed for one? If so, try these ideas:
- Consider timeboxing all work. You don't have to get to “done” as you do in an agile project in the timebox. The timebox provides focus and urgency to the team, which is what you need if you are in a death march. Sometimes, death marches are caused by too much work in progress, so asking people to focus on one thing for a week or two and do as much as they can on just that one piece helps them finish work.
- Ask the team members to ask for review on all their work. Code review, design review, test review–all these peer reviews help people see what they are not doing. I particularly like the “Come over here, Tim, and tell me what I'm doing wrong” review. As soon as I start explaining what I'm doing, I see my problem. And, when I miss the problem, Tim sees it.
- Make sure everyone is on this project and just this project. Sometimes, projects become death marches because everyone is so busy servicing other requests, they don't work on this project.
- Wherever possible, finish and test features. Do not code or test from the architecture–start with the features. And, start with the features that people use most often.
Death marches are terrible for any project team. Avoid them. If you discover you are in a death march, act to stop it now–maybe with a retrospective, timeboxing, root cause analysis. Don't keep doing what you are doing, continuing the death march. All you'll get is even more tired people. Tired people make mistakes, and a late project can't afford any of those.
Join the Teleseminar Series, Prevent Your Agile Titanic
Death marches at the end of iterations are only one of the problems many people encounter in their transition to agile. Other issues are technical debt, lack of a product owner, or management assuming they can ask you for a Gantt Chart every iteration. All of these issues lead to trouble installing agile.
The first 3-6 months of Agile adoption are the riskiest. There's so much to do that's different from what you normally do and so much to watch out for. Which battles do you pick? How do you get the team to play well together? And why does it seem to work well for others and not for you?
We have a solution to this problem, and it's based on more than 10 combined years of experience. These issues of installing agile are what Gil Broza and I are addressing in a series of teleclasses called Prevent Your Agile Titanic. If you are installing agile in your organization and want to prevent your maiden voyage ending up like the Titanic, please join us.
The teleseries starts Feb 8, 2010. Please joinus.
Group Coaching for Managers and Project Managers
Several people have emailed me looking for group coaching about management and project management issues. If this is interesting to you, email me.
If you're a new subscriber, you may not have read all the back issues. Start here.
I keep my blogs current with my writings:
Johanna
© 2010 Johanna Rothman
|