Understanding the Agile Manifesto

To understand what Agile means today, we should start with the Agile Manifesto and its origins.  Even people with a minimal exposure to Agile may have heard of the “Agile Manifesto”.  It’s a provocative title which immediately puts “Agile” into a semi-political, even confrontational domain.

The Agile Manifesto came from a group of people who had considerable experience in software development.  They had found, by experiment, that some techniques appeared to be more successful than others.  Few of these techniques had any sort of clearly documented approach, let alone a substantial following. Some had started to write about what they had found effective.  Of course in the pre-internet days, communicating and sharing these ideas was harder than it is today.  The obvious solution was to get a group together to discuss and agree common good practices.

It’s easy to see the Agile Manifesto as an attempt to define the “right” way to develop software.  However, it seems no-one viewed it that way.  There seemed a general agreement that there was no “right” answer. What the meeting addressed is not the differences between approaches but the similarities.  There was a surprising level of agreement from all those present that there were common approaches that were working.

Agile as a standard

A critical point to understand about “Agile” is that it is not owned.  There is no “Agile standard” or trademark.  There is no standards body who arbitrates what is and is not “Agile”.  This is where much of the confusion about Agile is generated.  The output of the Snowbird meeting was the “Agile Manifesto”.  It is not an instruction manual for running software developments, nor a set of rules.  It is a set of concepts or ideas where the attendees aligned.

The Agile Manifesto is not hundreds of pages of text.  It is not even hundreds of words.  It totals only sixty eight words.  There is a further section of “Principles” which make up another 189 words.  The Agile Manifesto is about the same size as one verse of the US national anthem.  With the Principles it is a little smaller than all four verses combined. We can reproduce the Manifesto itself below, in full.

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software 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.

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT

We are uncovering better ways…

Most people skip over the first sentence, thinking it is just a preamble before we get to the main part of the Manifesto. To me, however, this is the most important sentence in the whole manifesto.  You don’t waste sixteen words on “fluff” when you only have sixty eight words to play with.

Agile development is about “doing it and helping others do it”. 

It is very much a practical application, not a set of theoretical principles.  The authors could have considered what software development should be from an idealised viewpoint.  And then they could have worked from that to decide what we need to do in order to implement that theory.

Instead they focussed on practical learnings.  They were experts who had worked with software for a long time.  They had seen what worked and what did not.

Good practices

This principle of learning by doing is fundamental to Agile development.  This preamble also empowers the reader.  At no point is the manifesto presented as “final and perfect”.  “Learning by doing” is the underlying approach.  The implication is that we too, as readers, can “uncover better ways” by following the path of “doing it and helping others do it”. Support your teams in exploring and proposing better ways.