The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Amr Elssamadisy on May 22, 2007
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:
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.
Five Key Practices to Agile ALM
18 agile and lean practices for effective software development governance
SCM best practices for multiple processes, releases & distributed teams
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Here's the right one.
At the first ADC conference in Salt Lake City I put to Allistair Cockburn the idea that the Agile Manifesto should be "refactored" ( "rewritten" to non techy, non agile types ). It was obvious that "Business Value" was more important than "Working Software" which was more important than "Extensive Documentation". It was obvious that "Good relationships" were more important than "effective communication". ( You may speak the same language as someone but if you have a bad relationship, well it ain't gonna work ).
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.
Thanks - fixed.
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?
I also think of it as an 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. :-)
The Agile Manifesto is not really meant as a starting point for Agile. They would be better off reading the White Book, and a Scrum Book, and "Lean Software Development", and "Agile Software Development"... and probably some more. Perhaps the AA could sponsor someone to write the "dummies guide to Agile".
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.
Deborah
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.
I've also been thinking some more about a wiki. I'm surprised that no wiki has surfaced as a central repository, as C2 was for so long for the patterns community.
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?
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
8 comments
Watch Thread Reply