Note: This post is part of a series about Enterprise Design Sprints. If you’re new to the series, start with Why you should try an Enterprise Design Sprint.
Over the past few weeks, we’ve looked at ways to incorporate Enterprise Design Sprints into the team level, program level, and value stream level in the Scaled Agile Framework (SAFe) hierarchy. We’re continuing the journey one level up, at the Portfolio level.
Portfolio Level
In the SAFe model, the Portfolio level identifies and organizes initiatives that would impact multiple Value Streams and Programs. They transform inputs like strategic goals, user feedback, high-level business and technical needs, plus insights from lower levels of the framework, into large sets of work that can be implemented. Like cultivating a garden, Portfolio Managers look at all of the projects and changes the Enterprise wants to support and provide the structure and resources for the rest of the levels to successfully implement the work.
Run by the Portfolio Management, the Portfolio level works mainly in the realm of Portfolio epics, which are usually large, complex, and cross-cutting sets of work, taking months to years to implement. Epics require a light-weight business case and financial approval before they can be decomposed and implemented by a single Program, Value Stream or set of Value Streams.
Sometimes epics come to the Portfolio team fully formed, but most often the Portfolio will get a range of inputs of varying sizes, and will be looking for the cross-cutting themes, new capabilities, and infrastructure that would be required to support those changes. So they need to unpack and track a lot of other information besides the backlog of epics.
Unlike the agile Teams, Programs, or Value Streams, the Portfolio team doesn’t directly implement or manage the implementation of value. They can give recommendations about phasing but cannot speak to delivery dates. However, they can play a role in connecting teams and aiding with coordination and planning.
Another role of the Portfolio level is to help inform funding decisions, such as what percentage of the budget should go to different Value Streams or Programs, given enterprise goals. When starting from scratch, they’re also in charge of defining the boundaries of the Value Streams. To get real for a moment, often funding mechanisms are separated from product development and can be the last piece to change in a transition to SAFe. So if the Portfolio doesn’t have direct influence over funding, they can still provide recommendations (such as, “please don’t put a mission-critical product into sustainment”).
Depending on the enterprise, it might need one or more Portfolio teams. If you can easily slice your business into separate businesses with minimal overlap, then having multiple Enterprise Portfolio teams might make sense. However, if you provide multiple services to the same customer, or similar services to multiple customer types, then it’s beneficial to have one overarching Portfolio Team. That avoids duplication of effort and siloing that will ultimately impact your customer’s experience and need to be reworked later.
What’s missing
The Portfolio findings impact investment decisions, which should be based on the value and complexity of the work and the estimated roadmap. Enterprise Design Sprints provide a systematic way to identify opportunities, gotchas, and value vs. complexity of the proposed changes. For example, if there is an enterprise goal to improve customer satisfaction, an Enterprise Design Sprint could be used to sort through where the biggest problems are and potential ways to solve them. Then funding could go towards solving those problems, instead of basing funding off of past priorities or pouring money into something that is less important when compared to the broader portfolio of changes.
There are ways that the Enterprise can support and reduce the work required by the Portfolio team, which we’ll discuss in a later post. However, in the absence of extra enterprise support, the Portfolio team needs to be able to conduct any analysis that Value Streams, Programs, and Teams don’t have time to do because they are also responsible for delivering changes. That includes user research, business process, and technical analysis. The SAFe model assumes that Epic Owners already have that knowledge or have the tools to obtain them. An Enterprise Design Sprint could be that tool.
However, there are downsides to working in a vacuum and passing off the results of analysis to the Value Streams and Programs. Circumstances could have changed by the time the initiative will be implemented, and it may not be clear which process you followed, whom you talked to, and what you researched to reach the final outcome. Providing all of those details would basically require a white paper, which can take twice as long as the research itself (and good luck getting already busy people to read it).
Enterprise Design Sprints provide a way to collect and share knowledge that is flexible enough to minimize or maximize participation, as needed. This frequent two-way communication is especially important for making Portfolio investment decisions, which may depend on insights from the front lines about solution options and current resources. Enterprise Design Sprints help balance analysis and design work with efficient knowledge sharing.
Timing
Enterprise Design Sprints fit well into the Analysis phase of the Portfolio Kanban. Potential topics would be prioritized, one or more sprints run, and a go/no-go decision on the resulting epic (or epics) would be made. The Portfolio might need to work around other implementation commitments when scheduling the sprint, to make sure the right representation can attend.
The sprint itself
Portfolio sprints will likely involve bringing in Solution Managers from the Value Streams and potentially also Product Managers from the Programs. In the absence of direction from enterprise leadership, initial priorities would come from an analysis of the market, business, and technical landscape both within and outside of the business to identify issues and opportunities.
Sometimes the sprint topic will be a Portfolio epic and sometimes it will be a general problem or opportunity. By conducting an Enterprise Design Sprint, you can validate the usefulness of that epic and begin to break it down into work suitable for individual Value Streams and Programs. Or you can explore a high-level problem and identify epics that could solve that problem. The outputs of the sprint are more information about what could be built, a roadmap, and a go/no-go decision about whether the Portfolio epic (or set of epics) is worthwhile to invest in. Findings from all of this analysis should be stored in a shared knowledge base.
The outputs from all of your sprints will be organized in a work-in-progress, larger, Enterprise Portfolio Roadmap which is owned by the Portfolio team. The roadmap can be sliced to show progress along Products, Value Streams, or epics. You might also want to start tracking epics and issues that are shared by multiple Value Streams, such as defining consistent customer touch points for similar business steps, or moving from siloed to shared business data.
The Portfolio team regularly shares the roadmap with the Value Streams and stakeholders so that they understand what’s coming up and how their personal roadmaps fit into the general enterprise strategy. Business lines and technical teams work along their roadmaps, coordinating dependencies.
Connecting sprint outcomes to the Portfolio Backlog
Portfolio epics coming out of the sprint can be approved and added to the Portfolio Backlog. Any related Value Stream epics and Program features you defined would appear in their corresponding roadmaps and backlogs.
The approved Portfolio backlog is made up of epics with their own light-weight business cases. Portfolio management and epic owners already need to create a light-weight business case for the epic, so an Enterprise Design Sprint could be an effective way to build out the rationale along with supporting documentation and validated prototypes. By pulling in architects or systems engineering to the sprint, you will leave with some understanding of the implementation effort and impact on existing solutions. The business case for the epic also includes success criteria, which is defined during the sprint.
The information gathered during a Portfolio sprint also helps to inform the creation of Value Stream Roadmaps, which are further elaborated and updated with Value Stream Enterprise Design Sprints. Then each Agile Release Train may decide to run their own sprints to break down the details of changes that may need to be implemented across multiple teams. Finally, a single agile team may decide to run another Enterprise Design Sprint to work through the details and get feedback on the specific items they plan to build over the next few increments or releases.
People at each level can add new items that contribute to the business case, linking up to the original epic. In this way, outcomes from sprints at all levels can be linked back to the original Portfolio epic.
Demos
SAFe doesn’t have any demos at the Portfolio level because the Portfolio is more of a strategic organizing team than a delivery team demonstrating a working solution. However, it would be useful for the Portfolio team to regularly review progress made along epics, by attending demos at other levels to understand where the problems and trends are. They could also conduct some demos of their own to share roadmaps, findings, and epics with the other teams to spread awareness of new concepts that could influence roadmaps. Sometimes a quick touch base and looking at the macro or micro level can provide a new perspective, knowledge, and inspiration.
Making progress on medium-term to long-term initiatives
Timelines at the Portfolio level are long so there is some extra time to focus on creating the systems and knowledge bases that will help support other teams and future phases of the roadmap. SAFe calls out funding as one example. Aligning funding to Enterprise priorities is a huge step forward towards helping the teams execute changes in the highest priority areas.
It’s also important for the Portfolio team to be monitoring quantitative and qualitative feedback to see if the success criteria were met. It’s possible that epics could be in progress for years. Some may never need to be completed because (a) the majority of business value was provided or (b) the value/cost of continuing was too low. Staying informed and identifying when it makes sense to continue down an epic vs. pivot to another one will be necessary to maximize the value of the Portfolio. It’s also possible that the plan may need to be reworked if new strategic goals are announced.
Repeat the process
The Portfolio team can execute Enterprise Design Sprints as often as they need to, depending on how much information is known and how quickly the business changes. Maybe you’ll want to run a lot of sprints in a row to learn more about the problems and opportunities or explore different solution options. Alternatively, you could use an EDS every quarter to verify that you’re still going in the right direction given system, market, and industry changes.
Next steps
This was the fourth part of a mini-series about scaling within the broader series about Enterprise Design Sprints. In the next post of this series, we’ll wrap up by talking about the role the Enterprise can play to support the Teams, Programs, Value Streams, and Portfolios.
Update: This blog series about Enterprise Design Sprints has been expanded into a guide for facilitators with all of the content, plus 50+ worksheets and some other surprises. Check it out in the store.
Does your organization have a Portfolio team? How do they integrate with other teams?