The Agile PM Revolution
With any new approach, there will be those that think it’s the best thing since sliced bread and equally there will be those that think it’s just a fad that will pass just like every other fad, and there are those that simply don’t care. When it comes to the agile project management, everyone should be paying attention because it really does matter. It’s not just the latest in management fads it’s a wake up call for an industry that has an awful track record and is in need of serious help.
So, why is agile important? How is an agile approach to project management going to help where the PMBOK doesn’t? The simple answer is that it deals with the issues in projects that really matter. Every project has it’s unique challenges and you can’t expect to take exactly the same approach each time and expect the same results as no two projects are identical. So what can we do? What does really matter? That’s what agile project management focuses on.
The best way to understand what matters most is to go back to the source of agile project management, the agile manifesto. This is where it all started and where we find captured what really matters.
It’s important to note that the Agile Manifesto is not a method, it is not a set of processes and procedures that we must follow. That’s where a lot of the confusion arises when people talk about “agility”. There’s the assumption that if you follow a particular method or process that has been labeled as “agile” then you are being agile. That’s not true. The agile manifesto defines a mindset on matters when it comes to building software, and therefore what matters when it comes to agile project management.
Let’s start by reviewing the manifesto itself.
"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 which is where it’s power lies. There are no statements that you must do this, or you should never do that. It states that in a given situation, individuals, working software, customer collaboration and responding to change will help us to better develop software, which in turn means delivering better results – the entire goal of project management.
Individuals and Interactions over Processes and Tools
It's all too easy to get caught up in the dogmatic debates over which process or 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 to managing the situation effectively.
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, but then again, the failure rate in projects is already high so starting any project is risky in itself! 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. The plan itself is useless, it doesn’t pan out that way, but having done the plan, the planning process is incredibly valuable.
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!
In summary, the agile approach to project management is not about throwing out the processes and procedures as defined in the PMBOK. The key is to make sure that we focus on what is going to give us the best result. Sometimes that will mean talking to people face to face rather than relying on a particular process or tool. Sometimes it will mean actually building working software rather than completing every element of documentation. Sometimes it will mean starting a project before the contract is nailed which although risky can at times give you a greater chance of success. And finally, sometimes it means throwing out the gantt chart and managing the change that inevitably arises in a project.
Taking an agile approach at times can be against conventional wisdom, that why agile project management is not just an evolution but a revolution, for the better.