Recently I’ve visited three software companies that are all “Agile”…. or at least they thought they were Agile. I know a lot has been written about the concept, but after seeing colleagues, friends, and peers struggling to get to grips with it I thought I would bring my own brand “Let’s keep it simple” to the debate.

Recently I’ve visited three software companies that are all “Agile”….

Or at least they thought they were Agile. I know a lot has been written about the concept, but after seeing colleagues, friends and peers struggling to get to grips with it I thought I would bring my own brand “Let’s keep it simple” to the debate.

It’s probably just me but when I hear people talking about Agile I start to get nervous, especially so when it’s my boss, or someone in marketing…. or the sales guy pitching to the latest prospect.

In my head I can see a thought bubble above their heads with pictures of silver bullets, magic cures, impossible solutions, free energy, invisibility cloaks and personal aerial vehicles.

Part of the problem is that Agile Development means different things to different people and whilst the classic benefits are easy to understand, the way to get to the benefits can be difficult.

Ok Dick Turpin, what’s Agile Development?

Maybe it’s easier to start with what it isn’t…

It isn’t Waterfall….

When we tune out all of the white noise there’s a fundamental assumption in Waterfall that doesn’t exist in Agile Development…..

Namely that all problems and corresponding solutions can be understood upfront.

Or that the project will be delivered in a serial type way.

One thing followed by another in a very structured process that probably ends in a big regression test phase.

Agile approaches break the project up into smaller chunks, they’re called sprints.

The basic premise is that when a sprint is finished the software is ready to release.

So we need all the people skills in one team to be able to release i.e. teams are organized around end products / releasable artefacts.

Think about this, it might change your team structure like having dev and test in one team.

Be specific please….

Agile turns the rationale for a spec on its head and says we can’t possibly understand all of the challenges and solutions upfront. We might have a rough idea, or we might choose to deep dive specific problems that we’re aware of in advance, but we accept that we can’t know everything.

We accept that there is inherent uncertainty in not only the solution but also the problem that we are solving. Sounds weird right…. we’re saying that when we start a piece of development we don’t completely understand the problem that we’re solving.

How can this possibly be true??…. Well, it’s true because we’re human and because often we’re attempting to do difficult stuff.

Agile Development for SAP Benefit #1 Reduce Risk

I think this idea of inherent uncertainty is really interesting and kind of contradicts the first of the commonly cited benefits of Agile Development….. Agile reduces Risk:

Now, this is not Agile trickery or bloggy sleight of hand… it’s true because all of the stakeholders are accepting the uncertainty up front, which means that we must work very closely to make sure that we all understand the problem that is being solved and the solution that is being created.

As we discover new constraints or opportunities the customer and build team understand how this will affect the solution.

Four Candles Please

So we have actually dramatically reduced the likelihood of delivering “four candles” when the customer asked bought “fork-handles”…. the risk of delivering the wrong thing has been reduced.

Read my next blog and find out the remaining agile benefits.