Title: The Agile Manifesto Explained (and a First Amendment)

Why are individuals and interactions important?

An organisation, team, or group are made up of individuals. In order for the team, group or organisation to 'work together' and meet common goals they have to interact. The nature of how they interact, and the efficiency of the interaction, can severely affect the performance of that team. Thus, it is worth spending effort making the interaction effective. Now, some would argue that processes and tools can improve the quality of interactions. I have sympathy with such an argument for I think so too.

So why are process and tools less important than individuals and interactions?

In a nutshell "Tools support the process and the process supports the interactions of the individuals". That's why they are there.

In a team of one, or a collocated few, you can get away with out much in the way of a process, and the minimum of tools to build the system. As the number of people involved, the complexity or size of the information, the number of locations where the individuals are, the number of time zones,… grows, defined processes and tools can help to stay on top of the situation.

A danger is that a tool might grow to control the process and/or the process may grow to control the interactions of the individuals. Is that a bad thing? Well it can be if it reduces the value that is provided to the business by the interactions of the individuals. But there are often cases where a tool controls a process and adds significant value. For example, if your configuration management is complex a well chosen tool that drives the process can prevent a myriad of problems. As a second example, Extreme Programming [Beck] encourages heavy use of tools and process: "You will perform daily builds; You will run all automated tests suites; You will…"

So, defined process and expedient use of tools is not a bad thing. So I'll ask a different question. Why are individuals and interactions more important than process and tools? Sorry that is the same question. How about, how can a process or a tool reduce the value? Or better, how can a process or tool make it harder to add value?

At the heart of the problem is the fact that consultants and software vendors (including those of an Agile persuasion) make their money by selling processes and tools. It is, perhaps, too easy to take a process and/or set of tools without consideration of the benefits that they can supply and without later seeing whether any benefits have been supplied. To me this is the real purpose of this beatitude - think hard before committing to what can be expensive tools and processes. Very often an efficient team can improve the process at less cost.

The moral: Tools support the process and the process supports the interactions of the individuals - and don't you forget it!

Well obviously - duh! That was my reaction when I read this and I would not be surprised if it was yours - so why include this bi-attitude in the manifesto?

This time I'll start from the back end. Why have a go at comprehensive documentation?

So many processes get carried away creating comprehensive documentation and end up creating too much documentation. The creation of that documentation adds cost to the work and introduces latencies to feedback making it harder to respond to change and harder to collaborate with the customer. The documentation often duplicates information again adding to costs and latency of maintaining the information in two places. The excess of documentation, if not maintained is soon out of date diminishing its value. And oh even worse, out of date documentation can obviously cause problems making its value negative. In short much of the documentation either:

So there are a few reasons why documentation may not be needed. But what documentation is needed? I'll put that another way. What deliverables provide long term value?

Requirements define what is needed from the software. Software is working if it fulfils the requirements. Tests are used to prove the requirements are fulfilled. In my mind that is what really matters in software development: requirements, software and tests.

So what is all this comprehensive documentation malarkey that the Manifesto refers to? It is High level designs, technical designs, user interface design, standards, use case models, class diagrams, architecture….

Between us we could probably name a hundred different types of documentation. Why do we need any of it? In my mind there are two key purposes: understanding and communication.

When you are faced with a new system you want to be able understand how you are going to solve the problem. You will be analysing and designing a system. This is the forward engineering part of your work.

If you are not working alone you will want to communicate this incite to others. The number and nature of individuals you have to interact in order to make this communication will influence the nature and amount of documentation created - but remember to consider how much will need to be maintained.

In order to understand how you are going to solve the problem you will need to understand what is already there. And you will want to communicate this understanding to anyone who, in the future, wants to evolve the system. This is the reverse engineering part of the work. In summary it is an art of:

To conclude, the manifesto is warning us against a costly pitfall in which we strive to provide comprehensive documentation that does not provide value.

To me this is the hardest bi-attitude to argue in favour of convincingly but I'll try - starting with the supplier consumer model that this alludes to.

The supplier consumer model for software development has a simple but entrenched form. The consumer wants a system that does abc. The supplier says that will cost you £xyz (or $xyz or €xyz or…). If the consumer is happy with the cost the supplier, well, supplies. Oh if only it were that simple!

In practice the definition of abc are not really known AND, even if the definition of abc where known, the cost £xyz is not, AND even if the requirements are understand there is a reasonable chance that they will have to change, AND even if the costs are understood there is a reasonable chance that the costs will change AND… It would be easy to rant on. I'll emphasise these perils by putting (some of) them in a list:

This last point is interesting. Even though it is difficult to be precise in your definition of requirements, the consumer will not be happy parting with (or committing to part with) money unless they know what they are going to get. Equally the supplier will not be happy committing to deliver until they know what they are supposed to produce. So in order to be sure of what they are going to get/produce they define a contract. And then hope it is fulfilled.

So what is the alternative?

The problem, in my opinion, is that the requirements are part of the contract.

The solution is Feedback. This simple notion is so important I will say it again - and louder. Feedback!

Instead of defining requirements fully up front and incorporating them into a contract, the contract does not specify the requirements at all (or at least not very much). Instead it specifies the approach. An approach that gives both parties opportunities to adapt to the perils listed above (and others not listed) while protecting the interests of both parties. The work is then split into iterations. During each iteration, the consumer and supplier work together to find out how best to give value to the consumer for the money that will be spent during the next iteration. It is a very simple proposition but it seems to work very well.

Short iterations allow BOTH parties to get FEEDBACK and examine whether the requirements have been understood. If the requirements change, the change can be incorporated into the next iteration.

Since the contract defines the approach it doesn't have to change. But it can have a clause in which the consumer can terminate if value is not being provided or if they have enough value so far. This may not appeal to some suppliers but early drop out clauses could be introduced. Forgive me, I am acutely aware that I am not a lawyer and my contract speak is unlikely to be correct, but I hope you get a feel for how it could work.

In summary, the contract defines the approach, the requirements are defined by collaboration between the consumer and supplier, feedback is used to help both parties provide maximum value to the consumer.

And you never know everyone could be happy.

A project manager, when presented with this bi-attitude might say. "If you don't follow the plan how will you deliver?" or "If you don't follow the plan your project will deteriorate to anarchy!"

But there is a simple counter to this: "If you follow the plan how do make sure you are delivering what is needed?" Or put another way: "If you don't respond to change, how are you going to deliver what is needed? - You may deliver something but that something may not be needed anymore."

Change is a major obstacle to delivering what is needed - a major obstacle to providing value to the business. Many things can change during the life of a project:

I could easily list loads and loads more, anyone one of which could render the plan invalid.

Let me get one thing straight. Planning is not a bad thing. Planning is a good thing. It is such a good thing that you should do it all the time. The problem is sticking to the plan rather than adapting the plan, re-planning, in the face of change.

The morale:

If you are going to plan, plan often. That way it will be easy to make sure you are providing value to the business. If you are going to be planning often you need an approach to planning that is a low overhead to the project.