If you are preparing for the PMP^® exam you will notice that the Project Management Institute has become very interested in agile, or iterative and incremental methods. We expect to see this reflected in the PMP^® exam, so we need to know something about agile and the thinking behind it.

On this page:

• The Agile Manifesto: Principles and Controversy
• Value People and Interactions over Processes and Tools
• Emphasizing Working Software over Comprehensive Documentation
• Prioritizing Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan

The Agile Manifesto: Principles and Controversy

Agile methods started to appear in the software industry in the early 1990’s and they claimed to address two issues that had plagued the industry since its emergence in the 1960’s: (1) software was being employed in more and more industries, meaning that the computer experts were meeting a very diverse range of clients from areas that the software people had no experience of; (2) if the client needed to make a change during the execution stage of the project, it caused major upheaval – often requiring the entire product to be redesigned from scratch.

But how did these problems lead to agile project management methods? To try to find out, a good place to start is in a ski report in Snowbird, Utah. Back near the turn of the century, all the agile pioneers gathered there with a view to coming up with a single, grand, unifying methodology that they are could promote together. This effort proved to be a disaster – no one could agree on anything. That is, until someone asked the question: what is the goal of your method; what is its underlying philosophy? From that moment on, to the surprise of the delegates, there was a realization that they were all singing from the same hymn sheet.

So impressed were they at finally reaching agreement that they published their philosophy, calling it The Agile Manifesto. Although only four lines long, this proved to be an extremely controversial document. It was framed as four statements, all with the same format: We have come to value A over B. However, people who saw the manifesto interpreted these statements as reading: we want to do A not B and promptly dismissed the movement.

This is a pity because there is a lot of good sense in these four lines and it is well worth while for any project manager to take a closer look.

Value People and Interactions over Processes and Tools

The first line declares that the agile people value people and interactions over processes and tools. Simply put, this is making the statement that, to write good software (or indeed to execute any sort of project) you need good people. Ironically, good software developers tend to be disciplined; they tend to follow a given process, or even make one up if a process is not specified. They also love technology and will happily develop the necessary tools to support the project. Interestingly, the converse is not true. If you take the civil service approach and prescribe a project management process and supply the necessary tools, you will not get away with hiring second-rate people. So indeed, your people are your most important asset in any project.

Emphasizing Working Software over Comprehensive Documentation

The second line is the really controversial one: we have come to value working software over comprehensive documentation. When people read this, they dismissed the manifesto as a hacker’s charter interpreting the line as: we do not want to do any documentation. This is a pity, because what the agile people were trying to articulate was an obvious flaw in the way traditional Waterfall or V-Model project life-cycle models work. In these, a lot of time is spent tying down requirements before we move onto specifying the software. If it is a big project, we will spend time on architecture and high-level design. Then we move to detailed design, before reaching the coding phase. Even then, we are likely to need an integration phase before we have working software we could demonstrate.

The important thing to realize is that non-technical managers and non-technical customers cannot understand any software project artefact other than working software, so we need to get this on the table much earlier in the development cycle. Otherwise, we will not be able to get any useful feedback from our customers.This is true of other disciplines as well. Modern Computer Aided Design (CAD) software allows three dimensional renderings to be made from the traditional plan, elevation and end-view architectural drawings, allowing potential customers to “walk” through a building design and imagine what it would be like to live there. Virtual Reality makes this simulation even more convincing. It is much more difficult to imagine the finished product from the drawings alone.

Prioritizing Customer Collaboration over Contract Negotiation

The third line expresses a preference for customer collaboration over contract negotiation. If you are preparing for the PMP^® exam, you will know what the Guide to the Project Management Body of Knowledge (PMBOK^® Guide) has to say on risk management and will appreciate that uncertainty is at its height at the start of any project. Being aware of this, the agile people ask: why insist on tying the customer into a legally binding contract at the precise point when the customer is not sure what it wants and the development team is not sure what to deliver? Surely, it must make sense to build up a mutual understanding of what the finished product looks like over time, rather than commit too early in the project?

It is understandable though. Change is a disaster in traditional software development life-cycle models. But our solution to the problem is to insist that the world stays still for six months, twelve months, eighteen months – however long it takes to complete the development project. We are effectively demanding that the customer’s needs cannot change, the market cannot change and technology cannot change. Unfortunately, this is not the case in the real world.

Responding to Change over Following a Plan

Which brings us to the last line in the manifesto: we have come to value responding to change over following a plan. Whatever method you use, it needs to be responsive to change.

By focusing on people, evolving understanding and an awareness of change, the agile philosophy makes perfect sense for projects where uncertainly is high. If The Agile Manifesto itself is not enough to convince you that agile is at least worth a look, consider that an Agile Practice Guide is bundled in with the 6th edition of the PMBOK^® Guide. Indeed, the Project Management Institute itself offers an Agile Certified Practitioner (PMI-ACP)^® accreditation, and is promoting its own agile approach, called “Disciplined Agile”, indicating that these methods are certainly being taken seriously in the project management profession.