by Liz Sedley

Recommended Reading

Introduction to Agile.

I am constantly amazed at the misconceptions held about agile. When I interview develoeprs I always ask what they know about Agile, and invariably I get back a specific practice like pair programming or test driven development. Agile is hard to explain in thirty seconds, but here I will try to introduce what Agile is really about. This article is for anyone, at any level in the organisation, who is interested in understanding what Agile really is.

The Agile practices that I personally have chosen to adopt come from eXtreme programming and lean software development. Adopting these practices, along with time, patience and energy helped us down the path of becoming a learning organisation.

Agile is about responding to change. This really freaks out companies who do fixed price contacts. They need to know exactly what we are going to do so we can decide how much to charge.

But if you want to deliver customer satisfaction you must respond to change. The customer doesnít know what they want. Not exactly, maybe not even vaguely. During the course of development ideas will flow, and the good ideas need to be captured and implemented in the prodcut. Not ignored because it is too late.

For me the most heartbreaking thing is being on a project that is going to deliver what the customer asked for, but not what they wanted.

Of course Agile doesnít force you to change. If you donít get any better ideas during the course of development you can stick to your original ideas. However if you are working on a project for months and donít get any ideas about how to do things better, what are you thinking about 9 Ė 5, Mon Ė Fri? What value are you adding to your company?

I think the bussiness implications of responding to change is the biggest blocker to turning agile. It may require a totally different realtionship with your customer. If this is a problem in your company you can do one of two things.

1) Donít implement this piece of the puzzle yet. Get some successes elsewhere and come back to responding to change later.

2) Or, realise that itís a mammoth task and work out what the first baby step towards it would be Ė and then take that baby step.

The way agile teams respond to change is by not doing anything that is not required immediately. The person who best represents the customer chooses the feature which is most valuable to the customer, and the whole team works on that feature.

What the team doesnít do is try and anticipate the future and implement things that might come up in the future. This is the key to being able to respond to change. If you havenít invested anything in a feature, then it is free to change your mind and implmenet something else instead.

Agile is about adding nothing but value. Itís about examining every bit of work everybody in the company does and thinking about how it adds value to the customer.

Agile challenges the value of everything that is being done. For example, In what way do requirements documents add value to the customer? Oh, by enabling the customer and the development team to agree on what is being produced. But is a document the best way to do this? Is there a better, less ambiguous way of understanding what weíre trying to build? ( There is, but thatís a topic for another dayÖ)

Part 2...