In my first post on the subject of “Agile” I want to focus on “The Agile Manifesto”, what it is, what it means and that it is often misrepresented by many people.

The agile manifesto was created in 2001 by 17 people who wanted to find a better way to develop software. They met in Snowbird Utah and over a few days came up with what we now usually refer to as “The agile manifesto”. This is probably also the first source of misunderstanding and possible contention. Later on the same group of people came up with the 12 principles of agile software development, which is likely to be the subject of a future blog post. You can find more about the history of the manifesto here and it is a very interesting read if you are in a typical “Agile shop” today.

Maybe the first thing to realise about a manifesto is what it is. There are many dictionaries online where we can look up the definition of “Manifesto” and the first that came up for me was the Cambridge dictionary so here is their definition “A written statement of the beliefs, aims, and policies of an organisation, especially a political party”. Therefore we can conclude that the manifesto was a statement of aims, beliefs and values at the time that the manifesto was written. The same group of people have not come together to update it since that time, and it stands as the best that any group of people have done to that point or since in terms of widespread recognition.

Let us review “The agile manifesto” by looking at it one section at a time and seeing what we can learn from it.

The title
“Manifesto for Agile Software Development”

What does this tell us? Well it starts by telling us that this is about software development. If you are using “The agile manifesto” to sell agility anywhere else then you’re most likely doing it wrong. This is not a generic “Agile manifesto” for a whole business. It may transfer to other business areas or it may not, and in either case it was not the intention that it would. This manifesto is about software development so please bear that in mind when discussing agility, especially in a wider business context.

The introduction
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:”

Here we can see that the agile alliance (As the group called themselves) were uncovering better ways of working at the time (2001). As in it is a never ending process to find better ways of developing software. We can also see that we learn better ways of developing software by developing software. Therefore we can conclude that we should develop software in order to get better at developing software. As such we might have learned more in time and come up with a better manifesto in future (After 2001).

By the way I know it seems obvious to say that we should learn better ways of developing software by developing software. The problem is that all too often “Agile” is pushed by management to gain something other than better ways of developing software such as “Twice the work in half the time” (If they read that book). I don’t mean that agility cannot make you more effective or efficient at developing software, just that people should make honest claims and use it for the right reasons. This blog will get into my take on that in future.

The values
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

This is very interesting when you read it and look at it more closely. We value individuals and interactions over processes and tools, but how much more? Just a little more? A lot more? We don’t know. We may even find instances where it isn’t a zero sum decision and we can enhance both at the same time. The same holds for every one of the value statements in the manifesto. If we want to be agile, according to the agile alliance in 2001, we should value the items on the left over the items on the right and we have to find the right balance for our environment.

So what do I mean by environment? That is a great question because it is multi-layered. We have to balance these values at the right level, which might include some or all of the following: –

• Organisational.
• Program.
• Project/product.
• Team.

An example might help to clear that up. Say we want to respond to changing conditions over following a plan. At the team or individual level this is very easy. At the project/product level this requires more effort and the effort is even greater at the organisational level. However, this also means that we should probably work in a way that permits us to change direction as easily as possible and commit to a course of action as late as possible. So when we are writing code we should do so with the mindset that we might change direction in future. It is also a great idea to work towards being in a permanently shippable state so that we can always test if we need to change direction or not. These points change a lot things about how we code and the processes by which we want to work.

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

Lastly a point about the value statements is made. We value everything mentioned, we just value the items on the left more. Which means that while we value responding to change over following a plan, we still value plans (In my opinion it is more that we value planning, as in the activity of creating plans. I am sure I will have a post about that in future as well). In the same way we value documentation, just not as much as working software and so on. This is very important because some people seem to think that we value software and don’t document anything anymore or that we respond to change so we never plan more than a week or a month ahead. That is far from true and was never a part of the manifesto.

In conclusion
So what can we learn from the manifesto? Well there are some points that seem to be misunderstood, and for me the following stands out: –

• It is a manifesto for software development (Not generic agility).
• The people who created the manifesto were learning, are learning and will continue to learn. We all continue to learn, so maybe we can do better, maybe not. We will learn that in time.
• It has 4 values statements and we value both sides.
• There is no defined method, methodology or process by which we become more agile. We have to find the right way to work for ourselves.

The manifesto for agile software development is a very simple statement of values with the aim to helping us find better ways to develop software, no more and no less. Something else that might not be totally obvious, because it isn’t mentioned, is that the manifesto does have a focus on individuals, trust and respect that runs through those values and is in support of organisational models based on people.

The “Agile manifesto” is about software and not generic business agility. If you want to use “The agile manifesto” to promote agility in other areas of a company please do so honestly and openly. State what you have learned from the manifesto for agile software development, including that a people centric approach works extremely well, at least in a learning environment. Make reference to the manifesto all you need, just be honest that it isn’t a generic manifesto for all business areas.