“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 – Portfolio WIP limits
Previous blogs have explored the decisions that affect the work as it moves across the Portfolio Kanban Board, but for the Kanban Board to be properly formed there should be Policies and Work-In-Process limits in place to ensure the smooth running of the Kanban. In this blog we'll explore what sort of Work-In-Process limits should apply to the Portfolio Kanban and my suspicion is that different parts of the Portfolio Kanban are going to need different styles of Work-In-Process limits. This also provides an opportunity to explore what the different factors are that influencing those Work-In-Process limits.
Figure 1: Portfolio Kanban
The strucuture of the above Kanban board has previously been described in a set of blog posts on the Dynamics Of Decision Making In The Portfolio Kanban. For the purposes of this article the four areas being discussed are the central sections of Review, Analysis, Backlog & Implementation and Success.
Review
The official description of the Portfolio Kanban suggests “WIP Limited" and “pull when an Epic Owner is available".
It is at this stage that the Epic Hypothesis Statement is created. If you are doing Participatory Budgeting they you will need some initial costings to support the budgeting discussions. If you are doing Participatory Budgeting then you will need enough work to fill the budgeting period under discussion, which is going to be a batch that builds up. Therefore, there should be Doing & Done sub-columns, with a tight Work-In-Process on the Review-Doing, and the batch building up in Review-Done ready for Participatory Budgeting.
As space becomes available downstream then Review-Done entries can be pulled across into Analysis. Long term trends are going to be useful here; if the amount of work leaving Review-Done doesn’t match the number of ideas coming in then there will be problems, either overload or starvation; cumulative flow diagrams are a good tool for helping visualise this.
Portfolio Road Mapping also needs a set of Epics with enough information to discuss and reserve space on the roadmap but those activities don’t require a full business case yet. Another reason for having the batch build up in Review-Done for use as in Road Mapping.
| Note: |
|---|
|
It doesn’t matter whether during Participatory Budgeting an Epic is used to transfer funds to the Development Value Streams or not, the Epic only moves into Analysis when it is time to develop the Epic’s Business Case. Separating the Investment Cycle from the Approval Cycle has been discussed in Participatory Budgeting. |
Analysis – In Progress, Done
The description of the official Portfolio Kanban suggests “pull when an Epic owner has capacity".
It is at this stage that the Lean Business Case is developed ready for approval.
It’s not uncommon that the Analysis column is separated into In Progress and Done. Keep a tight Work-In-Process limit on In-Progress, the Done column is the queue of Epics building up for the approvals meeting which often occurs only once per Program Increment, see the articles on Portfolio Events – Exploring The Decisions Being Made for more details of the Portfolio Events. Whilst it isn’t necessary to have an explicit Work-In-Process limit on the queue of Done Epics, it does need to be actively monitored and managed. If the queue is forever building up and never being processed then that’s a trigger that all upstream work (left of this column on the Kanban) should pause until downstream work (right of this column on the Kanban) has cleared out to create space. Again, cumulative flow diagrams will help visualise the behaviour of the queue.
You do need enough people to take ownership of assembling the business case for the Epics; so the initial statement about being pulled when an Epic Owner has capacity is correct. However, not all Epics are equal, some will be big, some might be small.Some Epics might be small enough that a single person could look after several at the same time, others might be large enough to warrant a small team of people managing them. This is very dependent upon the industry and the level at which the Portfolio has been instigated.
Backlog & Implementation
I always used to say capacity limited; but that’s not quite correct. It’s more complex than that because different parts of the Portfolio have different skills and not every train, team or individual might be capable of working on every Epic.
It’s not single piece flow either, that might be an aspiration at the team level, but it’s not going to work at the Portfolio Level, the Portfolio with it’s large pool of people is going to be able to work on more than one Epic at a time without individuals working on more than a single Epic.
There is a U-curve style of optimisation at work, a sweet spot in the middle, but to know what the middle looks like you have to examine the extremes to be able to avoid them:
- If the Work-In-Process limit is high then there will be a greater chance that a given Development Value Stream can contribute to a piece of Portfolio work, but more chance of everything moving very slowly because the fixed amount of effort is spread across all of the available Epics.
- If the Work-In-Process list is low then there will be a greater chance that a given Development Value Stream can’t contribute to any of the pieces of Portfolio Work, but there will be a focus on the things the Portfolio needs to get done.
Figure 2: Work-In-Process Tradeoff
If an Agile Release Train is substantially contributing to more than one or two Epics at a time then they are working on work in parallel and value will be delayed as demonstrated by the Serial/Parallel game played as part of describing SAFe Principle #1 in the Leading SAFE course. There is some subtlety here with the use of the word "substantial", trains may be asked to do a little bit here and there to support other trains working on other Epics, it’s the Epics that this train is substantially working on in its own right that you want to tackle in as serial a fashion as possible.
Lack of Portfolio derived work doesn’t mean that the trains are idle, it means that they have the capacity to do their own internally generated work, from within the train. Agile Release Trains should always have some of their capacity reserved for their work, not just Enablers but work solicited from talking directly to their stakeholders and ideas that their engineers are generating from innovation time. There are many benefits to the trains having more of their own capacity, the engineers know what their systems are capable from an innovation perspective and the Product Management on the Release Train should be closest to their customers to know what those customers want.
The Portfolio Kanban doesn’t help visualise the how many Epics a Development Value Stream is work on, that requires a Development Value Stream perspective. Each Development Value Stream needs be able to say what percentage of their capacity is being spent on each Epic they are contributing to, as well as Internal work generated locally and time set aside for Emergent work such as defects and support. This information is also necessary to close the accountability loop on Guardrail 2: Apply Capacity Allocation to check that the advice given in the guardrail has been honoured.
The metrics can be gathered at different times during the Program Increment (Fig 3). As the Development Value Stream goes into PI Planning it can feed back on the what percentage of capacity has been allocated to each category given the set of work prepared for PI planning. Once PI Planning has been completed the percentage of capacity allocated to each category given the set of work that has gone into the plan can be provided. Finally metrics could be collected at the end of the PI to provide insight into the percentage of capacity for each category given what the teams actually worked on.
Figure 3: Capacity Allocation Collection Points
Guardrail 2 : Apply Capacity Allocation is meant to provide intent to the Development Value Streams as to where their time should be spent, to ensure that there is a good balance. The Development Value Streams don’t need to be, and probably can’t be, exactly honouring the suggested percentages, it’s the intent that matters. If the guardrail suggested 70%/30% and the Development Value Stream ends up at 68%/32% then that’s close enough, they’ve honour the intent. If the Development Value Streams ends up at 88%/12% then there might need to be discussion as that has deviated too far from the intent.
The following examples show 4 separate Development Value Streams that are contributing to 4 Epics as well as Emergent (support, defects, etc…) and Internal work.
Figure 4: Development Value Stream Capacity Allocation Table
Figure 5: Development Value Stream Capacity Allocation Charts
- DVS W: The Development Value Stream's effort is focused on a single Epic, Epic 3, alongside it’s own Internal work as well as some effort set aside for Emergent work. This is the “good" scenario but slightly theoretical because there will likely be demands from elsewhere, which is illustrated by DVS Y.
- DVS X: The Development Value Stream's effort is evenly split between the 4 Epics, which means that work is being done in parallel and the lack of focus will mean everything takes an age to complete. This is the “bad" scenario, questions should be asked as to why they can’t focus on just one thing.
- DVS Y: The Development Value Stream's effort is substantially dedicated to Epic 2, with a small amount of effort contributing to the other 3 Epics. They’re maintaining their focus by substantially working on just one Epic but at the same time being good corporate citizens by helping others that need support on the other Epics. This is the “good" real world scenario.
- DVS Z: The Development Value Stream isn’t contributing to any Epics, all of it’s effort it devoted to Internal work and Emergent work. This isn’t necessarily a problem, maybe it doesn’t need to contribute to any Portfolio Epics and instead can concentrate on keeping its own customers happy through its own internal work. Internal work can be Business requests from Product Management within the Development Value Stream as much as it is Enablers from the Engineering staff.
As always get beyond the metrics, the numbers are just there to trigger conversations. Talk to the people involved to find out the real story behind the metrics.
Success
There’s no need for an explicit Work-In-Process limit here; these are just the Epics whose engineering effort is over and the Portfolio is watching the metrics so that the Portfolio gains insight into whether the Epic eventually succeeds or fails.
The one thing to watch out for here is the number of items in Success is forever increasing. Typically, this happens because the Epics aren’t being successful but the Portfolio isn’t willing to admit that they’ve failed and therefore just leaves them going in the hope that they might eventually reach success; they won’t. If an Epic doesn’t substantially achieve it’s Business Outcomes within the expected time period, it’s failed, categorise it as such, close the feedback loop and learn.
Conclusions
The Work-In-Process limits at the Portfolio limit aren’t as simple as stick a number on the column and work to that, there are instances where it is deliberately necessary to let batches build up ready to feed the next timebox and it's the balancing of the inflow and outflow over time that is more important than an absolute limit.
Whilst the Portfolio Kanban is an important visualisation tool for tracking progress of the work, to truly understand whether trains are doing work in parallel the Portfolio will need to visualise the work from the perspective of those trains. Close the loop of Guardrail #2 : Capacity Allocations.
Figure 6: Suggested Work-In-Process Policies
Next Steps
I still want to explore Enabler Epics but there might also be a quick detour into why there isn’t a Definition-Of-Done for Epics.