What do we mean by ‘agile’?

Dr Peter Parkes provides a guide to agile project management, and addresses some common misconceptions

Many people think of agile as a toolset. But in the words of the chairman of the Agile Business Consortium, Steve Messenger: “Agile is more about mindset and behaviours than method and tools.”

The cause of confusion perhaps arises from the adoption of particular methods for software development which come with some terms foreign to the project, programme and portfolio management lexicon. But put these aside, as they are variations at a working level below the management layer. In fact, the agile project manager carries out similar functions to the traditional project manager, including high-level planning, stakeholder management and communications, risk management, and so on.

What agile does differently is accept and embrace the fact that change is inevitable and estimates are just that. Hence, rather than attempting to do a big design phase up front and lock down scope, agile adopts a ‘just enough’ approach. Rather than pretending that the three cornerstones of the ‘iron triangle’ – time, cost and quality – are immutable, an agile project manager agrees when things are needed and what the budget is, and then flexes delivery. We are able to do this by prioritising a consolidated wishlist of all stakeholders’ hopes and dreams using a technique called ‘MoSCoW’.

‘Must-have’ requirements are defined as the ‘minimum usable subset’, without which the project does not meet the business case in terms of usability or regulatory constraints. ‘Should haves’ are defined as requiring painful workarounds if not delivered. Hence, they are likely to need implementing in later delivery increments, while the ‘must haves’ can go live.

And the ‘could haves’? There are business benefits and return on investment on these in the business case, and so omitting them does not make good business sense unless we have run out of allotted time and money – hence the initial comment about agile being about mindset. We always deliver on time and to budget, and flex functionality according to a prioritisation agreed with the business up front.

A second feature of agile is that it is an iterative approach. That is, unlike in traditional waterfall methods of planning where we might still be in the design phase due to delays when we run out of time or money, we aim to deliver through several deployments, with new features and benefits being realised within each release. Within each increment we also ‘time-box’ build and internal testing and assurance so that we have a cadence to delivery. We can talk about methods for stakeholder management, but I believe that regularly seeing delivery of features when they were promised, and at the cost we agreed, is the best message to restore confidence against a backdrop of project failures.

There is also a popular misconception that adopting agile means a hands-off approach to governance. Indeed, with regards to the development teams, the project manager should be hands-off, with the team appointing its own leader on a first-among-equals basis. With agile, business representatives and testers form part of the team, and the concept of self-managing teams has its roots in lean manufacture. In terms of leadership style, agile requires a ‘servant-leader’, which can be thought of as an inversion of the traditional management pyramid, with the leader being there to ‘grease the wheels’ and minimise disruption to the team.

Although traditional projects are also supposed to have a sponsor (APM Body of Knowledge), agile cannot start without one, as they own the business case and agree prioritisation of requirements. APM has recently released a guide on the governance of agile projects, Directing Agile Change, which of course places the sponsor at the heart of oversight. Because agile teams embrace the concept of visual management – that is, displaying key information on walls in chart format rather than burying it in physical or electronic folders – oversight can be literally that, coming along to daily ‘stand-up’ progress meetings and seeing exactly at that point in time where the project is. These progress meetings take less than half an hour.

Similarly, although agile requires a trust-based organisation to function, it recognises that assurance is a governance principle. APM’s Assurance Specific Interest Group released guidance on assurance of agile projects this year.

You may note that I have referred simply to ‘agile’ in most of the above. This reflects the opening quotation from Steve Messenger that agile is about mindset and behaviours. As well as at the development and project level, there is guidance and examination at the programme level. But what you must have first is an openness to behaving in an environment of trust and empowered teams through development of an agile organisation.

Dr Peter Parkes is a certified practitioner in AgilePM and Agile Digital Services. He is the author of NLP for Business Analysts and NLP for Project Managers