The Death of the Programme Plan
One of the values enshrined in the Manifesto for Agile Software Development is “…responding to change over following a plan…” That’s sometimes caricatured as meaning Agile doesn’t involve planning beyond individual sprints. On programmes, that’s an issue, especially when executive sponsors want to know what they’re going to get and when they’re going to get it.
The Myth of the Programme Plan
For those of us that have been around traditional programme management for a while, and who have been a part of large scale business transformation programmes, it’s a depressingly familiar experience to spend large amounts of time and energy explaining to senior executives why a programme isn’t progressing per the plan agreed at the beginning.
The honest answer is often that the plan was based on partial information known at the time of mobilization, and a whole host of assumptions, none of which were ever going to survive encountering the reality of actually delivering the programme.
Critics of traditional approaches to programme planning point to the resulting frequency of delivering poor results late and at inflated cost, a trend that remains stubbornly common. Sadly.
Much better, they say, to acknowledge the degree of uncertainty involved and work with it, adapting the solution as it’s developed. You can’t know everything, so why pretend you do?
The attraction of the Agile approach is clear. Personally, I wholly support the mindset, and approach. Let’s be real; or if not real, let’s be honest. We’re on a journey, and this way we’ll get the best result possible in the time (and cost) available.
However, programmes usually represent major investments for the organisations that spawn them. Often those investments involve more than just finance: competitive positioning, reputation and even organisational survival are commonly considered.
Executives are risking their shareholders’ funds (let alone their own careers), so it’s perfectly reasonable that they expect commitments from the programme team on timing, cost and what is delivered. There are corporate ‘red lines’, which in some organizations, cannot yet be crossed.
We’ve found that the reality of these red lines often makes Agile proponents uncomfortable. But let’s be honest here too: those red lines aren’t going to go away for some no matter how much senior executives buy in to the theory of Agile.
Programmes Aren’t Agile
A programme with Agile components is not an Agile project at large, it’s a completely different animal.
“A programme is a group of projects, subprograms and program activities, managed in a coordinated way to obtain benefits not available from managing them individually.” ( The Standard for Program Management, ©2013 Project Management Institute )
And that’s the point: programmes have multiple components, some or all of which may be delivered using Agile techniques, but the programme is greater than the sum of its parts.
In addition, the programme absolutely must manage its relationship with its executive sponsors, who – as expressed earlier – are reasonably expecting the programme to commit to delivering specifics and almost certainly don’t care whether you’re using Agile or the XYZ method, they just want results.
Squaring the Circle
So, you have a programme. The programme has multiple projects aligned in work streams. Some projects are being delivered using Agile, some are using waterfall or other more traditional techniques, and other projects depend on your Agile components delivering specific things at specific times.
Welcome to the world of ‘adaptive’ programmes. We at Pcubed believe before long, virtually all programmes will be adaptive; a hybrid blend of Agile and non-Agile approaches.
Our experience in helping clients meet their corporate expectations and securing the very real benefits of Agile techniques has highlighted some principles for programme planning, here are the three key ones:
1. You Still Need a Programme Plan
It may be called something different, an Integrated Delivery Roadmap being one option.
This won’t be a rolled-up schedule based on the schedules of each of the components, and it won’t have too many of the milestones beloved by traditional reporting. It’s more likely to be graphical representation of what will (or is intended to) be delivered when.
This is where the corporate red lines meet the flexibility the programme will use to deliver success and maximise the advantages Agile brings. This is the tool used to manage those all-important expectations of senior executives and to demonstrate how evolution of the programme’s solution is delivering (the present continuous used here is vital) a better result.
Is that harder than a traditional programme plan or schedule? Yes and no.
Yes, because the teams involved in the Agile projects within your programme will have to shape their delivery and commit to key outputs more than they would like, and that means backlogs may have to be developed in more detail earlier than they would prefer.
And no, because the comparable traditional ‘programme plan’ tends to be in summary form suitable for senior executive digestion, rather than a mechanical roll up of individual schedules.
2. Shape Your Programme into Increments
As noted above, demonstrating that the programme is delivering value is vital.
Programmes should always be shaped into phases, tranches, or whatever term you choose, rather than being monolithic. Using shorter periods or increments (of about 12 weeks) works well and fits with Agile’s principle of continuous, iterative delivery. I like it and luckily for me it works.
Ideally, the programme should transition some form of release, output or product into the organisation with each increment, but either way, increments provide opportunities to demonstrate the programme’s real progress, and they also provide a mechanism for aligning component plans and setting everybody’s expectations.
3. Align Planning Events and Plans
Programme increments provide manageable iterations for developing backlog detail, embracing and accommodating change and aligning the components of your programme.
Those projects using waterfall or similar techniques can work with Agile components where there are dependencies to align their efforts in the up-coming increment in staged events that bring the entire programme together.
Vendors (who might or might not be using Agile) must be included, and increment planning events can be used to foster integration not only with suppliers but with the (usually) multiple elements of the organisation involved.
This is where some cultural and behavioural (and commercial where suppliers are included) issues must be addressed effectively. For sure, there is a need for compromise. Not all traditionalists understand or appreciate the Agile mind set, and it’s equally true that not all Agile enthusiasts recognise the continuing value of other techniques, so be prepared for some heavy-duty stakeholder management within the programme team, remembering we are on a journey to scaling Agile for transformation programmes.
The End of the Programme Plan?
The answer is somewhat like Mark Twain’s, in response to reports that he had died, “The report of my death was an exaggeration.”
Because a programme is greater than the sum of its parts, some form of reliable, resilient structure and method continues to be necessary to shape its overall delivery and meet the justifiable expectations of corporate executives with accountability for the programme.
What form that programme plan takes and the techniques used to construct, maintain and assure its robustness will be different in the adaptive world, but its purpose remains.
Merryn Hornemann is part of the Pcubed UK leadership team with 17 years’ experience in Programme & Project Management. Merryn specialises in mobilising and leading transformation programmes, and has supported clients in executing their strategic initiatives in M&A, Integration and Digital Innovation. Merryn leverages her experience in future state visioning and application of business change adoption, to derive novel, out-of-the-box solutions for her clients. Merryn has worked across Telecommunications, Financial Services, Manufacturing and Retail sectors. She is SAFe® qualified with experience in integrating both traditional and agile methods and tools.