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.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview