An agile principles retrospective

The agile manifesto is, by now, well known within the IT community and its fame is spreading beyond IT. Whilst the agile manifesto itself is well known – particularly the 4 ‘preference statements’, the twelve principles seem to be less well known. Perhaps it is because many people dive straight into a particular agile development approach (e.g. Scrum) instead of dwelling on the rest of the material that is part of the agile manifesto? I wonder if a poor understanding of those principles is a significant cause of poor implementations of Scrum?

The agile principles are a great way to get a feel for ‘the agile way’. Reading through them again, there are many principles that I can wholeheartedly agree with – but also a few that I feel could be improved. Here is my take on the sub-optimal agile principles (I’ll try not to simply repeat what Tom Gilb had to say about them in AgileRecord #03).

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Satisfying the customer should be the highest priority – no issue. (It is not always clear who the customer is, and there are many other stakeholders that we should try to satisfy as well of course). What I dispute is that continuous delivery is the only suitable means to satisfy the customer. For example, in an environment with many interdependent legacy applications continuous delivery may put too much strain on testing. Regular demo’s of a working product to the customer (or stakeholders) should still be attempted, but actual delivery to the production environment or to end users could be done in larger release cycles.

Business people and developers must work together daily throughout the project.
This principle is sound – if you interpret it liberally. I would say: key business stakeholders must work together with the delivery team throughout the project. It must be a multi-disciplinary operation and it must go on throughout the project. I don’t think it has to be daily, though. It is important that people are available on a daily basis if needed, but that does not feel the same as ‘must work together daily”.
And working together is not just about business people and developers. I know some agile approaches call the whole team “developers” but I would like to emphasize that you need a good mix of different skills. I also think it is important to work together with other stakeholders and subject matter experts as much as possible.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I suppose this principle is fine, only it should come with a disclaimer. Something along the lines of: “Caution: motivated individuals need regular care and attention if you want them to stay motivated.”

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is just plain rubbish, sorry guys. There is no silver bullet; face-to-face conversation is not the most efficient and effective method in all cases. For example, if you’re not co-located then face-to-face conversations may still be a very effective method of conveying information, it just is NOT particularly efficient due to travel overhead. (I know ideally the team and key stakeholders are co-located, but I don’t live in an ideal world.) And if you need to comply with a written standard then just reading the document may well be more effective than face-to-face conversation (though probably a lot more tedious).

Working software is the primary measure of progress.
Tom Gilb already said it all on this one. In short: “Added value is the primary measure of progress.” (my interpretation).

The best architectures, requirements, and designs emerge from self-organizing teams.
This I can believe: effective self-organizing teams will quite possible outperform other teams. Unfortunately, many people seem to think that this principle implies that “Each self-organizing team will produce great architectures, requirements and designs.”. Well, it does not and they don’t. Good self-organizing teams do, but if you randomly put together a bunch of people and tell them they are a self-organizing team they won’t necessarily be good at self-organizing. This fits neatly with Roy Osherove’s concept of elastic leadership which gives guidelines on how to lead teams depending on their maturity.

But hey, what do I know about agile? I’m not even certified.