Posts Tagged “project recovery”

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.

Comments No Comments »

I’ve done enough recovery projects over the years that many patterns are easy to spot. One that I had overlooked — but has really come home to roost this time around — is what to do at the very start. My epiphany of the week (yes, I try to have an epiphany every week) is that every recovery project I have taken on would have benefited from applying the same four steps.

Step One: Assess the Team’s Current Capabilities

I’ve never met a team in a recovery setting that was not dysfunctional in some fundamental way. It doesn’t matter whether the team’s dysfunction caused the project to veer off course or whether external forces ran the project off course, thrusting the team into dysfunction. The end result is the same.

Perhaps the fact that only one person knows the domain is bottlenecking the performance of the rest of the team. Perhaps the team’s skills are not a fit for the technology. Perhaps the team leads are new to their roles and do not know how to manage process and lead people. Perhaps there are a few bad apples on the team. Perhaps morale is shot, causing good apples to exhibit bad apple behaviors. Perhaps team members are exhaustively satisfying PMO and SDLC documentation requirements that do nothing to contribute to delivery. Perhaps improper communication practices are causing excessive rework. Perhaps inadequate programming discipline has created a vast quagmire of bugs. In the end, all these dysfunctions lead to the same output: waste in place of delivery.

Ultimately, the first things to be done are (1) gauge at what percent of full capacity the team is actually delivering and (2) asses the causes for the team’s reduced delivery. And don’t be surprised if the team’s actual current delivery is less than fifty percent of its true capability.

Step Two: Make Management Understand the Real Problem

Too often I’ve seen management start a recovery initiative by feverishly asking for a complete sizing of the project and a revised delivery date. What management doesn’t understand is that they’ve got bigger problems. Re-estimating and re-planning the project will do nothing to recover the broken team. The true state of the team needs to be made clear to management. If a ten person team is delivering at half capacity (due to any number of reasons listed above) then management needs to understand that they are hemorrhaging around twenty thousand dollars a week.

This math (and a few BP Oil Cam pics) should go a long way to getting management to let you focus on recovering the team. You will, of course, have to make some commitment about getting back to release-level estimation planning after you’ve made progress with the team.

Step Three: Help the Team

Identify an obtainable delivery goal no more than a month or two out (nearer is better). Draft just enough process for the team to use to complete this goal. This process should be a set of agile practices that are adapted to fit the environment and personalities of the team. Simplicity is  key. You won’t have a lot of time for this and the only thing that you will know for certain is that the draft process will break. But simple things are easier to fix.

Set the team on short iterations of one or two weeks toward its obtainable goal. You’ll need the short iterations to gauge whether the team is improving at delivery and to gain feedback on both people and process. Make sure the team’s path is clear of obstacles and external dependencies. The team members need to feel that they are in a place of relative security, where their efforts make a measurable difference and their ideas and opinions contribute to the overall process and health of the team.

Watch where improvements can be made, through coaching people or flexing process. Identify the larger issues that need management attention to resolve (such as moving staff on or off the team) and make sure these get done.

Ultimately, the team needs assistance working itself into a sustainable delivery process. You’re in a good place when the team is delivering at or above seventy-five percent capacity.

Step Four: Make Management Happy

Make sure management recognizes the improved performance of the team, and that this was done by the team (rather than to the team). Shining some positive light back on the team will start to heal the bruised relationship between the team and management. That relationship (and its well-being) will become increasingly important in the weeks and months to come.

And now it is the time to get back to whatever goals and timelines management had set for the project. This will be no less challenging than the activities above, so buckle up. But at least it can now be done without the sense that Rome is burning while management is fiddling.

Comments No Comments »