The Manifesto for Agile Software is 16. It’s no longer a ‘new’ thing to try out and feels as established as what came before it . . . so established in fact, that we should return to source and ask the question:

Is the manifesto for agile software as valuable as it was in 2001?

The answer, for my money, is ‘yes’ . . . and not just for software but for public services too.

I had the conversation in real life recently with my colleague Georg Fasching, and we agreed that if you replace the word ‘software’ with ‘public services’ then the manifesto and principles are great for building public services that are judged on how valuable they are for users and the organisations we work for (not just on their adherence to cost and delivery milestones). Features of public services should be designed and prioritised by how valuable they are, and value should be delivered as quickly as possible in small increments.

Sixteen years on, here’s a return to the agile manifesto - tweaked slightly to apply to public services (whether or not they are software).

The Manifesto for Agile Public Services

We are uncovering better ways of developing public 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 public services 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 for Public Services

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable public services.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working public services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and development teams must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working public software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, development team, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximising the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organising teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What do you think, is the Manifesto for Agile Software Development still valuable at the age of 16?

Background

ps

Me and Georg both felt that ‘simplicity–the art of maximising the amount of work not done’ is the principle that public services would most benefit from focussing on, since many public services are unnecessarily complicated and could be much more valuable for users and government organisations if they were simplified. What do you think?