The Real Benefit of Agile

| Comments | featured, technical

Agile vs. Prince2 by Matthew Hutchinson
Agile vs. Prince2 by Matthew Hutchinson

What is the point of doing agile development? We’re told that we will be more efficient, higher quality software that matches what the user wants, but is that really the best reason to do it?

I think that well executed “traditional waterfall” project management can also achieve the above aims. So what is the point of agile techniques and why do I continue to drink the agile kool-aid?

For me there are two reasons for doing agile.

Doing agile badly is cheaper than doing waterfall badly

Given that very few of us are exemplary, and it’s even less likely that everyone on your team is exemplary, then you should probably not consider that your chosen methodology is better when perfectly executed, but consider what it’s like when it’s executed by stressed people under a deadline.

When waterfall is put under pressure, requirements get missed, quality and development practices reduce and you get a war between the dates the project manager promised and the actual capability of the team to deliver.

That results in a low quality product, shipped late and often in desperate need to remedial work, but too badly put together to enable easy fixes.

What happens when agile teams rush? They tend to execute on badly thought through stories, they also reduce quality (it’s a natural instinct of a rushed developer in my experience), but the primary thing that suffers is the scope. Given even half-arsed product management, there was some scoping and prioritisation of the stories, and the product that comes out doesn’t deliver all the features that was originally promised.

Since agile teams deliver the product builds more often, they are far more likely to deliver half a product instead of overrunning to deliver all the features.

Because it’s more visible that things are going wrong (and you know you have the first half of the product) it should be easier for program managers to kill the project earlier. Killing a waterfall project early results in no output for the money spent, a decision that most program managers who have career aspirations just can’t make.

Change is built in

To me, the main benefit of doing agile is that it embeds the concept of change into the team and the project. All agile methodologies encourage incremental delivery of the product.

That means that your team will need to think about:

  • Writing code they can come back and change 2 weeks later
  • Releasing the software repeatedly (not just once)
  • Communicating changes to the user
  • Accepting a minimally viable feature set / You Aint Gonna Need It mentality

Because change is embedded into the entire process, it becomes a natural part of the teams thought processes, and that means that once the product is delivered, deciding to remedial work tends to be easier.

Comments