Notes:
But in writing that down we've missed out the first step: that of writing down the context and identifying the forces. For the “key values” to be a valid solution they need to resolve the actual forces. Without a context they could be taken to recommend doing away with tools, process, documentation, contract negotiation and planning. That would be absurd (and nothing I've read of the material written by the signatories suggests differently).
Before adopting an “Agile” solution we should ensure that the context of our project and the forces we need to resolve are a fit for that solution.
I've worked on a project where no two developers built the software in the same way – the tools and process varied. Even with good people on the project this led to problems. I don't think that any of the agile adherents would claim that I was wrong to introduce standard build processes and tools to the project. So, already assumed as part of the context is the existance of tools and processes and the force being addressed is treating the tools and processes as the end and not the means.
I've worked on a project where there was no documentation of what the program does, or how it does it. Even the function names were unhelpful – being based on whim. (OK I did work out that any functions with “Sharon” in their name had been originally written by Russ – and that any with “Jane” in their name had been written by Pete, but that wasn't helpful in working out what they were there for.) There is a need to communicate the purpose and structure of the software, the force being addressed is pursute of documentation beyond the point at which it ceases to be useful.
I have never worked on a project without a contract in place, but it once happened to a colleague. He was somewhat unhappy to find that a significant proportion of his last three years work was never invoiced or paid for. Contract negotiation is an essential part of ensuring that both parties get what they need from a project. The force being addressed is that overspecifying how these benifits are to be delivered can prevent more effective solutions being adopted.
Planning is essental: one needs ensure that things are ready when they are needed and that things are not started before they are possible. I've seen people arrive on a project to find that thereis no desk or computer for them, and that there is no work ready for them to start either. Alternatively, I've seen plans that detail daily activities months in advance – and which diverge rapidly from reality because it is too much work to update them. Planning is essential, but a plan is only a way to prepare for the future, and must be flexible enough to accomodate reality when it arrives.
Rather than being the answer to everything, the key values of the Agile manifesto assume a software development environment that has already reached a basic level of sophistication. (And one that is better than many organisations that I'm aware of.) But they do have value: they are a necessary correction to the calls for ever more heavyweight processes, more documentation, detailed contracts and more planning.