2 Dec 2007

are you agile....enough?

A recurring question on many of the Agile discussion boards is what is Agile? The problem is that at it's most basic, Agile is simply the values laid out in the Agile Manifesto.

The Agile Manifesto was an agreement that was made by key software thought leaders including:
- Kent Beck, Ward Cunningham and Ron Jeffries (XP, JUnit, Design Patterns),
- Ken Schwaber (SCRUM),
- Martin Fowler,
- Dave Thomas and Andy Hunt (The Pragmatic Programmers).

The Manifesto was basically a statement of values, specifically:

"We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."
Source: The Agile Manifesto

Great words, but how does that help us in practice? I believe that the key to being Agile is held in that last value: being able to respond to change.

In software development change affects us through changes in requirements, and changes in our code.

Coping with changing requirements
Requirements can change either because we realise that there has been a misunderstanding between developers and customers, or because the underlying reason for the software system has changed.

With traditional approaches we create detailed requirements documents and get customers to sign these off. We then try to discourage changing these "signed off" requirements by introducing heavy change control procedures. Unfortunately this approach doesn't work too well when:
- the requirements are still "wooly" (the customer isn't actually that sure what they want); or
- the business that the system is to support changes rapidly.

Unfortunately this approach also ignores the fact that it is actually extremely difficult to get a picture of a working system from a requirements document. This increases the change of misunderstandings between developers and customers.

With Agile approaches we try to respond to change in requirements by developing software iteratively. This drastically reduces the time to having something to show our customers, which in turn increases the feedback. Getting the feedback earlier means we can react to that feedback quicker. Getting feedback quicker makes it easier to incorporate any changes. The shorter the iteration - the shorter the feedback cycle.

This has to be a balance though - too short an iteration and you risk not being able to get anything meaningfull done. Most agile advocates recommend between 1 to 3 weeks as the sweet spot.

Coping with changing code
Changes in code happen each time we add or remove a line of code. This change is continuous, and carries with it the risk we break something.

With more traditional methods, we try control this change through clever architectures and up front design to limit the impact of this change.

With Agile approaches, instead of trying to control this change, we attempt to embrace it. We accept that we have a very good chance of breaking things when we change code and rely on fast running automated tests to help us catch this. Each time we add a small amount of code we rerun our tests - if they all pass - we have a confidence that we have not broken anything.

Fast running automated tests and short iterations
Fast running automated tests and short iterations. These are the two core tools that help us respond to change - and that is what keeps us agile. Many of the most of the popular Agile practices are based around making it easier to do these two things effectively and leveraging their effectiveness.

If you can get these two things working effectively for you. You are most of the way there.