In my post a few weeks back on How to Start the Next Recovery Project I asserted that I will take the following four steps the next time I take on a recovery project:

  1. Assess the Team’s Current Capabilities
  2. Make Management Understand the Real Problem
  3. Help the Team
  4. Make Management Happy

Additionally, for anyone who needs the extra background, an Iteration Zero is a featureless iteration (or sprint) executed at the beginning of the project that lets the team focus on building out both its development infrastructure and its planning and management method.

An Iteration Zero may be used quite effectively to bootstrap a recovery activity without freaking out upper management by calling a project-wide time out. Depending on the state of the team, there’s two different places you could insert an iteration zero. Either right in the beginning of the recovery action, or after you’ve gotten management to understand where the problems lie.

In order to be successful the early option requires a willing team that has some knowledge of agile processes AND is functional enough to identify and run toward a meaningful set of timeboxed goals WITHOUT getting getting bogged down in the type of infighting, backbiting and recrimination that can be common on broken projects. The later option can be deployed in most circumstances and, since you’ve already taken the time to assess the team, you can set expectations with management as to realistic outputs from the activity.

In either case there are many valuable goals you can hope to achieve when deploying an Iteration Zero in a project recovery setting. Here’s five of the most valuable:

  • Scope, estimate, and story out a near term release. This is almost always the first activity you should consider when staging an Iteration Zero. The typical broken project has yet to deliver anything useful to end users (regardless of what they may have built thus far). The best way to break a deployment dry spell is to lock in an obtainable goal and deliver on it.
  • Help your business users. Often it’s not simply the team that’s flailing. The business people (represented by the customer or product owner) are likely also struggling. They may need help with the agile process, their own business domain, or something entirely different. An iteration Zero provides the perfect opportunity to recognize the business’ need for assistance and to make it happen.
  • Pay down high-value (or high risk) technical debt. While it might not seem obvious to focus on something other than high business value, there are two potential benefits of taking the time to pay down some technical debt. First, there are pieces of technical debt that can, in the near term, cost more to ignore than they will cost to fix. Focusing on these, then ADDS to business value. Second, by paying attention to technical debt (and thereby listening to the team that is screaming about technical debt rising at a pace faster than the national debt) you contribute to team morale. And this matters! Team morale is often shot at the beginning of a recovery project and you are going to need as much of it as you can get if you intend to pull the recovery off.
  • Nail down your integration and migration environments and processes. This is often another area where broken teams are suffering, if for no other reason than neglect as the team has rushed ever faster to keep up. Like high-value technical debt, investing in integration and migration (and automated testing) can pay back huge dividends both in near-term business value and in team morale.
  • Recruit and on-board new team members. You may need additional people (or replacement people) on the team for various reason. An Iteration Zero is a comparatively low-stress period during which people can take the time to screen and interview candidates or train and acclimate fresh recruits.

An Iteration Zero won’t solve all you project recovery problems. In fact, it’s only the beginning of the solution. But it’s a new beginning, without pulling the team to a complete halt and without calling a due-over. In the high-pressure environment of project recovery, it’s often critical to start again without starting over.

Leave a Reply

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