Agile manifesto part 3

There is more value in continuously evolving community thoughts than in a fixed manifesto

Adjugo, Chris Verlinden

Let us move to the third principle:

Customer collaboration over contract negotiation

I get what this means. I think.

This is what Beyond Budgeting says about it:

CustomersConnect everyone’s work with customer needs; avoid conflicts of interest.

Or SAFe:

 The goal: Creation of value, as fast as sustainably possible, aiming for best value to customer and society.

The alternative mission statements point out some weakness in the Agile Manifesto Principle.

For one thing, it is often not possible to collaborate with the customer in any real sense. You develop an App or a computer game: who do you collaborate with? The software developers may be able to collaborate with proxies for the customer such as business people whose job it is to understand the customers’ needs, or product owners who talk to business people who may be in contact with the customers, but that is pushing it. Or worse: if business really sends somebody over to work full time with development, chances are they do not particularly want him/her around. They are not sending their best.

There is often no relevant contract to cover the software development work either. An internal IT-department is unlikely to have formal contracts with the ‘business departments’ they work for.  If you work as an employee or as a freelancer in the average software project, I am fully behind you negotiating a good contract for yourself.

The statement in the Agile Manifesto is easiest understood as a fixed scope– fixed price software development contract. These are indeed important in IT business (and other business) and do suffer from serious problems when discussing ‘scope creep’ versus ‘this was clearly intended all along’. But these are too specific for a general principle.

So, as before, the Beyond Budgeting statement is stronger that the Agile Manifesto. The statement really should be about the agile organization aligning to customer needs. As in SAFe, where we use Value Streams as the basis for collaboration.

And then the final principle:

Responding to change over following a plan

This one is good. It captures the essence of agile thinking and uses a sensible contrast.

So that is it about the principles.

Again, there is nothing wrong with the Agile Manifesto from a historical perspective. It made a big splash – in the long run (it was not all that much noticed at the time). That splash is changing the world and agile is becoming way more than just something nerdy programmers do.

In fact, the changes agile software development has brought and the new tooling that has been developed to support agile, have made some of the original elements in the agile manifesto less important and somewhat obsolete. Fortunately.

The real issue is that there is no mechanism for keeping the Agile Manifesto up to date, even if new insights and a new consensus are arising on what agility really means. The Agile Manifesto should be true to its own principles: respond to change over following a strict manifesto.

What to do with this?

If the Agile Manifesto still inspires you, let it be your guide and look for updates in the vibrant agile community. If, like me, you are suspicious of dogma, you can still respect the Agile Manifesto as written in a specific context, but as it triggered the change of the context, it starts to get outdated.

To paraphrase the Agile Manifesto: There is more value in continuously evolving community thoughts than in a fixed manifesto.


You can read the first post in the series, as well as the second one...