“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the Solutions within Lean Portfolios but an exploration of the Problems to understand whether the Solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
Portfolio Forecasting & Road Mappingt
Previous blogs explored the topic of using Weighted Shortest Job First and the conclusions drawn were that WSJF alone is not enough to manage a Portfolio; other activities are necessary to allow a Portfolio to make informed decisions. The Weighted Shortest Job First algorithm also requires supporting activities, particularly the Time Criticality component of WSJF can’t be assessed without an understanding of timelines and for that a Roadmap is required.
The focus of the next few blogs is Portfolio Level Roadmapping. This first blog will look into the Why? and cover some of the challenges that Portfolio Level Roadmapping faces; later posts will cover some practical facilitation techniques and look at Epic roadmaps.
Why Do We Need Roadmaps?
Forecasting
Every business has deadlines; points in time by which certain outcomes need to have occurred. Those deadlines could be an absolute point in time such as a regulatory deadline, or could be implied through other measures such as when the start-up funding runs out. Either way the business wants to know whether those outcomes are achievable before the deadline.
The roadmap is, given current knowledge, the intended sequence of future work. The items on the roadmap don’t need to be detailed, a name and an estimate are enough to populate a roadmap. Combine the estimates in the roadmap with information from teams and trains around how much work they can within a set period of time and forecasting becomes possible.
Forecasts are used to ratify whether the outcomes and their associated dates are achievable. This is vital when the Outcomes for the Portfolio are initially being negotiated, if the outcomes can’t be achieved then the workforce will realise they’re impossible, won’t try to achieve them and become a demotivated workforce that just “works” rather than having purpose.
Forecasting also allows the teams and trains within the portfolio to limit their commitment. It is very difficult to commit to things too far into the future, the volume of work is often too large, the risks and unknowns too great for any commitment to be meaningful. Additionally, committing to too much compromises agility, because in order to embrace any future changes the commitment will have to be broken to accommodate the required change. Forecasting, repeatedly, using the roadmap to check that work can be done before the deadlines, gives the organisation confidence that the deadlines can be achieved, or an early warning that they can’t be achieved so that corrective action can be taken. Confidence in the forecasts allows the commitment to constrained to just the next timebox, the Program Increment.
Preparing for the future
Enablers
“What do we need to do now in order to be able to deliver the requested business functionality efficiently in the future?”
The architects and engineers can only answer that question if they know what’s in the future; the Roadmap provides that insight.
Any form of internally generated work, is always easier to advocate and prioritise if there is a clear link to value. For Architectural and Infrastructure enablers that should be a clear link to the future Business functionality that they will support; creating the enablers in response to upcoming work on the roadmap automatically provides that context.
Work-In-Process Limits
The roadmap can also be used to visualise whether the Portfolio is trying to do too much at once.
Sheer volume of work is one aspect, but the Portfolio alos has to consider whether it has the right skills in the right places to undertake the work. It will need to look at the skills required by Epics and the capacity of the Development Value Streams with those skills and check that there aren’t going to be bottlenecks. Capacity can be a constrain until investment is moved towards the relevant Development Value Stream, but investments move slowly as described in Mananging Investment with Value Streams.
Inputs to Participatory Budgeting
When discussing Participatory Budgeting, it was observed that the inputs for Participatory Budgeting don’t need to be that detailed, a name, a brief description and an estimate for the amount of investment needed to do the work. That is an similar level of detail to the items on the Roadmap, having an idea of what we think we want to do in the future can be used as an input to the budgeting process. This is another feedback cycle, the outputs of Participatory Budgeting are going to influence the roadmap because the proposed budget becomes a constraints on what can or can’t be done which will need to be reflected in the roadmap.
The Challenges With Portfolio Roadmpaping
Lean-Startup
Lean-Startup can quickly invalidate a roadmap when the hypothesis of an experiment proves to be false and it alters direction that the organisation is heading.
There is no simple fix for this other than embracing the mindset inherent in </a href=”https://www.scaledagileframework.com/assume-variability-preserve-options/”>SAFe Principle #3 : Assume variability, Preserve Options; the roadmap is going to change. That doesn’t mean that roadmaps aren’t useful, organisations still need to forecast and predict, even a lean-startup organisation needs an idea of what steps are potentially ahead of it but those steps will be rewritten repeatedly as new information uncovered. The mistake is to treat the roadmap as a commitment, rather than forecasting tool that it is.
The next blog will cover the practicalities of Portfolio Roadmaps, one practical thing to help with the Lean-Startup challenge is to think of the roadmap as a decision tree rather than a linear sequence of events.
The “Roadmaps aren’t Agile” argument
There nothing inherently Agile or un-Agile about roadmaps; they’re just a tool. It is people that are Agile, or un-Agile, in how they utilise the tool. If someone turns the roadmap into a queue by creating a commitment around the contents of the roadmap then that will limit the agility of everyone whose work is covered by the roadmap. It becomes very difficult to embrace change, or choose a different approach to reach the desired outcomes, when the work outlined in the roadmap has been fixed through a commitment.
When you read the SAFe article on roadmaps did you spot the word “intent”?
In an Agile environemnt every roadmap acts as an illustration of intent for achieving the Vision over an extended period of time, but it can, and probably will, change. Since it is intent rather than commitment change is easier.
The next blog will cover the practicalities of Portfolio Roadmaps, one practical thing to help with the “Roadmaps aren’t Agile” argument is to construct the roadmap in terms of “Outcomes” rather than “Work To Be Done.”
What Next?
Practical advice on How To Construct Roadmaps.