Updates to the Agile Manifesto

While the ideas written in the Agile Manifesto  have been inspiring and durable, the actual uptake and introduction of these new ways of working within teams and organizations has not been long-lasting.  It seems like what was radical and groundbreaking in February 2001 now feels commonplace, trite or even old skool in 2016.  When you have parody website (the half-assed Agile Manifesto) that is over five years old, you know people are beginning to feel a bit cynical about this whole Agile thing.

So if we were to re-examine the Agile Manifesto for 2016, what would it say?  In the last fifteen years of Agile practice, have we learned anything useful that helps us understand what Agile is really all about?  If so, what would we identify as our guiding principles?  As it turns out my friend and colleague from Toronto, Gil Broza, has done just that in his excellent book, Agile Mindset: Making Agile Processes Work, and I want to share some of his ideas to help all of you.

As most people in our community know, the Agile Manifesto begins with the familiar four values of individuals and interactions, working software, customer collaboration and responding to change.  The Agile values were contrasted with the predominant paradigms of the day – process and tools, comprehensive documentation, contract negotiation and following a plan – as a way to show how Agile was different not to exclude the “items on the right”.

So if we were to re-state the Agile values for 2016, what would they be?

1. People come first
2. Early and frequent value delivery
3. Customer collaboration
4. Adaptation

To begin with, I think we can be more declarative about what Agile is and eschew the negative contrasting found in the original document.  Today in 2016, thousands upon thousands of people have adopted Agile practices.  Agile thinking and Agile practices have been used widely and successfully to deliver working software in a variety of domains with a variety of teams.  Fifteen years later, it is no longer that radical to say that Agile works.

Second, as we have matured in our understanding of Agile we have seen many examples of how Agile ideas and practices can be employed outside the realm of software development.  For people outside of software, value delivery is more germane than a slavish adherence to the phrase “working software”.  Now before all my detractors come at me with the long knives, if you are using Agile to build software products, then the correct term is “working software” not “value delivery”.  However, if what you are doing is not valuable, then why do it at all?