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.
The complexity is increasing from a single agile team to a group of teams organized as a Program, to a group of Programs working within one Value Stream. This is where the big changes and big difficulties come in.
Value Stream Level
Scaled Agile Framework (SAFe) version 4.0 introduces a new level called the Value Stream. It provides an additional level for coordinating the tactical implementation of changes. It’s especially helpful if you have a large organization or multiple groups operating under different management. For most complex problems involving systems of systems with organizational or political challenges and decentralized leadership, you’ll find yourself in this realm.
According to SAFe, “a value stream is a long-lived series of steps used to deliver value from concept or customer order to delivery of a tangible result for the customer.” They clarify between operational value streams and development value streams. You could think of an operational value stream as being the steps that occur to deliver value to your end customer, while the development value stream involves delivering technical value to internal or external customers in the form of new products, systems, or service capabilities.
For example, your operational value stream could be to provide widgets to your customers when they order them and a development value stream could be the application that is developed to support the ordering and status checking process. So you almost have a mini product development business to consider within the larger business.
Personally, I prefer to organize analysis and design around operational value streams, because designing technology in the absence of that understanding can lead to major oversights. However, SAFe asserts that operational value streams drive development value streams so there’s an assumption that operational value streams are already considered at a higher level and the value of the development effort has already been determined.
The takeaway here is that someone needs to be thinking about the operational value stream level and it needs to be a sophisticated operation to avoid development for technology’s sake and separate business and technology silos. The “Value Streams” should be organized around operational value streams that include other groups like policy, finance, call centers, etc. That would be my recommendation for the highest quality technical and business solution that truly supports business goals from analysis through implementation.
SAFe says that the Value Stream level is optional because it may not be needed if everyone is organized into one program, which could be the case in a small to medium sized business. However, if you’re trying to change an entire enterprise operational value stream or are working on highly complex, mission-critical systems that require more than 12 agile teams or 150 people to build, then you’ll need multiple agile release trains working together on a “Solution.” That’s where the Value Stream layer and its concepts come in handy.
Below is a comparison of the SAFe model with just the three layers, and with an added Value Stream layer (from the SAFe website):
For the rest of this post, we’ll be digging into the details of the picture on the right.
In the SAFe Value Stream model, ideally, all of your Agile Release Trains/Programs will have milestones that align. That way planning, demos, integration, and releases can be organized more easily. The job of coordinating multiple Release Train Engineers would be done by the Value Stream Engineer.
The set up of the Value Stream level is similar to the Program in that you have to organize multiple groups together to identify, plan, and coordinate the delivery of value. SAFe calls the business side of this plan the “Solution Management.” They are in charge of working with everyone to define and improve the “Solution.” Solution Managers are the Value Stream version of Product Managers and Product Owners.
In the SAFe requirements model Capability > Feature > Story. All three describe the functional behavior of the system at different levels of abstraction. Every capability, feature, and story could be categorized as “business,” which provides direct business value, or as an “enabler,” which basically covers everything needed to support current or future business items. So, at the Value Stream level, you’re looking to define and demo items that are around the size of a “capability.”
However, you’ll probably also be looking at Epics, which can be at every level (Value Stream Epic > Program Epic). Epics are large, cross-cutting initiatives that drive business value and connect the work to the strategic goals. They need to be broken down into changes that can be implemented as capabilities, features, and stories. Capabilities, features, and stories have acceptance tests that indicate when they are “done” while epics will have success criteria.
The Solution Architect/Engineer defines the overall architecture for the Solution. They would work with the System Architect/Engineers within each Program, who in turn would advise the developers on the Teams.
Other roles such as DevOps, a System Team, User Experience, and shared services can play a role at the Value Stream level as well. They support the infrastructure the teams need to create and deliver value. They can also provide standards for the Programs to follow and inputs to the backlog.
SAFe also highlighted a new set of tools at the Value Stream level to help guide decision making and share knowledge. The Economic Framework provides boundaries for decision making. The Solution Intent is a repository for to-be and as-is solution behavior. And the Solution Context describes how the solution will fit into the broader context once it is released to the customer. SAFe suggests Model-Based Systems Engineering, Set-Based Design, and Agile Architecture as tools to be used at the Value Stream level. While the icons appear in the Value Stream level in the graphic, the creators of the SAFe have mentioned that these tools can be used at any level.
What’s missing
In charge of an entire Value Stream, the Solution Manager needs to pull in perspectives from Programs and Teams, as well as look outwards to the market, and upwards to business goals (if they exist). Given the amount of knowledge required and impact of something as large as a “Solution,” this is where having a repository of information about users, processes, technology, and shared roadmaps helps to cut down the work. If that doesn’t exist then the Solution Manager will need to analyze the business, user needs, and technical state herself. Which is where Enterprise Design Sprints are handy. It gives Solution Managers a framework for quickly working through complex problems to generate ideas for capabilities and features that can be implemented.
Another challenge for the Solution Manager, Solution Architect, and parts of the User Experience team at this level is balancing systems analysis and the need to feed the development pipelines in a timely manner. Quickly identifying high value and less risky areas to move forward will help keep the backlogs full while more information and feedback is being gathered.
Clear communication and coordination are also needed to quickly pivot if new information is found that would impact the value of the solution. Focusing on setting up systems for coordination and breaking down complex problems will also be critical to avoid the low-hanging fruit trap.
Timing
Since Value Streams deliver larger changes over longer time frames, the Value Stream Enterprise Design Sprints don’t need to happen as frequently as a Team or Program EDS. Depending on the speed of delivery and rate of change in your industry, you probably need only one per month or quarter. However, if you’re exploring new business options or looking to dramatically rework and improve a value stream then you might want to run them more frequently to iterate through multiple options.
Solution Managers can prioritize an enabler capability to sort through the issues. Or they could attempt to use the analysis phase of the Value Stream kanban and pull in representatives. Another option could be quarterly planning sessions or off-sites where regular work is deferred while the right representatives from the Programs are pulled in.
The Enterprise Design Sprint itself
If the current experience and process are known and it’s clear that the major problems can be handled in a particular Program or Team then it makes sense for the Product Manager on the Program to drive the sprint, pulling in partners and the Solution Manager as subject matter experts (SMEs). However, if the symptoms are occurring in one area but the core issue is in another, then running a sprint at the Value Stream level is better. This can help avoid any authority or priority issues that could hinder progress.
Since the SMEs from the programs and teams will probably be busy with their own backlogs and work, you’ll have limited opportunities to pull them in. This is where identifying who will absolutely need to be there and why will be important. Decide whether you want to pull in the Product Managers from the relevant programs to the sprint or if you absolutely need the Product Owners as well. Consider consulting with them as an SME unless the epic or feature heavily impacts their team. In that case, it may be beneficial to include them in the sprint, especially in the as-is phase and to review the outcomes. You want to avoid moving too far on false assumptions, especially about the current state.
A backlog at the Value Stream level is a nightmare to sort through because it’s going to include items coming from the top down, bottom up, and new insights that you uncovered. It’s also likely to include items of varying sizes that could be organized in multiple ways. Separate lists, tags, and roadmaps will be critical to organize it all without losing anything or going crazy. You’ll also want a place to store and track problems that were identified and ideas for what could be. You might also want to have some idea portals to collect ideas from customers and co-workers before they are validated and organized. Good news is that some of the roadmapping tools can help you organize all of those inputs so you can focus on defining the major themes and new directions for the value stream.
Roadmaps are better than backlogs at the Value Stream level because you can visually show themes, dependencies, timelines, and programs involved. And given the complexity of the work at the Value Stream level, you’ll have even more roadmaps to track. Each epic, capability, or product could have their own roadmap, each Program will have their own, and you might also want to track dependencies and deadlines between Programs. This is where having a roadmap tool is going to save a ton of time and headaches.
For organizing the problems and opportunities at the Value Stream level, adding notes to your operational or development value stream process model can be very effective. That way you can see where the clusters of problems are, look immediately for root causes, and quickly identify if they are mainly within one program or a handful. It’s also a way to store a lot of information in a compact space. Then decision makers can decide which part of the process to improve, given current data and themes.
Through the Enterprise Design Sprint, you’ll review the value stream in its entirety or select an existing topic or epic to break apart further. Then your outputs will be a roadmap with epics, capabilities, and features. Your prototypes could be screens or physical prototypes of what you’re looking to build if you can pull in the responsible team. Or they could be general outlines or “box” pictures to get feedback on whether that’s a good direction to go in.
At the Value Stream level, you also need to define relevant metrics and create reports, which may be a roll up of what Programs and Teams are reporting. Big picture information about the whole process should be shared with individual Programs and Teams so that they understand how their piece fits into the broader picture. And shared understanding of users will be critical. If you have Value Streams, Programs, and Teams gathering, sharing, and updating knowledge about user preferences, feedback, and needs, you’ll be way ahead of many companies. Same with the current business process and technical design. This is where an enterprise structure for handling data will be helpful, which we will get into during a later post in this series.
Linking sprint outputs and the Value Stream Backlog
At the end of the Enterprise Design Sprint, you’ll have ideas for epics, capabilities, features, and maybe even stories to implement. All of your findings will be added to a central repository and epics, capabilities, features, and stories will be linked together. That way, as Programs move forward with their relevant epics and features, they’ll have all of the information needed to know why those decisions were made and where there is still room for improvement.
Approved capabilities will become part of the Value Stream Backlog, and the rest will be part of the roadmap or captured as notes in your process documentation. If you identified an area that needs extra exploration, you could also create an enabler capability and recommend another Enterprise Design Sprint around it. That could be a good way to capture the priority of the work so you can pull in other resources to support the analysis.
Solution demos
Solution demos will occur when enough features are delivered that they equal a new “capability” as determined by the Solution Manager. This is a great chance to get feedback on all levels. Sometimes the feedback at the detailed level doesn’t make sense or isn’t as high a priority once viewed in the macro context. The information you gather after a solution increment can be a great turning point to decide which business model play to work on next.
Making progress on medium and long-term initiatives
At the Value Stream level, medium and long term are probably in the 6 months to years time frame. The Solution Manager is in the best position to be looking ahead to industry trends, identifying new partners, and removing roadblocks that require a longer runway (like a policy change). They can also spend time reviewing the Value Stream metrics to validate that progress is being made towards achieving the success criteria.
Repeat the process
After running an Enterprise Design Sprint at the Value Stream level, keep running one every time you are considering a new capability or as cross-cutting program problems surface. Value Streams are a great opportunity to really dig into the customer journey, your entire business process, and a high-level picture of all of the technical resources involved. That perspective can yield insights that agile teams working on just one piece usually don’t have enough time to uncover.
Next steps
This was the third part of a mini-series about scaling within the broader series about Enterprise Design Sprints. Next week we’ll talk about how to incorporate the sprints when you have multiple Value Streams working together within a Portfolio.
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.
Have you ever worked on a project where multiple programs needed to collaborate to improve a process or experience? What were your biggest challenges?