Agile Manifesto: It's the principles that bind us

Anyone who has taken even the slightest interest in Agile probably knows that it is based on a manifesto that has four core 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"

Followed by the caveat:

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

The great thing about the manifesto is that it is short and sweet. Even I can remember it. It's a simple set of values that people can keep in the back of their mind when making every day decisions. The problem with these values is that they are very loose and open to misinterpretation. Looking at the values for the first time, one might be tempted to start investigating agile software development further, but how to begin? That's the question.

Perhaps you should buy a book on agile? There are plenty available. A common approach, I know I was guilty of this once, is to get your hands on a book like Extreme Programming Explained by Kent Beck, read it from front to back, pick out the things that you think are interesting and start banging on about this being agile development. Maybe it is, maybe it isn't, that really depends on how well you understood the book and how open minded you are after reading it.

Maybe you know someone in another company who is "doing agile" that can help? You could seek out an agile consultancy to get you started. You could, he says holding his head in his hands, just stop documenting things, throw out any plans for the next few months, get a few people together and start cranking out code. See how far you get.

Let me make a suggestion. After reading the manifesto, click through to the following page titled Principles behind the Agile Manifesto. Read the twelve principles there. Consider them. Chew them over with some friends and colleagues. Savour them like a fine wine. These are the guiding principles that help give context to everything else that you might read or hear about agile.

If you don't agree with these principles, if you can find no common ground with the way you want to work and these principles, then stop. Leave agile software development well alone. Find some other way, and whatever you do, don't call it agile! Oh, and if you do find a better way, please let me know.

Agile software development is a nebulous thing. Mainly because it is a philosophy rather than any methodology. Yes there are methodologies that adhere to the agile philosophy, but it is entirely possible for a team to be using one of these methodologies and not be adhering to the agile principles.

Let's consider a Scrum team that doesn't write automated unit tests. Can they be agile? They are following the Scrum practices of regular product increments, using burn down charts, performing a demo and reflecting at the end of each sprint. They are using all the tools provided by Scrum to help self organising teams find the best way they can of working together. So, given this and the definition of agile taken from the values of the manifesto, who can say this team is not doing agile software development?

Well, after considering the principles behind agile software development, I'm willing to go so far as to say that there is a very good chance that they are not very agile. Here is my line of reasoning. One of the principles of agile states:

"Continuous attention to technical excellence and good design enhances agility."

I don't know how, or am not smart enough, to design and code everything correctly first time. I have to rely on refactoring to improve my code, and this is where I need automated unit tests. I can't reliably refactor my code without good unit test coverage and so I can't follow the principle of technical excellence and good design without them.

The reason I hedged my bets in the statement about the agility of this particular team is because I can't know everything about their approach, and they may have a very good way of ensuring good design and technical excellence without refactoring and unit tests. I doubt it, but I remain open minded.

If we can agree that agile software development is a philosophy, rather than a methodology, with a set of guiding principles then I believe we have a much stronger foundation for handling the increasing interest in agile adoption. These shared principles give more substance to the agile manifesto and can help identify situations where teams following agile methodologies end up failing where teams adhering to agile principles would have succeeded.

NB. Please don't consider my use of Scrum in the example above as an attack on the Scrum methodology. In the example above it is the collective team that I consider to be failing to adhere to the agile philosophy, rather than Scrum not being a suitable vehicle for agile.