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.

Tagged , , . Bookmark the permalink.

2 Responses to An agile principles retrospective

  1. marten says:

    One way to find out if you really understand the Agile principles is simply start doing it. For example simply by following the practises of an Agile development approach like scrum, and try not to think to much about it, just do it.

    And then, after a couple of sprints you look back at these principles and ask yourself: Are we really doing this?

    And this is something you should repeat from time to time. Because sooner or later you will forget about ‘scrum by the book’ and start doing things the way you think is best. If at that point you’re still able to point out the agile principles in your own process, you got it.

    If not, you just learned a trick and didn’t get the point.

    • Thanks Marten!
      I agree that ‘doing it’ is crucial to gaining an understanding – not just for Agile, but for anything that is non-trivial. I also refer to this on the main PragmaticAll site (theory and practice should co-evolve).

      As you rightly point out, doing it is not enough: you also need to reflect from time to time. With that in mind I’m glad to see some books starting to appear which provide practical guidance on facilitating retrospectives.

      However, when somebody starts on Scrum, XP or any other agile practice, I hope they still take a bit of time to examine the rules of that approach and try to make sense of them before they dive in and knuckle down.

Leave a Reply