“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.
Combined Portfolios
Could you have a Portfolio that contains both Operational and Development Value Streams?
No!
Because, as discussed previously in Multiple Portfolios, the SAFe definition is a collection of Development Value Streams; but if we politely ignore that definition then…
Yes!
The caveat being that SAFe won’t provide much advice on how to run the Operational Value Streams within a combined Portfolio. This is understandable as once you move beyond the problem solving of Development Value Streams the options for how Operational Value Streams could be run turns it into an unbounded problem and Scaled Agile need to set some boundaries somewhere otherwise they end up proposing solutions for everything for everyone everywhere. If you want advice on how to run Operational Value Streams you will need to look elsewhere; the only thing to bear in mind is to make sure that whatever advice you follow aligns with the Lean / Agile principles driving the organization, and that core competency of Organizational Agility.
If you consider the SAFe Portfolio as an investment vehicle for Value Streams, then it’s not going to matter whether your investing in an OVS, a DVS, or anything else, it’s just an investment being made. However, for this to work effectively the Portfolio does need to abstract itself out of managing the details and constrain itself to providing the strategy, the investments and the high level changes, the Epics, that are needed in order to enact the strategy.
Figure 1: Combined Portfolios containing both Operational and Development Value Streams
Common Strategy
If the Operational Value Streams are in separate portfolios to the Development Value Streams then there is always a chance that the different portfolios will have different goals. The Strategic Themes try to minimise this by aligning the SAFe Portfolio with the wider organisation but there is always a chance that mistakes and divergence could be introduced.
The advantage of a Combined Portfolio is that everything within the Combined Portfolio is working towards a common strategy, expressed and measured through the Strategic Themes.
Challenges with combined portfolios
The main challenge at the Portfolio level is always a variant of Conways Law, the desire to recreate the past with new words rather than embrace the new and properly change the organisational behaviours to adopt a Lean Portfolio. Allowing Combined Portfolios provides another chance to mistakenly recreate the old world.
What are some of the challenges that might arise?
Operational Value Streams and Participatory Budgeting>
There is limited discretionary spending with an Operational Value Stream; they are primarily comprised of baseline costs to keep them running. If participatory budgeting chooses not to fund an Operational Value Stream then it is suggesting that that line of business be shut down, there may be commercial, legal and HR issues arising from such decisions. This isn’t to say that such decisions shouldn’t be taken, but that they have to be approached with due care and attention.
If Participatory Budgeting decides to fund an Operational Value Stream at less than it’s baseline cost then the Operational Value Stream needs to find the savings to meet that allocated funds. Again there may be commercial, legal and HR issues arising from such decisions. The savings will come from the Development Value Streams enacting changes to the Operational Value Stream to reduce it’s baseline costs, typically automation or optimization of the Operational Value Strea.
Operational Value Streams and Epics
Do Operational Value Streams do Epics?
No and yes.
Epics are change, it’s the Development Value Stream that updates the Solutions that allow the Operational Value Stream to run and should take the lead in enacting the change, the Operational Value Streams do the running and should focus on the running. However, the change is being made to the Operational Value Stream therefore they will need to participate as the change is being made to them. They may also be the originators of the change having identified it through their own retrospective processes and should be providing information and insight to influence the change.
Don’t create Epics to keep things running, that is what the baseline costs are responsible for. Justify the baseline costs by highlighting the KPI’s that the Operational Value Stream contributes to. In the case of Operational Value Streams this will be sales figures, profit margins, keeping production costs under control, the metrics of running the business; even not-for-profit organisations need to manage their running costs.
Separation Of Concerns
Keep the Operational and Development Value Streams separate.
The purpose of the Development Value Stream is to develop, to improve, the Operational Value stream, to provide it with the products, systems and tools it needs to operate. Managing the problem solving involved in enacting change is different from managing operations, the differing concerns are one reason to keep them separate.
Keeping the Operational and Development Value Streams separate provides more visibility between the investment required to keep things running versus the investment required to change. Investing in Change
Operational Value Stream Agility
Whilst the people within the Operational Value Stream must be encouraged to be more Lean and Agile, don’t expect them to follow exactly the same set of agile patterns and processes as the engineering teams within the Development Value Streams that are tailored towards collaborative problem solving.
- For anyone that needs to do forwards plannable work start with the Scrum process, which considers what do we need to do to reach our goals.
- For anyone that has to deal with emergent issues consider the Kanban process, which considers what is the most important thing to be doing now.
- For anyone that is doing exactly the same task repeatedly, as in manning a production line, just do the task!
Even for repetitive tasks the core competencies of Organisational Agility and Continuous Learning Culture still apply. The later competency suggests that even for repetitive tasks those involve should at regular intervals stop and retrospect to see if it could be done better.
One Operational Value Stream does not a Portfolio make
Portfolios are investment vehicles. If the Portfolio is a single Operational Value stream and its associated Development Value streams then those investment decisions are limited to the context of the Operational Value stream. It’s not really investment decisions any more, it’s spending decisions.
The benefits of reuse where one Development Value Stream provides a solution that multiple Operational Value Streams can utilise are harder to achieve if a Portfolio is a single Operational Value stream; there is an increased chance of duplication of solutions.
One option might be to instigate a Portfolio of Portfolios to balance investment decisions across the Operational Portfolios but equally the Portfolio could just be instantiated slightly higher up and Value Streams empowered to make their own spending decisions.
Investing beyond Value Streams
As long as the Portfolio is treating it’s investments as investments and tracking the outcomes, then it could potentially invest in anything that might affect those outcomes.
Investing In Projects
Contrary to popular belief within the Agile world Projects are not evil, just abused. Projects can be as Agile as Value Streams, it’s just that the governance is focused around making a single change rather than being focused around a product with a succession of changes being made to it.
If the Portfolio is all-encompassing, it contains everything, then there may well be projects to deal with truly one-off changes. The example used previously is “an airline building an airport”, it’s going to happen once and only once and it requires a set of skills not found within the airline so run it as a project that is given the money to hire those skills in to get it done, then those skills can be released once the project is complete. Running the airport once it’s built would be an Operational Value Stream and that requires a skill set that the airline will want to retain either as direct employees or long-term contracts.
Another scenario where Projects might be encountered is early in the adoption of Lean-Agile processes. There will be a stage where half the organisation has transformed and is working as Value Streams and half the organisation is still working the old way. The Portfolio has to deal with both old and new. As more of the organisation transitions, the old will eventually disappear replaced by the new ways of working.
The final scenario where Projects might be encountered are the opportunities that fall into Horizon 3 of the Horizons Guardrail. Horizon 3 represents opportunities that might provide a return on investment in a few years, that sizeable time to achieve a return on investment is often because the opportunity requires new lines of business and hence new Operational Value Streams to be set up from scratch. If there isn’t an existing Operational Value Stream there’s unlikely to be existing Development Value Streams supporting it, which means nothing to invest in to get work done. The investment needs to be made into the work and the work employs people to pursue the opportunity and set up the relevant Operational and Development values streams so that they can subsequently be invested in. Whilst investing in the work implies Project Governance, the project can still be run using Lean-Agile processes tracking Lean-Agile metrics.
The challenge here is that it is another point where the old world could be allowed to persist without the necessary organisational and behavioural change occurring. Projects are a useful tool for Portfolios to have in their toolbox but use the right tool for the right job, most engineering endeavours are long term, continual change to a product, and Development Value Streams should be the preferred choice of enacting that change.
Investing In Other Portfolios
A Portfolio could choose to invest in another portfolio within the organisation if it thinks that that investment will have an impact on the outcomes that the investing Portfolio is trying to achieve. The instances where we’ve seen this occur most frequently are typically multi-national organisations where there is a portfolio of common solutions that local, often regional or country, portfolios take-on and customise and adapt to their customers specific needs. In order to achieve their local outcomes a country portfolio would either have to develop everything itself, which would be beyond it’s means, or it invests in the common solutions.
Figure 2: Investing In Other Portfolios
The country portfolios raise their own funds through sales, they have complete freedom of choice in how those funds are invested. The common solution portfolio raises their funds by providing solutions that the country portfolios wish to invest in. A completely free market where the country portfolios invest whatever they want in the common solutions allows the organisation to see exactly where the demand is. If the demand isn’t there a solution won’t be funded; which is a clear indication that it’s not relevant any more. In reality there are usually some guidelines to the country portfolios to ensure that the common solutions receive minimum funding to keep them operational, and to cover any corporate wide changes that are non-negotiable but, wherever possible, the country portfolios should be given complete freedom of choice over how they invest their funds..
The challenge is keeping the transfer of investments at a very high level of abstraction, the investment should be for achieving outcomes, not for doing a piece of work. Maintaining a high level of abstraction allows the common solution portfolios choice in how they achieve the outcomes. If it descends to the level where the common solution portfolio is just doing work for money, then that choice is compromised. The topic of separating funding from work has been discussed as part of Estimating Effort or Expense, it is actually a fundamental principle that allows nested and combined portfolios to exist.
Conclusions
Can you have combined portfolios?
Yes, as long as the portfolio has the discipline to treat everything as investments in outcomes. As always, that comes with a long list of gotchas and anti-patterns but it can work.
Indeed many organisations, particularly the smaller ones, that I’ve worked with already have combined portfolios, even thought they might not be explicitly acknowledging it. They aren’t that big, the Portfolio is already the whole company, so it has no choice but to deal with investing in both the development and the operational aspects as part of managing the whole; there is no point in them treating the Development Value Streams as a separate collection and calling that collection a Portfolio.
Next steps
The above discussions about investing in other Portfolios leads me to start thinking about Portfolio Topologies, investing in Projects reminds me that I still need to cover transitioning Projects to Epics. Lots of places the next post could go, we’ll know which way it goes when we get there!