Open Project Management - Manifesto for Agile Software Development

The following is the original Agile Manifesto (

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

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

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

It's pretty simple but very powerful if you are able to apply it. It can also be easily mistaken and used as an excuse to avoid doing any management. Let's look at each of the values.

Individuals and Interactions over Processes and Tools

It's all too easy to get caught up in the dogmatic debates over which tool should be used for capturing requirements, version control, project planning, editing, file transfer, etc. These arguments are often distractions from what matters, i.e. getting the job done. The tool you use doesn't really matter as long as it works.

Similarly, processes can get in the way. There are some people who will follow a process or procedure to the letter, without thinking, or even worse, when the result actually hinders the project. There are times when the process can get in the way, and it's more important to get to the point. That's when talking to people is the key.

Rather than going through a formal business case proposal, sometimes it's far more useful to pick up the phone and call the project sponsor and ask a question. It's quicker and to the point. That doesn't mean we forget about documentation—we definitely want to document things, but ask the question face-to-face, then write down the answer and get confirmation that you've captured it right. That's using interaction over process and will get you much better results.

Working Software over Comprehensive Documentation

On the surface, this contradicts the importance of documentation, which is often lacking in projects and can cause problems. This value isn't saying that documentation is not important, but, when it comes down to a choice between finishing a project with a working outcome and incomplete documentation or the project being overtime but with full documentation, I'm pretty sure I know what the project sponsor is going to choose.

Once again, that's not to say documentation is not important; it's a question of what to value more and given the failure rates of projects, actually delivering the project on time is an achievement in itself. Documentation, if it's really important to the client, can be completed after the project has been delivered. Mind you, most of the time, this approach means the documentation never gets finished. But, if the project has been delivered—how much does it matter? Sure, later it becomes an issue, there's no argument there, but at least you've gotten to that stage where most projects don't.

Customer Collaboration over Contract Negotiation

I've been involved in many projects where the site has gone live around the same time as the contract has been finalized. That's not to say it's the safest way to manage a project; it's not. The purpose of the contract is to ensure that responsibilities and deliverables are clear, as well as providing a framework for resolving issues should they arise. If you have a good relationship with your client and are able to resolve things amicably, a contract is more like an insurance policy should things go wrong. The idea is to not let things go wrong in the first place; that's why there's greater value on customer collaboration rather than contract negotiation. If you're spending more effort working on clauses in a contract, you're not focusing on the project and delivering a working site. The contract is a part of the process, no doubt, but it shouldn't take precedence over dealing face to face with your client to work things out.

Responding to Change over Following a Plan

One of my favorite quotes is from Dwight Eisenhower; he said "plans are useless but planning is indispensable". Being the good project manager, I used to produce detailed Gantt charts using MS Project until I realized that the project never turned out the way I planned it. Now I know that they almost never will. Creating the initial project plan is an important process to capture all the tasks required, the ideal order in which they should be done, and most importantly, to identify dependencies. However, what's captured in the initial project plan and how things happen in reality are often quite different. As President Dwight Eisenhower stated, "Plans are useless but planning is indispensable".

The purpose of the plan is to know what you are deviating from when you have to make a change. Change is inevitable, there's no point in fighting it. The best thing to do is simply accept it and work out how best to manage it. That doesn't mean you let the client change things at the drop of a hat—every change has its ramifications. And because you've planned out your project at the start, you know what those ramifications can be, and can let your client know what the change means. If a client asks me, halfway through a project, if they can change something, the answer is always yes, as long as the client is willing to change the timeframe and budget, accordingly. That tends to keep things focused!