Refactoring the Agile Manifesto

| by Amr Elssamadisy Follow 0 Followers on May 22, 2007. Estimated reading time: 3 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Bad link to Brian Marick's blog by Ray Davis

Here's the right one.

A historical document... by Chris Matts

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.

Re: Bad link to Brian Marick's blog by Amr Elssamadisy

Thanks - fixed.

Re: A historical document... by Amr Elssamadisy

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... by Deborah Hartmann

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. :-)

Re: A historical document... by Chris Matts

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.

Agilepeadia by Chris Matts


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.

Re: Agilepeadia by Deborah Hartmann

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?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you