Like oil and water?
A traditional view of programmes is that they are large-scale, expensive, and managed in a top-down, command and control way. There is a lot of detailed planning to create certainty. The scope is tightly defined up front and then closely managed via rigid change control processes.
To agile aficionados, this view seems like a straitjacket and is the antithesis of an agile approach, where the focus is to get something up and running as quickly as possible and then “inspect and adapt” to refine it, moving towards the business outcome incrementally with priorities set based on business value.
Among programme traditionalists, there is a popular view that agile is “developers having fun”, involves no planning and is completely bottom-up – “we’ll know what it is when we’re done” – and that will take an indeterminate period of time to complete. There is no structure or discipline.
If you look beyond the stereotypes, though, you will see that adopting a programmatic approach to achieving a business outcome has a lot more in common with agile than people might think.
So what is a programme?
A programme is usually a significant investment by a business to achieve a strategic outcome. This business outcome will likely be expressed in terms of a vision – what the future will look like and what benefits will be realised.
For example, if we’re an insurance company, our vision may be to become one of the top three automotive insurers in the US within the next three years. That’s a meaningful goal, but you can’t go and write a 10,000-line project plan, start with the first task, finish three years later, and expect the goal to have been achieved.
Programmes are not simply big projects. The business environment, target state and even the rationale for the investment are highly likely to change during the life of the programme, making it impossible to create “certainty” up front.
But the organization needs to have confidence that it is making a good investment.
Ask yourself the following questions:
- Is the vision clearly articulated and understood?
- Does the vision align with the business strategy?
- Is there a clear sponsor who owns the vision and is accountable for achieving the business benefits?
- Is the sponsor actively engaged (not just a name on an organization chart)?
- Can the benefits be measured in ways that are meaningful to the business?
- How risky is the programme? Is it within the business’s risk appetite?
- What level of investment is required in the best, worst and most likely cases?
So how do you take a big goal and turn it into something that can be achieved?
Well, there’s an old joke that says, “how do you eat an elephant?” to which the answer is “a piece at a time!” In other words, you break it down into manageable chunks.
Programmes are often broken down into chunks called tranches (French for “slices”). Achieving the overall business outcome is like a big rock that you break down into smaller rocks, which are the tranches. It is similar in principle to the agile approach of taking epics and breaking them down into story points.
At the beginning, we can plan a high-level view of what we think the tranches will look like, but we need to accept that the number and nature of those tranches will change as the programme progresses.
We should have a pretty clear view of what the first tranche looks like and a reasonable view of the next couple, but it is normal to have an increasingly sketchy view of the later tranches. The entire programme cannot be planned at a detailed level up front.
Some good tests of whether you are breaking the rocks down in the right way:
- You’ve identified clear business benefits that can be achieved in that tranche. Ask yourself – if we have to wait until the end of the programme to achieve the benefits, have we really broken down the problem?
- You’re planning for a stable and sustainable business state at the end of each tranche. Ask yourself – if we had to stop the programme at this point, could we? Sustainability cannot be dependent on completing further tranches or worse, on completing the whole programme.
- You’ve prioritized tranches so that benefits are achieved as early as possible. Ask yourself – are we making business value-based decisions?
At the end of each tranche, it’s time to critically assess whether the rest of the tranches (and the vision itself) still make sense.
For example, if we’ve realised 80% of the expected benefits after the first couple of tranches, is it really worth pursuing the remaining 20% of the benefits given the costs and risks involved in completing the remaining tranches? Perhaps it’s worth stopping the programme at this point.
Or perhaps the future tranches that we laid out no longer make sense and we should head in a different direction and outline entirely new tranches – in other words, “inspect and adapt”.
Common ground and a shared philosophy
So, if a programmatic approach involves breaking down something large and complex into manageable chunks, implementing business value-based decision making, and embracing “inspect and adapt”, which are all agile fundamentals, is it really true that programmes and agile are incompatible?
Or are agile programmes the way of the future?