What is agile?

There’s a lot of confusion around the concept of agile, and particularly when it should be used. Basically, agility is a property of a class of business methodologies. Being agile is great, given the choice between agile and cumbersome who wouldn’t choose agility? But the thing to realise is that you might be accepting other trade offs.

A good analogy is a military air craft. Agility is a great thing to have depending on the role. As it turns out, for a fighter jet agility is one of the most important properties you can have. Dog fighting involves a tight decision loop and the faster you can react and out manoeuvre the opponent the better your odds of winning. Fighter jets need to be agile.

But what about a bomber? In a one to one fight a bomber is never going to be as agile as a fighter jet. The role of a bomber is not to provide combat power in the air but to provide a strike capability on the ground. For a bomber characteristics like range, payload and stealth are more important, agility almost doesn’t enter the picture. Would you waste time building an agile bomber?

When it comes to engineering a software system traditionally a very large process (known as the waterfall methodology) is followed. For government it goes like this:

  • Get the project mandate,
  • derive operational operational needs,
  • work down to functional requirements,
  • put it out to an open tender,
  • a bunch of people respond,
  • analyse tenders by set of predefined criteria,
  • functional requirements form basis of contract (deliver all these functions and we pay you),
  • contractor writes up a big design,
  • validate design,
  • deliver system,
  • test system,
  • authorities approve system,
  • transition into service,
  • sustain it

What a pain, we have to go through all those steps just to get a system?

Well there are really two main steps:
– Build something
– See if it works

If it works, bingo! If it doesn’t, go back to step 1. Except the thing is, evey time you go back you compromise the system. All or part of what you built in step 1 is now waste. Not only that, but the architectural decisions made while building step 1 now have to be revisited, and the design won’t be as good as if it had been rearchitected from the start. The design will have bandaids all over it.

So what we want to do to keep cost down and improve the design is to get it right the first time. Waterfall methodology does all the thinking up front. Work out exactly what the user wants, design the system, build it to the plan, test that it met the original design and introduce it. Waterfall is like a sniper. He chooses his time and place, identifies the target, gets permission to take the shot, tests the wind, makes adjustments, fires….. and confirms the kill. He gets it right the first time.

Or does he?

What if our sniper can only fire once, but now he’s trying to hit a man with a rocket pack at 200 meters from a moving train. He shoots, he misses! All that planning, all that setup for nothing, the solution was the most efficient one possible for a static target, but once things get crazy he needs a new plan.

And that new plan is agile.

Agile is the heat seeking missile. From atop that train he quickly locks in and fires the missile. The target is flying around, dodging and weaving and all the while the missile keeps adjusting trajectory to move toward where he is, but eventually hits the target. Wasting fuel and wasting distance but it eventually hits and we all say mission accomplished.

So which method is the best? It completely depends on the scenario. It scenario one the sniper rifle was obviously more efficient, the heat seeking missile was overkill. But in scenario 2 the sniper missed, all that effort wasted. Even though it used more fuel and cost a hell of a lot more overall, at least with the agile missile we hit the target.

So there we have the two methodologies, the sniper and the missile.

It turns out that in the commercial sector agile is the most effective strategy. Yes it’s more expensive, but only if the waterfall method hits the target spot on the first time, which considering how fast the market moves and how fickle customers can be is pretty damn hard. Agile works on iterations, continually testing and adjusting the solution.

Agile works quite well for commercial and small projects, so where does waterfall come in? Waterfall is great for large projects, where we can’t afford to be agile and the solution can be very well conceptualised ahead of time. You wouldn’t agile design a space shuttle. Imagine designing something that you think looks pretty good, sending it off into space only to have it blow up. Oops! Let’s do another one and tweak that failure point. It gets a little higher then blows up again. Great job. It’s also possible in government that even though agile would be better, due to the number of approvals required and public money handling requirements waterfall becomes your only option, which is frustrating but sometimes necessary.

Waterfall is often occasionally useful in very large software systems. Sometimes these systems are just so huge, particularly with considerations like change management, transition plans and engineering hours spent in development that you just can’t afford to be building the wrong thing. You only get one shot and the problem isn’t going anywhere, so it makes sense to do the analysis up front and get it right the first time.

So there you have the two methodologies. Next time you’re presented with the choice: agile vs waterfall just stop and have a think. Is the target nice and still or will it move slightly before I’m finished aiming? I want the rocket launcher, but can I afford it?

Whichever you choose it will come down to waste. Do I can make the shot without wasting it, or would it be better plan on wasting some time and fuel for readjusting.

Did you like this article? Check out the free task management tool I’m developing at teamsgo.com. You’ll love the simplicity, and your colleagues will love how much more orgnised you are. http://www.teamsgo.com

Comments are closed.