in

Ative at Work

Agile software development

Ative at Work

Managing Successful Software Projects

Successful software development is all about managing the development process.

Many projects fail or linger in the "80% completed" phase for years on end.

The root cause is a tradition for measuring status according to the wrong metrics.

"The requirements are complete", "The design phase is 50%" completed and other statements like this tell nothing about how much business value have been delivered. They merely confirm that the bureaucracy is keeping itself busy.

Despite of this many software projects measure their progress in terms of such abstract milestones. The result is predictable and catastrophical.

First of all since status reports do not tell anything about the distance to delivering a software system that provides actual business value, they are the cause of a lot of risk.

What they do is rob the project sponsors of the ability to manage the project. Since they are not measuring what has been delivered but merely the bureaucratic artifacts produces they usually paint a rosy picture until very late in the project when it becomes impossible to hide the fact that the project is suffering.

At this point, however, management has no time and budget left to react. In effect, they have been robbed of their tools of control and forced into a position where they can only accept budget and timeframe overruns or cancel the project.

Therefore, this kind of status reporting should be considered sabotage.

Unfortunately most software projects suffer from too many saboteurs. Not out of ill will but because the traditional best practices are nothing but sabotage.

There is a way out, however:

Measure status in terms of actual, delivered, tested, operational business value.

This is the key metric to success. It is hard to game it since it only measures the actual results, not bureaucratic artifacts from the production process. And since it is aligned with the business the risk exposure of the project is dramatically diminished.

The production process itself has to be aligned with this goal. Therefore we produce software in short iterations - 2-week cycles of specification, production and testing that deliver actual running code into the production environment.

At the end of each iteration the result is in a known good state, the acceptance test - which is automated - confirms that the system is sound and it is ready to deploy to production.

Doing this requires a disciplined team but the result is immediate. Reliable status, early warnings of deviations from the original plans and the ability to react with due diligence.

When we founded Ative we pledged to put an end to working stupidly. We pledged to do our best to create better software, faster.

If you would like to join us give us a shout.

Comments

 

ploeh said:

Heh, if you ask a developer how he's doing, he's always 90 percent done :)

This isn't even from ill will, but simply because developers tend to focus on the features they've created, and not the bugs they've introduced. The fact that they are deeply immersed in their own code doesn't help them make accurate estimates.

As you wrote, the only way to measure progress is by (automated) testing. Visual Studio Team Suite (particularly Team Foundation Server) provides good tools for this ;)

september 19, 2006 11:16
 

Søren Lindstrøm said:

It is a false statement that an agile project require an especially disiplined/skilled group of developers to succeed. This is the case no matter which methodology your project uses. However in agile projects it is just so painstakingly obvious that your development team is of insuficient quality.

Poor developer quality, is unfortunately an ailment that has plagued our business for too long.  

oktober 4, 2006 11:19
© Ative Consulting ApS