On The Nature Of Portfolios
“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.
Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation.
I first sketched out some ideas for discussions about the lifecycle of Epics around 2 years ago when this blog first started. Those ideas have evolved as other explorations have evolved as the series has explored other topics but now it’s finally time to get something on paper, or its electronic equivalent. The concept that is driving the next few posts is the separation of state from process. An Epic has a series of states that it goes through in its lifecycle, which should be explored. Processes do work to move the Epic between it’s states, so those processes should be investigated. Typically those processes are visualised on what is known as the Portfolio Kanban board so exploring how that behaves is another topic.
Kanban boards visualise process, and by making the process visible through visualisation they are invaluable at helping manage that process. The challenge comes when the processes change, how can you measure whether improvements have been made when the process that is being measured is now different? The new data points are not directly comparable to the old data points. You could measure from a step before where you changed to a step after where you changed; but what if those steps are also changing? Where are the points of stability to measure from and to?
At Ivar Jacobson International our work on Essence and SEMAT has led us the realisation that it is the States of the thing being manipulated, in this case an Epic, that are the points of stability, and that allows the process, or series of processes, that move the thing between states to evolve and change without affecting the measurement points of when the thing enters and leaves a state.
What are the states that an Epic goes through?
I started thinking about this 2 years ago, admittedly other topics, as well as the day job, have consumed my time and brain-power in the intervening months. What I started with at the beginning is not where the states are now, there has been an evolution from the exploration of the other Lean Portfolio Management topics. The mantra repeated by my colleagues that have more knowledge of Essence than I is; “Separate state from process.” This derives from the observation that it may take many little processes to enact a change of state on an item and equally some processes, particularly inspection processes don’t change the state at all. If state and process are separate then you can assess whether alternate or evolved processes might enact a state change quicker and easier, an important consideration in Agile organisations where evolution of the processes is a desirable attribute to help meet business needs.
The tyranny of naming
Names must be chosen; have I picked the right names?
Almost certainly not. Could I have picked a better name?
If I could, I would.
The names that I have chosen are the best I can do at this precise moment in time. They now need to be tested in the heat of battle to see whether they survive or fall. I will not mourn those that fall, they are just names; it is what they represent that is more important.
This isn’t a green-field endeavour, lots of information already exists from which to draw upon, so the journey stated by examining the existing Portfolio Kanban proposed in SAFe. The Portfolio Kanban maps out the sequence of processes that move an Epic through its lifecycle, the question is which of these imply a state change and which do not?
Additionally the lifecycle of Features and Stories have also been mapped out in Essence; the details of Features can be found in the blogPreparing Features for PI Planning - What Does it Mean for a Feature to be Ready? As you can see from the scribbled notes in the bottom right corner the Feature lifecycle was a source of inspiration since they do follow a similar pattern.
With the above as input a first sketch of the Epic states was drawn up:
After drawing up the initial set of state I embarked upon an exploration of budgeting and road mapping; which led me to wonder if there is an additional state that I hadn’t identified at the start. What was driving this line of reasoning is that Epic ideas need to be processed to the extent that they can used for Forecasting and Road Mapping, but neither of those activities need a full Business Case, that’s only required for Approval.
What would this extra state be called? It’s the end of the Review process in the default Portfolio Kanban, but “Reviewed” isn’t particularly descriptive as a name. Mapped? although not everyone does road mapping and the road mapping activity actually happens once the Epic has reach this state. Scoped? Bounded? Understood? But they are ambiguous terms that could mean anything and certainly something like Scoped could be easily misinterpreted to mean “build a great big work breakdown structure” which would drive the wrong behaviour.
Forecastable? To be able to be forecast, therefore can be used in budgeting and road mapping.
The more that I think this through the more that I am convinced that there is this extra state and that the evolution of SAFe’s Lean Portfolio Management, where Participatory Budgeting was added after the Portfolio Kanban, means that the description of the information that is needed to support Participatory Budgeting hasn’t been properly integrated into SAFE’s process descriptions.
The idea for the Epic has been captured, in that we know who suggested it, the source. It has got a meaningful name to help anyone involved understand what it is.
Some sanity checks to ensure that it is truly an Epic, i.e. not a story, nor a feature, if it were a Story or Feature then the idea should be routed straight to the relevant backlog.
Relevant is another sanity check to ensure that silly ideas are discarded. Either the idea aligns with the Strategic Themes that are guiding the Portfolio or there are some other significant factors that warrant it’s consideration. The latter clause would be utilised by enablers that arise from within the Development Value Streams, usually as the result of an I&A session, and should be considered by the Portfolio even though they might not contribute directly to one of the Strategic Themes.
In the Funnel is a reference to the fact that it has been captured in whatever tooling is being used to record items in the funnel. Re-reading this a week later the tyranny of naming and words strikes, “In The Funnel” is a very odd set of words, if you didn’t know that the SAFe Kanban board starts with a column called Funnel it wouldn’t make sense. “Captured in tooling” might be a better, more generic, phrase.
The Epic can be clearly described means that there is enough of a description to be able to discuss it during Participatory Budgeting or Road Mapping sessions. The Epic Hypothesis Statement would provide enough detail. You don’t need a full Business Case for budgeting purposes; if the idea isn’t funded then any effort put into the Business Case has become waste and could have been utilised elsewhere.
Why not ask “Has the Epic Hypothesis Statement has been filled out?” If you have decided to evolve your artefacts and move away from an Epic Hypothesis Statement then the state description would still hold. The Epic Hypothesis Statement is just a suggestion for how to record an Epic there are many other ways that could capture similar information. Separate State from Representation from Process. If you are evolving away from the suggested representation then ideally any chosen format should hold true to our principles and be Lean & Agile rather than substituting an old-world artefact and transplant all the bad behaviours that come with the old-world artefact.
In order to Road Map or Budget effectively we need to know which Development Value Streams are expected to contribute to this Epic. Whilst the detail has yet to be discovered and documented, there is still often enough information in the description to inform an educated guess about which Development Value Streams will need to contribute.
Initial Effort Estimates. How much effort is each Development Value Stream going to need to contribute. Enough detail is needed that an accurate amount is reserved when Budgeting or Road Mapping, but extreme precision isn’t required because all the estimate is going to be used for is reserving capacity in the Budget or on the Roadmap. Effort devoted to increased precision is liable to become waste if the item isn’t Budgeted or doesn’t fit onto the Roadmap and there is always a possibility that the precision leads to bad behaviours such as up-front-design.
Achieving this state allows the Participatory Budgeting and Road Mapping activities to happen, what it doesn’t do is say that they have happened because not everyone determines their budgets in this manner and not everyone develops road maps.
Allocating money to a Development Value Stream so that it can do some work in the future doesn’t change the state of the Work Item, the Epic, that caused the Development Value Stream to get the budget. Giving the Development Value Stream the money doesn’t mean that the work will be done, it’s business case still has to pass and newer work that is yet to emerge might be considered more valuable and be allowed to consume the allocated budget instead.
The Epic has a Clear Owner that will champion the Epic at the Strategic Portfolio Review in order to gain approval.
To be ready for Approval the business case must be understood, and for cost vs benefit of the business case to be validated there also needs to be some form of technical impact analysis since this will inform the effort/cost estimates.
Key activities that need to have been completed are do we know how the Business Outcomes will be measured to track progress towards success and any Leading Indicators to provide early insight into whether this Epic is Viable.
Feasible is a sanity check, do we have the skills, resources in place to do this work.
Cost-of-delay, if the organisation doesn’t pursue this idea what is the impact to the business. Use of the Weighted Shortest Job First prioritisation mechanic for Epics has been discussed extensively in a series on blog posts on the Portfolio Use of Weighted Shortest Job First. This information will be needed to be able to prioritise this Epic against others.
In the default SAFe Portfolio Kanban this point is halfway through the Analysis column, which also encapsulates the act of approval. The lack of separation between the analysis activity and the approval activity on the default SAFe Portfolio Kanban can be problematic because the visibility between the Doing, the analysis, and the Done, the batch of analysed Epics awaiting approval, is lost.
The idea has been approved and Development Value Streams should start working on it. It’s priority against the other Epics that have been approved needs to be understood to allow the teams to make sensible judgement calls in their own backlogs as to which Epics work should take priority.
There are always arguments in Essence circles about whether an approval is a state change or an inspection; inspecting something doesn’t change its state. In this case I am arguing that it is a state change because before the change teams wouldn’t be creating work to fulfil the Epic, after the change they will create work to fulfil the Epic.
What the linear state progression doesn’t show is that Epics can be abandoned at any time. If the Business decide that they don’t want, don’t have the capacity for, or that the Business Outcomes aren’t being met, then the Epic should be abandoned.
The challenge with the state based approach is that when an item is in a given state the processes that are occurring are the processes to move the item to the next state. In this instance when an Epic is in the Committed state the work that the teams are doing are the experiments to prove that the idea is Viable, the next state. It’s not a difficult challenge, you just need to remember to look ahead.
This is where Lean Start Up behaviour is embodied. The first goal is should be to prove that the idea is viable, that it’s going to work both from a business and a technical perspective.
The early experiments are often described in the Leading Indicators; metrics and measures to give the organisation confidence that it’s doing the right thing before it commits to further effort. These should have been proven.
Viability Proven, Risks under control. There’s probably a great big philosophical discussion to be had around this, because the earlier checks of “Leading Indicators Proven” and “Viability Confirmed” are themselves just forms of risk mitigation. I’ll take a Belt and Braces approach and include it as well.
Priority understood; the information from the experiments run may influence the priority. Particularly business experiments, such as customer surveys, may find that the customers aren’t as interested in this as the organisation thought they would be and therefore the idea should be de-prioritised.
Always remembering to look ahead, if the Epic is in this state the work that teams are doing is to get it do the Extracting state. This is state, Viable, is where most of the work will be done not to prove that it’s Viable, that was done in the preceding state, but to build out the functional of the product itself.
The engineering is done and the Epic waiting to achieve its Business Outcomes. For non-engineering spaces make appropriate substitutions for the engineering phrase. I felt “Work” was too generic but I’m beginning to think that it might cover more situations particularly as Epics, being Business Change, are more that just Engineering.
It’s important to know when the Epic has reached this state because true Business Outcomes, the value, often lags behind the work that was done. The Epic cannot declare success yet, but it is no longer requesting effort from the Development Value Streams, therefore doesn’t need to participate in budgeting and forecasting activities.
For true Business Outcomes to be seen, the Epic needs to be In Use.
Whilst the work may be done, the Epic Owner needs to continue gathering the metrics and measures of the Business Outcomes to show progress towards those Business Outcomes and, hopefully, eventual success.
The Epic has met its Business Outcomes. Success.
I’ll fully admit that it’s not perfect; this blog series has always aimed to show the thought processes as much as it shows the final results. I already know that I’m not happy with the sequencing of some of the checks on the cards. I need to encompass “abandonment” in the states since stopping work is such a key part of Lean Portfolio Management. It’s a decent starting point and my suspicions would be that as we explore more of an Epics lifecycle and look at the decision processes then that will cause us to revisit the Epic states in a later article.
To take a look at the Portfolio Kanban and how it can be used to support decisions about Epics as they progress through their lifecycle.