Agile: Death March

Agile in my view, when used correctly empowers a development team to create great software that delivery solution to solve business problems. Unfortunately, when management start playing with agile in the belief that they know better, things begin to go down a slippery slope.

A common problem with management is that they fail to understand the dynamics of the development team, and the advantages that agile bring to the team. Often the development team is viewed as simple a cookie cutting factory where ambiguous, poorly written stories will somehow generate sensible business solutions with zero defects.

Management can often be confused by ideal engineering days, and story points. Sometimes this can lead to management being poorly educated. In others its simple that management don’t want to be educated, believing they know best, and that a carrot-stick incentive scheme will prevail.

For agile to work, management have to trust the development team. Management need to respect the team, and empower them to deliver the solution at a speed that satisfies the business, but also doesn’t impact quality and creativeness. If two developers estimate a story and come to a consensus on the pointage, then management should accept the pointage unless they are prepared to develop the solution themselves. If the developer codes the solution quicker than originally estimated, they’re not going to sit idle, go to the beach or take the rest of the day off!

Velocity is an important metric that should be calculated and used usefully. Management needs to understand the usefulness of velocity in running a team’s iterations.

Planning games are important on any project - not just an agile project. If they team doesn’t understand what they have to deliver, what the aim is for the next iteration, and how the jigsaw pieces will fit, there is little hope of a well crafted user experience application. The delivery team needs time to understand the stories for an iteration, to understand the implications of developing the story, and to ask the product owner questions. Without this agile will be doomed to failure.

I believe that pragmatic agile works best. Retrospectives (as I’ve blogged about previous) are essential. If management starts to call the shots on how agile is implemented and run, the development team will incur painful days, weeks and months. Management should respect the development team, as much as the development team should respect management. A partnership should be formed, and both parties should aim to deliver a business solution - collectively.

I remember years ago when I worked for a British investment bank, the team I was working on were delivering an ASP solution. At Christmas we were all given a copy of Death March - quite fitting as the bank was selling most of its equities operations, and hence most project had turned into death march’s in various degrees.

It’s curious to see that in Wikipedia, Death March is defined as “Usually it is a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often includes lack of appropriate documentation”. An agile project that “asking team members to work especially grueling hours, weekends” is in my view an agile project that has turned into agile death!

~ by mdavey on May 21, 2008.