Pragmatic Agile Weblog

Agile software development in real life

Principles and anti-principles

Who heard of agile software development very likely heard of the Agile values and principles. These are quoted in the agile manifesto that you can read here.

I think that the fact that agile methodologies are backed by that conceptual framework is extremely effective and powerful (in addition to be a genial marketing move): it gives you a common background or system of values to think about when you are facing a problem and you are trying to figure out a solution. I believe the power of agile principles and values is the charge of positivity in finding good solutions that will make you a step forward in the right direction.

What I am realizing and experiencing lastly is that agile principles and values have also a negative charge, the dark side of agile principles… đŸ™‚ Let me explain. I consider a positive charge when in front of a problem we think at the values and they show me the right path. For example, in front of a customer that changes his mind about a feature, instead of pointing out that in the statement of work we said the features would have been different, we work with the customer to see how we can fit the change in the plan done together.

An example of negative effect of the principles and value is when they are used like a shield, or worst a ax, to make sure that something we do not like does not happen. I do not like to write documents? then I bring the principle “working software over comprehensive documentation”; I do not like this or that tool? then “individuals and interactions over processing and tools”; somebody asks me about my missed commitments? then I bring “responding to change over following a plan”. In other words, instead of trying to understand the underlying problem and finding an agile solution, I sometimes see the tendency to hide our-self behind the excuse that things should be done differently. “You want to be agile??? then you must follow the manifesto!”. How to do it is considered irrelevant, there is always another better way to do anything. What the underlying issue or problem that we want to solve is not important. The only thing that matters is that if you want to be agile you MUST follow the rules…

To me this is very anti-agile and turns the principles in anti-principles and the values into dis-values.

I think that part of the problem is that the agile manifest is often read superficially. In the above I used principles and values almost interchangeably, like they were almost the same thing. I’ve done it on purpose because it is what I hear very often. But reading carefully the agile manifesto, there is an important distinction between the two. The manifesto says

...Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

And after that:

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

The first thing I would note is that those are the Values. They are not the principles.

Secondly, what the manifesto says is that even recognizing the value of the right side of the sentences, the left part is more important.

The two observations above are important IMHO, because on one side, the agile value system shows you where you should look at when in doubt, on the other side they implicitly express that there is a balance you have to consider between the agile value system and other value systems (customer’s organization, your organization, business constraints and so on).

Where the principles come from then? ehehe, I do not know for which reason, but they are after the list of the Agile manifesto promoters and the copyright information, that is below where you usually would stop reading a web page. If instead you scroll a little, you will see the “Twelve principles of Agile Software” link. This is a very interesting reading, actually I would say the most challenging part of agile development. Those are the Principles and they are quite demanding. They start from putting at the highest priority early and continuous delivery of valuable software, to the delivery of working software frequently, to getting together business people and developers and so on.

The difference between values and principles is that the latter are a kind of normative guidelines derived from the values. I said guidelines because who is serious about software development knows that each team is different, each person is different, each organization is different. Therefore the challenge is always how to apply the agile values in a specific environment, putting in practice at the best in the given circumstances the principles. What’s funny is that I am sure that waving the agile values you could sustain that any of the principle should be avoided. For this reason it is not only important to have the values in mind, but also the principles. When we see a practice that seems in contrast with the values we should also ask why it is in place, and if it aims to achieve any of the principle. If so, we can pic of the two choices: propose how to improve things, or waiving the values and shield our-self behind them…


May 21, 2009 - Posted by | Agile, SCRUM

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: