The foundations of project agility
The Agile Manifesto – the foundation of agility
‘Bilbo?the?silly hobbit started?this affair, and?Bilbo?had better finish it, or himself.’ So said Bilbo Baggins in the Lord of the Rings, volunteering to take the Sauron’s ring to be destroyed in Mount Doom. Then Gandalf the wizard reminded Bilbo that he only played a small part in the ring’s journey, saving him another rather perilous one.
In Agile Beyond IT I remind readers that neither did the Agile Manifesto, with its software development origins, ‘start’ this matter of agility. Evidence of agility, both formally and informally exists way before 2001. I recognise informal examples in my own experience from around 1987. Yes I am THAT old.
Yet for me, the Agile Manifesto provides a coherent description of what agility means. Many criticise it as being insufficiently useful, being only 4 values and 12 principles. But wait a minute, the Project Management Institute (PMI) have made another 12 principles the core of its latest BoK7. The Agile Manifesto is the foundation of agility, not the entire building which is for others to construct. As I seek to do for project management agility in Agile Beyond IT.
In this article I will list the 12 principles of the Agile Manifesto and then outline my adaptation of them to the sphere of project management in ten principles.
The Agile Manifesto
Here are its 12 principles:
In addition to its principles, the Agile Manifesto also reflects four values.
In Agile Beyond IT I provide interpretations of each of the above principles and values. In part drawn from my own experience, but also from other people and writings. The problem with principles is that they are open to interpretation, ask any theologist, or for that matter, economist! For example, iteration seems to be taken as a bedrock of software development agility. And yet it does not appear in the Agile Manifesto, any more than Humphrey Bogart said ‘play it again Sam’ in the film Casablanca.
Adapting the Agile Manifesto to projects
I did think about simply re-creating the material from my book, but I (hopefully) want to leave you wanting more. So here I paraphrase part of Chapter 1, starting with the values of ??project agility.
In the end it is people that deliver projects, not processes or tools. Agility places at least as much importance on people and how they behave and relate as it does to process. In the project context those behaviours and relationships are both inside the project, and between the project and its organisational landscape. E.g. will the organisation delegate sufficient authority for the project team to self-organise and make decisions?
Projects are about delivering stuff, which when used/exploited return benefits of some kind. This does not mean NO documentation. It does mean that judgement is needed to ensure that the ‘stuff’ is delivered AND just enough of the means to use it. Which usually means some form of instructions. If in doubt, also remember why you are doing the project.
Collaboration is at the heart of agility, win-win is the game. A zero-sum (win-lose) culture is toxic to agility. Which is why I say in the book that project agility is not for every organisation.
For many in the software development world, this means a free-for-all. Even there it is rubbish, let alone in the project context. Where change is fine, as long as it enhances or at least preserves the benefits due from the project. And does not break the bank. Too free an attitude to change risks fragmenting the project and wrecking benefits delivery.
Having adapted the four Agile Manifesto values for project management, now let’s turn to a view of how the 12 principles can be adapted to projects.
Principles of project management agility
These principles, my 10 to the Agile Manifesto’s 12, drive the mindset of teams and individuals, from the project to the executive. Given that projects exist to deliver value/benefits, this is where we will start.
As a callow project management youth I was taught that projects were about delivering stuff. Much later as head of customer projects at Cable & Wireless my mantra was that our projects were not successful until; [1] the customer gained benefit from what we had delivered to them, and [2] we got paid! Projects have business cases (well mostly), and need to produce enough to make the case viable. This can be called the Minimum Viable Product.
However you express it; Value, Benefits, whatever. What a project delivers MUST result in something beneficial, preferably measurably. And agility in the project context means the team must always have this in mind and keep it there when decisions are being made.
Its not enough to build a car, is it driveable? Is it affordable in its market? Is it a pig to maintain? Is it saleable?
领英推荐
Being customer focused is very much a sign and the commercial mantra of our times. Project management agility is no different. I have separated it from focus on delivering value because projects and especially programmes have stakeholders. Some will be customers for whom the value is being delivered. Other stakeholders may be impacted by the project, such as householders living near the proposed route of HS2.
Assessing satisfaction is mostly via project controls which show progress. Project agility requires that to be openly, provably done, i.e. tell me and show me. Irrespective of life-cycle, a project must be able to demonstrate regular real progress. Even if it is only: here is this bit, it works, look… OK… next! There should be an audit trail from goal to proven output.
Role clarity in projects is nothing new. Project agility adds the dimension of flexibility. If necessary and perhaps for short periods of time, role flexibility can be beneficial. For example, when a team member is away on holiday and another team member can step into their role temporarily, then that is being flexible – that is agility.
Agility also requires commitment from senior roles, especially the sponsor, to a high degree of engagement with their project.
Just enough is at the heart of agility. ?A project needs to be literally just good enough in all of its respects. I.e. not just what is produced but also how the project is managed. For some this carries connotations of not good enough but from a qualitative quality management sense just good enough literally means good enough but no more.
Why build a rolls-royce when a mini is called for?
This is one of the most difficult aspects of agility for projects, as mentioned under values above. Traditionally change within a project is often fought against and rejected as far as possible.
Being agile means being more open to change during a project, but remembering the focus on value. Any proposed change must enhance the value being delivered or at least maintain it.
‘No man is an island entire of itself, Every man is a piece of the continent.’ So wrote poet John Donne in 1624.
‘Traditional’ (sorry Adrian Dooley), or rather ‘long established’ project management has focussed mainly on what happens inside projects, programmes even portfolios. That’s fine and dandy but project success also depends on what happens in the surrounding organisational hinterland. Project management agility requires a supportive landscape to thrive. If you cannot provide such, then agility, project management of any other type, will probably be strangled at birth. Just one example is the level of sponsor engagement.
Organizations often claim to empower teams and individuals, but this is much more difficult to demonstrate.
Agility means that the project is empowered properly by its governance landscape and it also means that the project leadership both delegates authority and encourages individuals and teams within the project to act on that authority. It is also about creating an atmosphere in which people feel they are able to speak up to make suggestions, be creative or challenge, to speak truth to power. They feel that they can take decisions rather than sticking their heads above the parapet waiting to have them shot off.
Collaborative behaviours are another aspect at the heart of being agile.
Earlier I stated this means that all parties involved support a win-win relationship. This requires openness about what each party needs to achieve to gain reasonable benefit from the project. Especially with customer–supplier relationships.
Collaboration must be built into every aspect of how a project will operate, from its procedures and working behaviours, to schedules in contracts between a client and supplier organization. N.B. Collaboration does not mean that everyone gets involved in everything.
Can agility survive if parts of a team do not work collaboratively? The edifice starts to shake…..
Project reviews have long ?included learning lessons from a completed project, and even during a project. The introduction of stage gates formalized lesson learning. But all too often lessons tend to be recorded but not used. Hell is paved with good intentions (Samuel Johnson).
Agility suggests two levels of actions to make this work. Agile project teams work closely together, sparking off each other and there is openness both to sharing an idea or lesson, and to receiving them. ‘Someone might just have a better way of doing this than me…’. At the organizational level, perhaps led by an enterprise PMO, there’s a mechanism for capturing and sharing learnings. But the learning culture also needs to be developed.
Quick wins we need quick wins! Is a common cry in projects. It keeps stakeholders happy but often just stores up trouble for late in the project. Agility suggests addressing the difficult, the complicated stuff as early as possible, if you can. The idea being that once you get past that hurdle the rest should be easier, lower risk. In other words, if you are on the road to nowhere, get off it as fast as you can.
This is true of project management agility itself, if you and your organisation are not making it work, stop. But if you can, there are some wonderful sunlight uplands to behold.
Good luck on your journey!
Adrian Pyne