The Agile Manifesto is six years old. Some have become disillusioned with Agile as it has spread and (inevitably?) been diluted. Post-agilism has been discussed even before Agile has become truly mainstream. Some have suggested that we have learned much over these years and the Agile Manifesto needs to be updated. Brian Marick, one of the authors of the Agile Manifesto, gave a keynote at XPDay Toronto entitled Six Years Later: What the Agile Manifesto Left Out and then blogged about it later with clarifications:
Despite coming out for customer collaboration over contract negotation, the Manifesto is something of a contract proposal: We promise to give you working software (at frequent intervals, no less), and we promise to stop whining when you change your mind late in the project. In return, you need to stop slowing us down with things like documents and tools and processes that are sometimes intended to be helpful (though not actually helpful) and sometime are ways to keep tabs on us because you don’t trust us. Instead of watching us indirectly, you need to come talk to us. A lot.
That was an appropriate and successful message for the time, but it’s now a different time. Now Agile is more respectable, a safer choice. The challenge isn’t so much getting a chance at Agile as it is executing once you’ve gotten the chance.
Marick then gave four missing ideas: skill, discipline, ease, and joy. This is similar to what we have previously reported on InfoQ that Kent Beck has been discussing how to have more ease at work and ways that people can bring a deeper sense of satisfaction at work.
Ron Jeffries and Chet Hendrickson have recently announced Five Days of Software Development with Style and Grace as a 5 day training course. When I asked Ron about why the community needs yet another agile class or TDD he responded:
This isn't "yet another Agile class". This is a workshop for people who have come to be interested in the particular way they have watched Chet and me work. We believe that while good software development involves skill and discipline, good software also requires working in a relaxed and mindful state we're calling "style and grace" in this offering. Our plan is to help people understand what we do and how we do it, and to experience it enough to decide how it fits into their own approach.
Simon Baker wrote about a conversation that took place at the previous Agile Practitioners Forum:
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.
Baker suggested that the concepts in the Agile Manifesto aren't easily understood in the business community and that maybe some of the concepts of Lean, such as pursuing excellence, understanding waste and eliminating it, optimising the whole, and queuing theory, might help alleviate this issue.
Jason Yip, on the other hand, took a more light and humorous perspective on refactoring the Manifesto:
- Let's talk to each other
- Let's just build it and show you
- Let's trust each other
- Let's respond to what is happening and what we learn.
Should the Agile Manifesto itself be agile? Most would agree that it should, but modification of the Agile Manifesto makes sense if the core values of the community have changed. Have they?
Whether they have or not, many of the thought-leaders of the Agile community are moving forward from their experiences and looking to issues not currently addressed directly by the manifesto. Perhaps the Agile Manifesto should mirror the community's evolving understanding of how to build better software.
