AGILE IN ACTION

Sunday, 29 April 2007

Does the Agile Manifesto need refactoring? Should it be extended?

Posted by Simon Baker

At the previous Agile Practitioners Forum , Colin MacAndrew asked the group "Does the Agile Manifesto need refactoring?" and it was encouraging to see quite a few people leap to its defence. Now, Colin simply asked a question about whether it could be improved, he didn’t state that it needed to be re-written. And yet the defence of the Manifesto was so vehement it took me a little by surprise. There’s a spark for an interesting debate here. I think it’s one worth pursuing in a future meeting.

I hope that everyone agrees that the Agile Manifesto is an important guiding text. However, it should not be sacrosanct. Some months ago I bought a new mountain bike. Before I left the shop the assistant reminded me to bring the bike back in 6 weeks for a free service - to "tighten some of the nuts and bolts that may have worked loose during its initial use and to check everything remains in working order", he said. Now, maybe the Manifesto is still right on the mark, but unless we take the time to review its statements and principles (through debate) given what we’ve learned about agility in the 6 years since its inception, we won’t know if there are a few "nuts and bolts that need tightening".

Brian Marick recently posted :

Six Years Later: What the Agile Manifesto Left Out.

The Agile Manifesto has worked rather well at changing the way software is built, but the Agile movement is now suffering from some backsliding and some backlash. I believe that’s partly because the Manifesto is almost entirely focused outward: it talks, to the business, about how the development team will interact with it. What it does not talk about is how the team must interact with itself and with the code. In the early days, that didn’t matter so much; the right interactions tended to happen anyway. But now it matters.
I look forward to reading what’s produced. Certainly many teams struggle with agility because of difficulties within the team. But I’m still wondering how much of the backsliding has been due to the Agile Manifesto not being understood at all levels of an organisation. Some of the qualities it alludes to may not be immediately obvious to senior management. I bet in many cases senior managers don’t even know about the Manifesto but that’s a failure in the adoption strategy. In my experience, it is this lack of understanding coupled with an incompatible corporate culture engrained with superstition and habit that is, more often than not, ultimately responsible for the breakdown in agility. Often, what is happening or not happening with teams is symptomatic of more deeply rooted problems.

The Agile Manifesto is a very useful tool and I use it all the time when I’m coaching. However, I do think it can be improved. In particular, to help senior management understand agility so that they can provide top-down support for it and take action to create and maintain a corporate culture in which agility can become sustainable. Based on experience, I’ve had better results engaging senior management when I use concepts that are more familiar to Lean practitioners (e.g. pursuing excellence, understanding waste and eliminating it, optimising the whole, queuing theory, etc) as they seem to provide a common understanding. The essences of these Lean concepts could be incorporated into the Manifesto and its principles.

I also think that some of the current wording undersells what have become cornerstone techniques. It’s not possible to appreciate the full capability of self-organisation from the principle, "The best architectures, requirements, and designs emerge from self-organising teams". And what about collaboration? This is limited to "Customer collaboration over contract negotiation". Both these statements are true and powerful but nothing is said about the richness of interaction and the commitment-based working that results from self-organising teams of people who collaborate intensely. Another principle starts, "Build projects around motivated individuals". Again there’s no doubting that this is good advice but it doesn’t communicate the greater ability of empowered teams (another Lean concept) where decision-making is pushed to the people doing the work. And what of the role of facilitation and leadership in empowering teams?

All this falls under "Individuals and interactions over processes and tools", which is testament to the foresight of the founders of the Manifesto. But maybe some of the current principles can be re-worked and some new principles added to communicate a more coherent and holistic alternative to hierarchical structure with role-based departments, command-and-control management, and waterfall development.

For me the Agile Manifesto needs to evolve over time.

1 Comment

The values part of the manifesto (X over Y) came together amazingly quickly once someone (Martin Fowler and Dave Thomas, I think) came up with a draft. The Principles part came partly after the meeting, via email, and was a troubled birth. It shows.

Comment by Brian Marick

Creative Commons Licence

Recent Posts

  1. Pursuing features increases total cost of ownership
  2. Organization complexity is a waste farm
  3. Managing costs provides a false sense of security
  4. State of Agile survey for 2011 tells a familiar story
  5. (I can't get no) satisfaction, let alone customer delight
  6. Positive emotions and purpose
  7. People don't buy what you do, they buy why you do it
  8. Too busy chopping wood to sharpen the axe
  9. So you want a fresh apple
  10. Systems are seductive

Archives

  1. 2012 (6)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
    1. December (11)
    2. November (7)
    3. October (17)
    4. September (8)
    5. August (7)
    6. July (13)
    7. June (15)
    8. May (24)
    9. April (14)
      1. Does the Agile Manifesto need refactoring? Should it be extended?
      2. Self-management and self-leadership
      3. Improve quality to increase productivity
      4. Self-organisation again
      5. Breaking habits
      6. Self-organisation
      7. Put customers first and everything else follows
      8. I just came from there ...
      9. Defect tracking tools and waste
      10. Individuals and interactions over processes and tools
      11. Are you missing the point?
      12. Scrum Master, Master of Ceremonies and Quartermaster
      13. When you put it like that ...
      14. Become a certified Agile Software Specialist!
    10. March (19)
    11. February (7)
    12. January (10)
  7. 2006 (128)
  8. 2005 (63)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (39) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (18) team (30) testing (18) xpday (19)