Agile Explained

The agile development community has a number of guiding principles, such as ‘people over process’ and ‘values over practices’, that try to capture the essence of what it means to be Agile. I’m feeling contentious today, so I’m going to poke at them a bit, and also propose a single core concept by which I think Agility can be measured.

I (and I suspect most people) first encountered agile development in the form of XP. XP got the whole agile conversation started because it was so bold, and made no apologies for being so. For that alone the software community should be thankful.

However, the clarity of XP’s message has since been diluted by the whole Agile movement, and the debates over what it means to be agile, what was agile, and what wasn’t, how do you know if you’re agile etc. etc. and we all kind of missed the point.

The point is this: Agility is (from the dictionary) ‘characterised by quickness, lightness, and ease of movement; nimble.’

Another way of saying that is ‘responsive to change’. What is the single largest change that can affect any software project?

Death.

Any project can potentially be canceled at any point. Less severely, budgets and schedules can be slashed, or teams dissolved. Any one of a whole range of events can occur, but the result is always a change.

So, if being Agile means responding to (and more importantly) coping with change, and death is the single largest change that can happen to any project, shouldn’t an Agile process have a clearly defined mechanism for coping with it?

Yes.

You may cry, “Thats nonsense, this fool thinks you can survive death.”

Not survive, cope. In commercial terms, that means delivering the greatest business value in the face of change. In this case, in the face of unforseen project death.

Can you see where this is going yet?

Now we come to the big revelation. How do you deliver value from a cancelled project? By being ready to ship whatever work you’ve done at any point throughout the project. Ship, as in release, deliver, wrap in clingfilm and stick on the shelves. Not only that, but what is delivered should contain the most business value that was possible to achieve in the time you had.

I submit that this ability to deliver what you’ve got at any time is the single defining characteristic for Agility in software development. Every other practice, value, and position statement can be evaluated in terms of its relationship to this fundamental concept.

Glad we got that straightened out.

Advertisements

Can thoughts be patented?

Arguments over software patents are highly topical at the moment (see this thread), so I couldn’t resist jumping in.

Software is about ideas. The act of writing code is that of expressing an idea in a way a computer can understand. Software patents appear to be an attempt to take ideas and thoughts and say, “This thought is mine. Nobody else is allowed to think it.” Its nonsense. For one there is the philosophical argument that there is no such thing as original thought (ie. every thought a person has is influenced by those they’ve come into contact with, and thus cannot be claimed as ‘original’). For another, most software patents are based on work that has gone before, which raises the whole issue of ‘prior art’, and what qualifies as prior art. The current furore over O/R mapping is a case in point. Thousands of developers all over the world have written ad-hoc O/R mapping code. It is such a universal problem domain that for one company or individual to claim ‘I invented O/R mapping’ is laughable. Its perfectly reasonable to try and come up with the best O/R mapping product, but perfectly unreasonable to claim that your way is the only way.

The only truly fair and equitable solution is to compete solely on the basis of quality of service, and for everyone to be honest and respect each other’s work, but what are the chances of that?


[ Previous post mysteriously vanished – for those expecting a post titled ‘O/R Patterns’ – it was just the following link. ]

Required Reading

The following books should be mandatory material for anyone who works with other people:

  • Out of the Crisis, and also, The New Economics – W. Edwards Deming.
  • Good to Great – Jim Collins.
  • Congruent Action – Gerald Weinberg.

Thank you.

Added on 21/07/03 in response to comments: They’re all books that really open your eyes about the nature of working with others, what quality really means, and what it takes to build a truly great company and have fun while doing it.

You are an entropy source

One of the laws of physics (can’t remember which) states that entropy always increases. Put another way, a local decrease in entropy must cause an overall increase. This is how refrigerators work. Lowering an object’s temperature also lowers it’s entropy, however, the heat given off by the coils at the back is increasing the entropy of the surroundings (by raising the air temperature), thus overall entropy goes up. In heat terms, the heat dissipated by the coils will be greater than the heat removed from the contents of the fridge.

The refrigerator analogy works rather well for software. Any time a developer makes a change to some code, its entropy (ie. software entropy, which in this case can be considered ‘disorder’) will tend to increase. In order to maintain the same level of entropy in the code, the developer has to put in more effort than strictly needed to just make the desired change. This effort might be expressed as adding extra tests or refactoring around the changed code. The extra effort takes energy (time + brainpower). To maintain the code’s level of entropy when making changes, the overall entropy must increase – measured in this case by the extra mental effort causing an increase in temperature of the air around the developer’s head.

Maintainable systems

How do you make a maintainable system? Make all your developers spend at least some of their time doing maintenance and support. There is no better way to really see and feel the impact of all the ad-hoc decisions that get made when developing.