Manifesto for Agile Product Development and Service Delivery

The Agile Manifesto has been my guiding light for many years, but as it is now being applied to more than just the Software Development community, the words used are causing a problem for some. Based on feedback and comments during many years of coaching and training, I propose a few tweaks to the Manifesto, so it applies to all areas of Product Development and Service Delivery

OK, let’s be totally open and honest right from the start, I love the Agile Manifesto.

From the first time I read it almost two decades ago, I have been invigorated and motivated by its simplicity, eloquence and power. As I have personally grown, and assisted others in their own journeys of discovery, I found that all of the best organisational, cultural and team solutions have come from having the right mindset, a mindset that has been developed, honed and sustained through the application of the Agile Manifesto’s Values and Principles.

Combined with the amazing Company Values of Capgemini, the Values and Principles from the Agile Manifesto have become my own personal guidelines in both my business and family life.

But…

While teaching and coaching individuals and organisations over the last six or so years, I have experienced more than a few people who have struggled to see passed the specific words used in the Manifesto to the deeper meanings behind them. I have been saddened as they have been unable to take full advantage of these insights and gain all the benefits that the resultant behaviours could bring.

Yes, as the name implies, the Manifesto for Agile Software Development was created for a specific reason. In the 90's we were having huge issues within the software development community around unfulfilled promises, over-engineering, complexity and unhappy customers. To meet these issues 17 thought leaders from the Software Development community met at the Snowbird ski resort in Utah during February 2001 to formulate a response. It is because of these issues, this time and this group that words like ‘Project’, ‘Working Software’ and ‘Valuable Software’ are used.

These words though have not stopped me extending the insights of the Manifesto beyond Software Development because the voices in my head read aloud different words such as ’product’, ‘working solutions’ or ‘valuable products and services’, and that has got me thinking.

In our current VUCA world, most industries are having similar challenges to those of the IT industry, and if we are able to see the meaning beyond the words, the mindset created by the Agile Manifesto could help resolve their 21st Century difficulties.

In addition, there has been a lot of progress in our ‘Agile’ world. With DevOps, Agility has moved into the Service and Operations domain, and Agility has also spread across the whole globe including areas and people not so fluent in the English language.

So, my question is, why not revisit the Manifesto and the words used?

That is the whole purpose of this article, to propose an adapted Manifesto and start a conversation within the wider Agile Community. I could be as wrong as the next person, I fully admit this, but if you think I am, propose an update and we can happily discuss.

Manifesto for Agile Product Development and Service Delivery

We are uncovering better ways of developing Products and providing Services by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working solutions over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable products or services.
2. Welcome changing requirements at any time during product development or support. Agile processes harness change for the customer's competitive advantage.
3. Deliver working products or service upgrades frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people, developers and service providers must work together daily throughout the required timeline in an open and transparent way.
5. Build teams around motivated individuals. Through Servant Leadership, provide the psychological, technical and physical environments and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development or service team is face-to-face conversation.
7. A working product or improving service is the primary measure of progress.
8. Agile processes promote sustainable effort. The sponsors, teams, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity is essential in all aspects of work. Always ask ‘Why’ and minimise the amount of wasted effort.
11. The best architectures, requirements, designs and recommendations emerge from psychologically safe, self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

In conclusion, I hope you have read this without being offended, it is not my objective to belittle the original Manifesto, but to help more people around the world and in different industries come to a understanding of Agility and develop the right mindset. As always, I welcome your input, collaboration and support in this remarkable and rewarding journey.

My sincere thanks to those original creators and signatories, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.