Refactoring the Agile Manifesto
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.
Bad link to Brian Marick's blog
A historical document...
Point is, I had him on the ropes... So I thought.
Alistair's response was that the Manifesto was a historical document. It had taken the days at Snowbird to agree the four principles, and then it several weeks of e:mail to agree the rest. This was with a small group of people, less than twenty.
He was right. By the time of ADC v1, the Agile community had grown to a thousand or so people. How do we get them all in a room to agree the new Agile Manifesto. Was it possible?
The Agile Manifesto is a historical document. The community has a choice. We either leave it as it is. An imperfect call to arms for a new generation of developer who believe in Winston Royce's original dream, or do we update it?
Leaving it is easy.
Updating it is hard. We have to find a PROCESS for coming up with Manifesto amendments (think constitutional amendments). We can leave it as a play thing of the Agile Alliance board, letting the 10 or so elected official decide, or we have a referendum. Chose your poison.
I vote for leaving it alone. I don't need a written set of rules to tell me what Agile is. I'll make it up myself. I would rather do something useful... Like invent cool new tools and methodologies.
Good night. I'm off to bed.
Re: A historical document...
I don't need a written set of rules to tell me what Agile is. I'll make it up myself. I would rather do something useful... Like invent cool new tools and methodologies.
You have a point - but what about all of the new people adopting Agile? Shouldn't they have access to a concise document of our current best?
Re: A historical document...
However, if it is going to be refactored, I'd suggest a third strategy: put it on a wiki and see what happens. Those who care will show up to help reshape it... I have no idea where this would go.
Personally, I'd rather spend my energy learning how to implement it in different contexts. :-)
Re: A historical document...
The Manifesto is really a simple statement of values and a yardstick to measure tools, processes and behaviours against.
I like the idea of a wiki. It would be an interesting experiment. It is still a process mind.
Another concern is that there are a lot of different view points in Agile. At the moment the community holds together because there is no precise definition of Agile. As we refactor and refine the Manifesto, there is a danger that we cause religious wars, division or fragmentation. The community benefits greatly from its current diversity. I suspect there are very few conferences that can pull together developers, testers, PMs, BAs, facilitators, Psychologists, Astronauts, Leaders and me.
Now that I've slept on it, i like your wiki idea more and more... However I would like to extend it to cover Amr's idea. A home for "a concise document of our current best". What better way than a wiki to make sure content is current.
We should learn from wikipedia in determining the rules for content. As well as "facts", we could have "opinions". My opinion on BDD for example.
This would be a good thing for the Agile Alliance to support... but it takes more than a server and money. What does supporting a public wiki take? I think I'll ask Sunir over at Meatball Wiki. Luckily he's in Toronto, so I can actually invite him for coffee! :-)
This is sort of segway-ing into the other news item on the Refocusing the Agile Alliance, isn't it?
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015