“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, with this specific article looking at how to structure our portfolio events. 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 Events
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.
Previous posts have explored the states that an Epic progresses through in its lifecycle and the decisions that influence the Epic as it progresses through the Portfolio Kanban.
- Epic States
- Portfolio Kanban – Normal Scenario
- Portfolio Kanban – Alternative Scenarios
- Portfolio Events - Exploring Decisions Being Made
In this series of posts we will explore the Events that either perform, schedule or track the activities that affect the operation of the Portfolio. The previous post explored the problem space: what are artefacts being manipulated and the activities to manipulate them? This post will develop a set of scheduled events that performs the activities where group decisions need to be made and validates whether the proposal fits together properly and covers the problem space.
|
Ceremonial aside During an Implementing SAFe training the other week I got caught up in a side discussion about how someone didn’t like the phrase “Ceremonies”. They pointed out that although people regularly talk about the Scrum Ceremonies, in the Scrum guide they are described as events. “Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Regularity, same time and place, that feels like ritual and ceremonial behaviour. Ritual can be bad, because it doesn’t encourage experimentation, it can encourage you to do the same thing time after time regardless of whether it’s valuable. Ritual can be good, because the repetition ingrains the behaviour, everyone knows how things should work. The challenge is that if the process becomes the ritual then the ritual locks you into the process and improvement of the process to increase value can be challenging. If the ritual is to achieve the outcomes then pursuit of the outcomes becomes ritualistic but allows freedom to adapt the process and the work products that represent the desired outcomes. The agile cadence of Sprint/Iterations every 2 weeks encourages ceremonial behaviour, but it must be tied to the outcomes. The outcome ritual is that every 2 weeks there is an increment of value. To support that we want to run a feedback loop to validate that the increment really has produced value. Which means that every 2 weeks a plan is needed to get through those 2 weeks, every 2 weeks progress must be demonstrated, feedback solicited and adjustments made to future plans. How those outcomes are achieved can be evolved; but lose those outcomes and the whole process collapses. |
Portfolio Events
Using the suggested SAFe events as a starting point for each of the events we can now ask:
- What decisions does it need to make?
- What information does it need?
- Where does the information come from?
- What frequency?
These can now be answered through facts gathered in the previous analysis.
Strategic Portfolio Review
What decisions does it need to make?
- Vision
- Set of approved Epics
Vision
Determine the vision for the Portfolio as whole. Ultimately this needs to be expressed as
- a set of measurable outcomes that the Portfolio wishes to achieve within a specified time period, usually expressed in the OKR format
- a set of measurable metrics that the Portfolio can use to validate whether it is running effectively, usually expressed as KPIs
Set Of Approved Epics
Determine the set of approved Epics which provides the Development Value Streams with intent on what they should be working on. This involves decisions that move Epics out of the Viable state towards Extracting or Success which declares the engineering over and stops the Development Value Streams from working on the Epics, and decisions that move Epics into Committed or Viable which provides the Development Value Streams with an indication that engineering efforts should be focused on these Epics.
Information is needed from the Epics about their progress towards their Business Outcomes and Leading Indicators. This informs the decisions around moving Epics towards Extracting or Success, or even abandoning the Epic entirely.
The Portfolio Vision provides the outline of the strategy for what the Portfolio should be doing and informs which Epics should progress towards the Ready state and have their Lean Business Cases developed. The Portfolio Vision comes from earlier Portfolio Sync activities.
Setup & Frequency
Development of the Portfolio Vision informs the Set of Approved Epics which in turn should influence the Portfolio Vision as the Epics declare Success or are Abandoned when it becomes clear that the hypothesised value isn’t materialising.
This could all be done as a single meeting, but combining it into a single meeting means that there would be no time between deciding on the vision and determining the set of Epics that will realise that vision. No time, to elaborate business cases for the new Epics deriving from the vision. You could change the strategy in one PI and then see it realised in the set of Epics at the event in the next PI but this would lead to an unacceptable delay and breaks the goal of Lean; “value in the sustainably shortest lead time.” Which leads me to suggest that the Strategic Portfolio Review might be better split into two separate meetings, the first focusing on updating the vision and the second on determining the set of Epics for the next timebox. The gap between allows any new Epics to be elaborated if necessary.
The Strategic Portfolio Review (Vision) focuses on updating or creating the Vision. To do that it needs input from the last set of PI reviews and PI plannings to understand what was completed in the previous PI and what the teams think they can do in the current PI. It needs to happen far enough in advance of any Epic approval to allow the building of an Epic Lean Business Case ready for approval. This would position this event somewhere within the first Iteration within the Program Increment. It’s output is an updated Portfolio Vision. Given that this meeting occurs once per Program Increment it doesn’t need to be a quick meeting, indeed I would suggest that the discussions around the Vision are likely to last the best part of a long afternoon, perhaps 4hrs.
The Strategic Portfolio Review (Epic Cancellation & Approval) focuses on the set of Epics that should be in-play for the next Program Increment. To do that it needs input from the Portfolio Vision to provide insight into what Portfolio is trying to achieve so that Epics can be assessed against whether they will help achieve that vision. It needs input from the Epics themselves, either in the form of Business Outcomes and Leading Indicators to support the continuation of the Epic and avoid cancellation, or a Lean Business Case for those Epics seeking Approval. It needs to happen far enough after the Strategic Portfolio Review (Vision) to allow for the Lean Business Cases of any new Epics to be created but far enough in advance of the PI Planning events to allow Features to be created to realise any newly approved Epics. This would position this event somewhere within the middle of the Program Increment. It’s output is a Prioritised Set of Epics. Given that this meeting occurs once per Program Increment it doesn’t need to be a quick meeting, indeed I would suggest that the discussions around cancelling, approving and prioritising the Epics are likely to last the best part of a long afternoon if not more, perhaps 4hrs.
Patterns & Anti-Patterns
Increasing Number Of Epics. The name of the Strategic Portfolio Review (Epic Cancellation & Approval) is very deliberately structured, Cancellation first then Approval. Cancellation appears first in the title and should be first in the agenda. In a flow based system work can be pulled across once there is space, in order to create space work needs to be deemed to be done or cancelled. Only once space has been created is it worth progressing to approvals; but there’s no point approving new work if there is no downstream capacity. If the meeting were named Epic Approval, then that’s what would happen. It is most likely that Epics would be approved, the time is spent discussing approvals and not cancellations, therefore nothing gets cancelled. With more work being approved and nothing being cancelled the amount of Work-In-Process goes up and the deliveries go down as the fixed capacity/effort is spread across more and more work.
Words matter; Cancellation & Approval, that’s all a bit old world. Can’t we come up with a better name, something that reflects the Lean-Startup mentality that the Portfolio should be adopting. Pivot and Prioritise. I like the alliteration. Unfortunately the drawings have acquired technical debt and use the old name so I’ll have to stick with the Cancellation & Approval name for now.
Everything Is Approved. If every idea proposed passes through the Approvals process then you have to question why the approvals process exists? If everything is always approved then it’s not adding anything useful, it’s overhead on something that is going to be done anyway. Ideally the Strategic Portfolio Review (Epic Cancellation and Approvals) would be run in a Dragons Den (Shark Tank to US readers), where ideas are pitched at the Lean Portfolio Management. Not all ideas will make it, some will be turned away. Lean Portfolio Management should be making true investment decisions, which ideas should we invest the organisations effort into, which will get us the best return on that investment. Turning something down shouldn’t be seen as a failure, putting lots of ideas up for consideration and only a few making it through is an instance of the Set Based Approach described in SAFe Principle #3: Assume Variability, Preserve Options. The challenge is to get organisations thinking in terms of ideas they could potentially pursue, rather than work that must be done.
Can’t be bothered. What if the real decision makers in the Business can’t be bothered to participate? The 4hours required every 6 weeks is just too much of a burden on their precious time! Do the math, present them with the economics of the situation. A quick back of napkin calculation, if an engineer costs the organisation $1000/week and an Agile Release Train is employing 100 of them for 10 weeks, then the cost of the Agile Release Train is a cool $1M. Given that a Portfolio by definition is going to contain several trains then that equates to several million dollars of investment in people that needs steering to ensure that it is consumed wisely. Usually the appearance of M (million) in the figures tends to make the decision makers start paying attention; 4hours every 6weeks to steer the consumption of several M of investment doesn’t sound too onerous.
Portfolio Sync
What decisions does it need to make?
- Decide on a plan to assist any Epics that need help?
- Decide on a plan to assist or coordinate any Development Value Streams that need help or coordination?
The Portfolio Sync is going to be the Daily Stand-up or Scrum-of-Scrums equivalent at the Portfolio Level. Like all of the Stand-up style meetings it should be a planning meeting, not a reporting meeting. It’s producing a localised plan for who needs to work with who over the timebox between now and the next meeting. Using it as a planning event keeps it short and focused and defers the actual work into “working time” rather than it occurring during “meeting time” which allows those not involved in resolving an issue to get on with their own work.
The two decisions that the Portfolio Sync need to make have different audiences; the Epic Owners are interested in the Epic progress, the Release Train Engineers (or Solution Train Engineers if running Solution Trains) are interested in the Development Value Streams. Like the PO Sync and Scrum-of-Scrums within the Agile Release Trains might be better served by two separate meetings with different sets of attendees.
The Portfolio Sync (Epic Progress) focuses on the ensuring that the activities to progress Epics through their lifecycle are happening efficiently. It provides a point where the Epic Owners can raise impediments and the group can start planning how to resolve the impediments. It should be facilitated as a planning meeting; unless the impediment is trivial, plan when the work to resolve the impediment is going to occur and who needs to be involved. The Strategic Portfolio Review (Vision) provides The Vision that informs what new Epics should be prepared ready for approval at the Strategic Portfolio Review (Epic Cancellation & Approval). Epics that have been approved need to be collecting their metrics, their Business Outcomes and Leading Indicators. The metrics will be used as justification at the Strategic Portfolio Review (Epic Cancellation & Approval) as to why these should not be cancelled because through the Business Outcomes they measurably demonstrate that the Epic is generating value, or through the Leading Indicators demonstrating that it is making progress towards the point where it start to generate value. If Epic Owners are having problems developing the Lean Business Case or collecting their Business Outcomes and Leading Indicators then they can raise the issue at the Portfolio Sync (Epic Progress) and the wider group can plan to put time aside to work out how to solve the issue.
If the Portfolio Sync (Epic Progress) only occurred once a month then there wouldn’t be enough instances within a Program Increment to be able to provide sufficient feedback to the Portfolio. If the organisation is capable of handling Epic progress offline in an ad-hoc manner, rather than as a collective group, then the infrequency might not be an issue. I would recommend falling in-line with the agile cadence of the organisation and having these at least once an iteration. Since these are frequent meetings they should be short; I would aim for an hour at most.
The Portfolio Sync (Development Value Stream coordination) focuses on issues arising from Development Value Streams.
If the Portfolio Sync (Development Value Stream coordination) only occurred once a month there could be a considerable delay between issues arising in the Development Value streams and them reaching the Portfolio Sync. If the cadence of the meetings is infrequent the issues will have to be dealt with as they occur, and then when the meeting does happen it lapses into reporting meeting because the issues have already been dealt with, which obviates the need for the meeting. Jeff Sutherland in his Scrum@Scale framework proposes that the Scaled Daily Scrum events for the different levels should be synchronised so that a team impediment can be forwarded to the team-of-teams level that follows it, and can be forwarded on up until it eventually reaches the Executive Action Group at the top. This means that an impediment identified by a team can reach the Executive in under half a day, since the Executive knows which team raised the impediment the response can return directly to the team, thereby minimising delays. There is no reason why a similar approach couldn’t be taken within the SAFe context, align the stand-up equivalents so that through them the impediments can escalate upwards rapidly. If the meeting is going to be run daily then it needs to be short, half hour at most. Don’t report, plan the resolutions for what you can resolve to occur outside of the meeting, and escalate what can’t be resolved.
Setup & Frequency
Jeff Sutherland would strongly suggest daily, falling in line with the Scrum-of-Scrums cadence that the Agile Release Train operate on would be another sensible option. At worst this needs to happen once per sprint/iteration but most organisations should be able to do a lot better than the worst.
Patterns & Anti-Patterns
Reporting instead of Planning; the classic stand-up anti-pattern. At the Agile Team level reporting behaviour often starts to occur when either the team or the work are badly structured and people within the group are operating independently rather than as a team. If people are operating independently then there’s no need to plan collaborations because they are independent so the fallback behaviour becomes reporting on what you’ve done, although nobody else cares about what’s being reported because they’re doing there own independent thing. The fix is to structure the team and work so that they all collaborate to get things done, the collaborations need to be planned daily and therefore the daily stand-up starts to become useful again. At the portfolio level this behaviour will manifest if the attendees are behaving independently rather than as a team. Regardless of the individual piece of work that each attendee may own, everyone needs to be invested in the Strategic Themes of the Portfolio and working towards the Portfolio’s success, this can engender cooperation which in turn requires planning and the meeting starts to become useful again.
Solving instead of Planning. During the event itself participants are trying to solve the issues that are being raised as part of the event. This often degrades into a small handful of people having detailed discussions whilst the remainder of the group just stand around and observe. Watching others have discussions is not a good use of the participants time; pull the focus back to planning. Who needs to participate in solving the problem? When, after the Event, do they have free time to properly discuss the problem. It’s another example of Design Thinking’s Double Diamond, separate Problem Space from Solution Space. The Portfolio Sync is the Problem Space and gets the Problems raised and visible to plan them, the Solutions occur during the time outside the Portfolio Sync.
Meeting takes too long. The obvious question to ask is why is it taking too long? What are you discussing. If the meeting has lapsed into Reporting or Solving then it will take too long. The volume of Epics or Development Value Streams that need to be discussed can also be another factor; rather than discussing every single one could you Manage by Exception? Only discuss those Epics or Development Value Streams that have issues that need discussing. For the Epics you might need to ask whether there are too many Epics in play, could you be more stringent with your Work-In-Process limits in order to get improve value delivery.
|
What Happened To Architecture? PO Syncs and the proposed Portfolio Sync (Epic Progress) represent work, business needs, and the Scrum-Of-Scrums and the proposed Portfolio Sync (Development Value Stream Coordination) represent process, facilitation, but what about Architecture? Shouldn’t the Architects and Engineers be getting together to check that there aren’t any technical impediments arising and to evolve the Architectural Strategies as necessary? Probably, yes there should be some sort of technical sync. Arguably it could be covered through the other two events, planning for preparing the technical changes could be discussed as part of the PO-Sync and technical impediments can be raised, resolved and escalated as necessary through the Scrum-of-Scrums. If you are going to have a technical sync does it need to be done as a ceremonial activity? Maybe, maybe not. Context, your context, is going to be king. If a ceremonial activity makes sense then the pattern has already been established with the two events already described, the attendees and the focus will obviously differ. I suspect that early SAFe implementations weren’t sophisticated enough to need an explicit Architectural Sync and by the time implementations were occurring that did need it there was an unwillingness to add another event into the framework because once an event is suggested in the framework people will do it regardless of whether then need to or not! |
Participatory Budgeting
What decisions does it need to make?
- Decide on an investment profile (budgets) for the Development Value Streams within the Portfolio.
Inputs to the decision making process are:
- Vision
- Baseline Solution Investments – The costs to keep a Solution running
- Proposed Solution Initiatives – Proposed changes to the Solution
- Total available funds
Setup & Frequency
The process of Participatory Budgeting has been discussed in earlier blogs.
It needs to occur far enough advance of the investments changing that those changes can be enacted. Given that this potentially includes hiring and firing processes, or renegotiating contracts, this needs to be done at least a PI in advance of when it is intended to be actioned. Hence the suggestion to run it every 6 months.
Remember changing the money is a strategic tool, repositioning the Portfolio for the long term. It can take months for changes to the investment profile to be enacted at the Team Level due to the latency of HR processes, changing the investment is hiring and firing. Changing the work is the tactical tool to use if you need to get something done, prioritise what you need, deprioritise or defer everything else!
Given that the Participatory Budgeting event is infrequent, it can and needs to be a larger event. Participatory budgeting is typically a whole day event and can involve anywhere between 50-100 people. An 8hr day every 6months doesn’t seem an unreasonable request on the participants time.
Patterns & Anti-Patterns
Some of the challenges with Participatory Budgeting have already been discussed in the earlier postings linked to above. One that is worth discussing here is Institutional Inertia.
Nothing ever changes. Institution inertia means that the status-quo is continually propagated rather than a relentless pursuit of value. If a Development Value Stream is no longer valuable or viable then it should be dropped. If Participatory Budgeting decides not to allocate funding to a Development Value Stream then the Development Value Stream goes, don’t invent work to keep a Development Value Stream busy it’s wasted money that could be used for something more valuable. If work is coming in that doesn’t have a natural home then that could be trigger to create a new Development Value Stream.
Validating The Information Flow
Does everything that’s been described fit together? Does the necessary information flow in the right direction? The following diagram shows two PI cycles, approximately half a year.
Abbreviations:
- SPR – Strategic Portfolio Review
- PIP – Program Increment Planning
- I&A – Inspect & Adapt
- IT – Iteration
- I.P. – Innovation & Planning Iteration
Insight from the planning events flows into SPR Strategy, Information from the Portfolio Syncs (PS) flows up to the Strategic Portfolio Review. This allows the Strategic Portfolio Review to adjust the Vision.
The Vision from the Strategic Portfolio Review (Vision) informs Participatory Budgeting which in turn can change the investment in the Development Value Streams by adjusting them at the PI Planning boundaries.
The Vision from the Strategic Portfolio Review (Vision) informs the Portfolio Sync (Epic Progress) so that it can organise the development of Lean Business Cases for any new Epics.
The Vision from the Strategic Portfolio Review (Vision) informs the Strategic Portfolio Review (Epics Cancellation & Approval) along with Lean Business Cases that the Portfolio Sync (Epic Progress) has been organising.
Note: Whilst the diagram indicates the flow of information, progress typically happens by work, principally the Epics but also Features, being pulled towards the destination, don’t misinterpret the diagram as showing work being pushed around.
From the perspective of Information flowing, the events look as if they will work.
Validating the Alpha progressions
If we utilise the Alphas described earlier we can see if the activities described above progress the Alphas as expected.
The Strategic Portfolio Review (Vision) is responsible for keeping the Vision up-to-date; it’s simplistic lifecycle is covered.
The lifecycle of the Epic is covered, all of the activities that happen ad-hoc can be tracked if necessary through the Portfolio Sync events. The Strategic Portfolio Review events make the higher level decisions about what set of Epics should be active and therefore whether this Epic is or isn’t active.
The Portfolio Sync (DVS) checks from a Portfolio perspective that the Team, which in our instance are the ARTs within a DVS, is running smoothly and assisting where necessary although much of the improvement should be done internally by the ARTs.
This does reveal a gap; none of the activities described so far progress the Team Alpha through to the Formed state, nor are there any activities to move it into the Adjourned state should it ever be needed. There is one last piece of the puzzle that needs to be slotted in to place to complete the set of activities…
Value Stream Mapping & ART Identification
What decisions does it need to make?
- Decide on the Development Value Streams within the Portfolio.
Inputs to the decision making process are:
- Vision
- Knowledge of the organisations Operational Value Streams.
- Knowledge of the solutions that support the Operational Value Stream.
- Knowledge of the engineering staff that maintain the solutions that support the Operational Value Streams
I won’t cover the details here as the workshop is described in the Identify Value Streams and ARTS article as part of the Implementation Roadmap and there is an associated toolkit available to accredited SPCs.
Output
- A proposal for a Development Value Stream
The proposed Development Value Stream can either be set up, or existing Development Value Stream(s) evolved to become the proposed Development Value Stream.
Setup & Frequency
Primarily this happens towards the beginning of an Agile transformation as an organisation moves from Projects to Products and needs to determine what Development Value Streams should be set up to produce those Products. However, the Development Value Stream setup needs to be periodically re-evaluated to ensure that it is still fit for purpose, this could be annually, or on an as needed basis.
Since this is happening infrequently it doesn’t need to be constrained to a short timebox, indeed experience with running these indicates that each Development Value Stream is likely to take a whole day of discussion, particularly during the first discovery phase. Subsequent revisits to check that the original decisions remain valid are likely to be quicker.
Patterns & Anti-Patterns
Entire books have been written on the Anti-patterns around Team formation, those aren’t the focus. The focus focus is on
Nothing ever changes. Institution inertia means that the status-quo is continually propagated rather than a relentless pursuit of value. If a Development Value Stream is no longer valuable or viable then it should be dropped. This isn’t to say that we should always be changing the Development Value Streams, some will be very, very stable1, but if they need to be changed they should.
The set of Development Value Streams within the Portfolio defines the type of work that can be done, which influences Participatory Budgeting which in turn defines the scope of the Development Value Streams.
Conclusions
Whilst it’s trivially easy to set up a set of events to run the portfolio, just stick the dates and times into your calendar program of choice and invite everyone along, making sure that they have a defined purpose and that the events are actually moving the organisation forwards requires a bit more care and thought. What started out as “these events feel wrong” turns into a much deeper discussion about what a Portfolio does operationally which in turn informs what the events need to do.
Is this what your Portfolio should be doing? Not directly, don’t just copy the proposed solution blindly! Feel free to copy my process to understand your problem space, then you can evolve your own set of events.
Next steps
Now that we’re done with looking at structuring our portfolio events, there are a few more things to explore about Epics before moving on, notably Enabler Epics and When is an Epic Done? After that it will be time to exlpore the role of Epic Owner.
#1 I did some training for The Belastingdienst, The Dutch Tax Office, a few years ago. We traced their Operational Value Stream “The Dutch Government taxing the Dutch population for the benefit of the Dutch Population” back about 100years. Prior to that the Operational Value Stream was “The Dutch Crown taxing the Dutch population, possibly for the benefit of the Dutch Crown more than the population” which went back another 100years. Prior to that is was “The Spanish Crown taxing the Dutch population, definitely for the benefit of the Spanish Crown rather than the Dutch population.” which went back another few hundred years. We could probably have traced back further. There was also agreement that Income Tax wasn’t going away anytime soon. A very stable Operational Value Stream.
We then started discussing Fuel Duties, Taxes on Petrol/Gasoline. With the current revolution going on in the car industry and its shift towards Electric vehicles, then the consensus was that that Operational Value Stream would be evolving at some point in the future.