The Agile Manifesto for Public Services

03 Jun 2017

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:

Principles behind the Agile Manifesto for Public Services

We follow these principles:

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



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?