The subject of Agile Project Management, and why organisations are attracted to it, is an increasingly frequent conversation with and among my customers. And yes, I do realise Agile is, at heart, a philosophy and mindset rather than a Project Management Methodology, but it is habitually purchased and deployed as the latter. De-risking change and getting it delivered more quickly, being fleet of foot and maturing organisational resilience are all cited as reasons why Agile Project Management is being invested in so handsomely. But almost equally as frequently, my customers describe the challenges they face with Agile. Here is the challenge my customers raise with me most commonly: do you recognise it and have you found a way to tackle it in your organisation?
Lack of definition of change project outcomes
In our project work, decades of research tell us that changes that impact people have to be viewed as a process, rather than an instantaneous, click of the fingers, event. Prosci describes this process as a move from a current state (how an employee, partner or associate does his or her work today, before the change has landed), through a facilitated transition, to a future state (how the employee needs to do his or her work once the change has landed). Other change management thought-leaders use different language to describe this process but the notion of a defined future - the outcomes we are shooting for - is common. And yet, so many of my customers recount examples of projects being embarked upon where, because the project is to be iteratively designed, developed and deployed using an Agile Project Management approach, they have been advised that the future state does not need to be defined upfront. What intrigues me about this is that there is nothing in the Agile Manifesto, nor the principles that underpin it, that recommends or even suggests that an articulation of the future is redundant.
Without some definition of the new capability my change project is aiming to deliver for the organisation, how can I construct even the most basic investment or business case for it? How can we make the cost/benefit case? Without some notion of what it is, how can we possibly know that we are on track, and how will we know when we’re done? Don’t think me naive, I fully appreciate and have experienced first hand how the “fail fast to learn fast” and “sprint-drop-learn-sprint-drop-learn” iterative nature of Agile means that we are developing the new capabilities as we go, but where I have seen Agile have the greatest success, those iterations are on a clear path to an articulated future state. The concerns you share with me are that without the outcomes defined, even at a high level, Agile changes risk meandering and delivering sub-optimal outcomes and disappointment, albeit more quickly.