What's all this Fuss about Agile?

19 June, 2013

If you are preparing for the PMP® exam or have already taken it, it is unlikely that you will have studied agile project management methods. So you might think that these are not legitimate strategies. Indeed, back in the early 1990’s, when agile project management methods started popping up in the software development world, they were greeted with an element of cynicism by practitioners. The reason for this is because agile methods are iterative and incremental project management strategies and these approaches had already been tried back in the 1970’s and 1980’s without gaining much traction. So the feeling was that agile project management was just a rebranding of an old idea, the flogging of a dead horse.

But is there any substance to these new 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 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.

The first line declares that the agile people value people and interactions over processes and tools. Simply put, this is making the statement: 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.

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 then 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.

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.

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 that agile is at least worth a look, consider that agile is listed among the valid project lifecycles in chapter 2 of the 5th edition of the PMBOK® Guide – see the section called Adaptive Life Cycles. Indeed, the Project Management Institute itself offers an Agile Certified Practitioner (PMI-ACP)® accreditation, indicating that these methods are certainly being taken seriously in the project management profession.


By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital