Steve Fenton

Alternatives to reworking the Agile Manifesto

An article was doing the rounds in an online discussion. The article was about reworking the Agile Manifesto. The premise of making the change was that the original twelfth principle is about regular reflecting on how to become more effective and tuning and adjusting behaviour – the original author argued that the manifesto should be changed often…

Unfortunately the decision by the original writers of the manifesto was to adopt a very strict, non-agile change management approach where any changes to the manifesto would need the approval of all 17 of them. So, pretty much zero chance of there ever being any changes (hence the lack of changes so far).

But here are some points I think may have been missed from this argument and from the reworked version of the manifesto.

While a process should be constantly evolved to be as effective as possible in a changing context, a value system can remain pretty static. If you value integrity, this need not change throughout your life. How you apply yourself to this value in specific circumstances may change.

This is the real reason the Agile manifesto and accompanying principles don’t need an update after ten years. The values they represent are still relevant.

If the question was “should Scrum change”, then there is a much higher chance that the framework would need to change than the value system it is built on. This is probably why changes have been made to The Scrum Guide. Try finding the word “commitment” in the latest version, for example.

Should your process change? Absolutely. Certainly. Your process, built on some framework, built on some values, will definitely need to change. Even if your context was fixed, you would reflect on your process and make it more effective – but it is highly unlikely your context is fixed, so there will be many, many reasons to make changes.

But what about these changes in the “reworked” version of the manifesto? They mainly boil down to terminology. Substituting “Customer” for “Stakeholder” and “Software” for “Solutions”. These changes indicate that a local terminology makes more sense to the author, which is fine – as long as you can change the words without accidentally making a subtle change to the values.

A better solution to editing the manifesto would have been to supply a glossary that removes any ambiguity. For example “Here at ACMESoft ‘Customer’ includes our end users, but also the following stakeholders”. The same could be done with software, development team or any other term. The original manifesto could be left untouched.

On a more specific note, I felt the changes in this reworked manifesto sounded jarring. The introduction of buzzwords made it sound sluggish and irrelevant, for example this additional principle:

Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

This doesn’t have the simplicity of the original and I’m pretty sure that you could find existing principles that cover this and that don’t sound so management-led.

This is a good example of why the original authors of the Agile Manifesto have protected it from churn. It would be so easy to explode it with ideas – but because the original isn’t tied to any particular process you can introduce ideas that are in harmony with the manifesto – such as Lean. The original Agile Manifesto still stands to scrutiny and the value system needs no changes. You might want to create a localised version in your own business language, but beware of altering the values. Perhaps a glossary would be better, with everything else being part of your unique process.

Written by Steve Fenton on