Think beyond iterations with Agile roadmapping
Value Streams represent the flow of value through the organisation and to the customer. When mapping our Value Stream we can understand the various routes by which we create and deliver value to our customers. In this article we look at how we represent the Value Stream and how we use a roadmap.
Value Stream and backlog
Planning using backlog is powerful because it is a single source of the data which enforces prioritisation in a clear and unambiguous way.
Our value stream roadmap works as a backlog at a higher level of abstraction. In our team backlog the elements are items such as Stories and the timeboxes are Sprints. In our value stream, the elements are value stream items such as Features.
A single version of the data and of priorities is key to success. So I should be clear that the value stream is not an independent backlog, but a different view of the same data, using “features” to give a higher abstraction level. A feature may contain many backlog items.
Because Value Streams and Backlog share many characteristics, we can reuse much of the language and techniques we have elsewhere described when discussing backlog. Where we have taught the teams about backlog, we can reuse the same concepts when extending to value streams and roadmap. This common approach and language really helps with rolling out the value stream concept around the orgainisation. Remember that shared language really counts.
All we are doing is looking at the timeline from the moment a customer gives us an order to the point we collect the cash.
Taiichi Ohno
And we are reducing that timeline in the value stream by removing non value-added wastes.
Timeboxes
We can consider the value as flowing continuously from the organisation to the customer along the value stream. This is a representation of the lean concept of “Flow” (and why the term “flow” works so well).
In a team backlog we will plan and deliver the backlog using timeboxes – iterations or Sprints. Similarly the roadmap will be separated into timeboxed phases of development. Each of these will end with a batched delivery of value to customers. Traditionally in software development these batches would be fairly large and infrequent. This is changing with a greater focus on SaaS products and continuous deployment.
Between 1990 and 2021 there were 20 versions of Microsoft Office, or around one every year. This can be considered a “traditional” delivery model. With Microsoft Office 365, while minor changes and fixes may be made more frequently, there were 33 versions in the first six months of 2024. This represents a 60x increase over the original annual cadence. These versions are grouped into monthly “formal” batches. The pace only increases. Amazon reportedly made 50 million deployments (across multiple platforms) in 2023.
Does Agile require batching?
It’s a good opportunity to address one point of confusion over Agile development. One of the Principles is as below. There is a huge gap between the “couple of weeks” below and Amazon’s 50 million deployments a year. This is one of the places where I feel the Agile Manifesto does show its age.
You could read this as saying that it isn’t Agile unless it is in two week batches. However, that would be a mistake. The Principle is that small batch size improves flow. This remains valid, even though the example is dated – SaaS software with multiple deployments a day simply wasn’t an option when the Manifesto was written.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Principles behind the AGile Manifesto
Most organisations will tend to use a similar model of “formal” delivery points with published scope in timeboxes. Functionality is developed over the timebox. Code may be available in production continually (the typical model for continuous deployment). Alternatively the code moving to the production system may be batched (the typical model for continuous delivery).
Remember that every work item is shippable when completed, whether or not it goes immediately to production, with the Definition of Done ensuring deliverable quality. The formal release is primarily a communication tool – a point in time where customers are aware they have new capabilities.
Releases
I tend to refer to these batched delivery points as “Releases”. The term “Increment” is also used (especially in SAFe). I prefer to avoid the term “Increment” as it can confuse. In Scrum an “Increment” applies to the updated product after each Sprint (remember it is releasable, even if not released) rather than at a later formal release point. Also “Increment” and “Iteration” are confusingly similar words, especially if English is not your first language.
Releases allow the organization to discuss progress on the value stream both internally and with customers. As with all Agile planning, releases should generally be timeboxed. Classical projects typically deliver to an (approximately) fixed scope and use plans to predict and track schedule. To allow for the uncertainty level of complex environments, Agile development ensures flexibility around scope. Our planning and communication around commitments allows us to maintain that flexibility.
Managing roadmap like backlog
One key challenge with a roadmap is how to manage the change and uncertainty inherent in the complex environment. Any well managed backlog is always changing through backlog refinement. Priorities change, learning is added and items move up and down the order.
The items at the top are well understood (as agreed in the Definition of Ready) and can be worked on. We estimate the work items in the backlog to get a rough idea of how depth in the backlog relates to time. When we start a Sprint, we set a goal for what is important to achieve in the Sprint and choose a set of backlog items to work on. This gives us the key components of Agile planning:
- Prioritisation – understanding the desired order of work to maximise value
- Estimation – an idea of how fast we might move down the backlog
- Timeboxing – setting expectations for the next timeperiod.
When working with an agile roadmap, a similar approach is taken.
Prioritisation
As with a backlog, we maintain the roadmap in priority order. We expect to focus on the top items first. As we avoid parallelism, this means we expect those items to be delivered first. However, we also expect and manage change in priorities.
Compared with a team backlog, the level of change in priorities is expected to be lower. The value stream items are bigger and a change in priority implies a greater impact. There is more likely to be partially-complete work remaining, meaning waste from Work in Progress. A robust decision making process is needed for value stream prioritisation.
Estimation
As with a backlog, we estimate the value stream items. However, uncertainty levels will be very high. We can use relative estimation to suggest that a feature is a similar scale to a past feature, but estimates will be very imprecise.
Timeboxing
We create a timebox for the roadmap representing the next release point. To make this effective we would like to understand what we will deliver in that timebox. But here we have a challenge.
How do we plan a roadmap?
Many organisations struggle to manage roadmap effectively.
The timebox is far longer than for a team backlog. There could be 1-3 months between releases, while only 2 weeks in a typical iteration. And estimates are far more imprecise. Although estimates may be approximate for far off backlog items, those in the next iteration will be fairly well understood.
With an agile roadmap we expect and manage a high level of change
This combination of longer timeboxes with less well understood items is a challenge to many organisations. Many organisations try and make release timeboxes predictive with significant initial planning. This is for example a central part of the Scaled Agile (SAFe) approach.
One outcome of the PI (Program Increment) planning is a set of PI Objectives, detailing what the ART should have ready to demonstrate at the end of the PI
Scaled Agile © Scaled Agile, Inc.
There is a subtle balance here. Although more predictability has value to the business, software development is complex. To get a more predictive roadmap, we would need to plan out every feature in advance (as in a project and as SAFe does to a degree).
Having invested in that planning, we now incur waste if we change priorities. We have planned work which we will not deliver, which is clearly waste. Most importantly, Agile environments are complex, and reductionist approaches are generally not effective. Initial planning does not typically substantially reduce uncertainty.
Limited commitment planning
We need a way to manage our roadmap which does not rely on trying to make the features predictive. There is a simple but effective pattern to do this using three steps:
- Prioritisation – we order the roadmap so that we have the features in priority order
- Focus – we work through the roadmap items in sequence, minimising parallelism
- Commitment – we commit only to the top features in the list
Imagine we have a 12 week release timebox. We have a roadmap of items which will each take the team between 1 and 3 weeks to complete. We could spend some of our 12 weeks trying to plan all the items to better predict how long they will take. But we would plan items which we do not deliver, and invest precious time for a doubtful increase in predictability.
We can instead place all our items in priority order. We can be pretty confident we’ll complete the top four. On average we’ll manage six and of course we could complete twelve, but it’s unlikely. We can tell customers with reasonable confidence that the release will contain the top four items and (probably) other value which is uncommitted. We aim to deliver as much value as we can, but we commit only to what we have confidence in.
It is very important to defer public commitment to exactly which features will be in the product, because this makes it possible to reliably release the product on time.
“Leading Lean Software Development” – Mary Poppendieck
The release date is guaranteed, but the exact features are not. Timebox — don’t scopebox.
Good practices
Language is as always the starting point, so ensure you have agreement here. What are you going to call the timeboxes for value streams? Releases, increments or another term?
You will need to ensure that the Product Owner (or other business representative) maintains an ordered roadmap of features. A key part of this is to ensure everyone is aware and uses this reference. Ruthless prioritisation is just as important here as for backlog.
A decision making process to manage change will also be important. Not because you want to resist change but because you want to “harness change for the customer’s competitive advantage“.
Finally you will need to promote limited commitment planning. This will be a challenge to implement. People may want to promise far more features to customers than this approach allows. They may want the team to attempt to produce a far more predictive plan than is possible. You will need to explain the limitations of planning and delivery in a complex environment. However, if you can get the whole organisation to understand this approach you will be able to work at a sustainable pace.
Leave a Reply