Smarter Is Faster

A common mantra you will hear in many companies is to equate Agile with speed.

While in broad strokes it is true to say that Agile is about delivering quickly and frequently I think its important to understand where this speed is supposed to come from.

No Silver Bullet

Agile is not a silver bullet that will allow you to squeeze more effort, work or speed out of your developers.

If you try to use Agile to produce a large monolithic piece of software based on a large set of sometimes vaguely defined requirements you will face the same issues and problems that these kinds of projects have always faced.

What Agile is trying to tell us is that trying to deliver software in this way will always be slow.

Instead in order to get something of value out of the door quickly we should apply two relatively simple concepts, don't waste time and start off small.

Wading Through The Detail

At the start of a project, especially a new project, we know very little about what it is or what we should be building.

One approach to gaining this knowledge is to spend time, usually a large amount of time, thinking hard about what users of this system might want and producing a large list of requirements and producing a detailed plan.

Maybe we understand our customers inside out and we completely nail what it is they want, or as is often the case we realise we started off on slightly the wrong direction and what users want is subtly different from what we've delivered, they don't hate it but they don't love it.

Not only is the time we spent defining the requirements now wasted but also the time it took the developers to implement those requirements has also been wasted.

The situation for developers may be even worse if the new requirements based on customer feedback contradict some of the early up front requirements they might have to spend more time unpicking what they've already done.

How could we have avoided this? We could have admitted we're not sure exactly what the users want and instead produced something minimal that works and use this as a vehicle to get their feedback.

Sprints Not A Marathon

The true speed of Agile is delivered simply by developing small chunks of functionality that delivers some value to the user and provides an opportunity for iteration to deliver more in the future.

This doesn't involve developers working harder or faster, its simply that it takes less time to deliver something small.

It also takes less time to define the requirements for something small and less time to test something small.

Agile is not a magic wand that can distort time to enable something large and complicated to be delivered quicker, its a dose of realism that the only way to conquer the mountain is one step at a time.

Glorious Failure

Another aspect of Agile that is sometimes distorted in the name of speed is the concept of failing fast.

Its crucial to understand what should be meant by failure here.

Having developers work beyond their natural pace to point where they make mistakes is not failing fast, that's just being sloppy. Within Agile development quality is not an exchangeable commodity for anything else.

We've talked in this post already about user feedback what sort of feedback would we rather get,

"I quite like that idea but it would be more useful if....."

"I don't really know what it does it keeps crashing"

The type of failure we should embrace is where we slightly miss the target, we are aiming in the right direction we've just not hit the bullseye. If we can experience that kind of failure quickly we can improve, iterate and eventually hit that bullseye.

Failure to deliver something that works is just failing, users don't forgive that, nor should they, users aren't an extension of your QA department.

Agile does deliver speed, but only if you embrace what its trying to say, it doesn't do this with some clever technique to deliver 6 months worth of work in 4 months, it does so by only requiring 4 weeks worth of work in the first place.