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.
For months we’ve been talking about Enterprise Design Sprints. What they are, how to run one, and how to scale them to improve outcomes throughout an entire enterprise. In this post, we’ll look at the remaining part of the Scaled Agile Framework (SAFe), the Enterprise, and how it can support the rest of the levels. Finally, we’ll zoom back out and look at the entire picture.
The “Enterprise” is the name of the highest level in the Scaled Agile Framework. In most organizations, this generally includes the C-suite and the groups that support them.
An Enterprise oversees one or more Portfolios. Like the Portfolio level, the Enterprise level doesn’t directly implement value. However, they can guide other levels by sharing the organization’s mission and vision, wide-scale transformation goals, and priorities.
According to SAFe, the Enterprise determines the Enterprise Strategy, and shares strategic themes with the Portfolio team(s). In the reverse direction, information from the Portfolio(s), like progress on key performance indicators (KPIs) and qualitative information, can help shape the Enterprise Strategy. Put in another way, a centralized team determines the general strategy, via a collaborative process. The Portfolio helps translate that strategy into epics. Then the Value Streams, Programs, and Teams execute the strategy, adapting to real-time inputs in order to achieve the goals.
Ideal vs. reality
SAFe assumes that there’s an Enterprise vision guiding the remaining levels. However, there was a reason why this series about scaling Enterprise Design Sprints started from the bottom up. Assuming that each layer did not have any support from the layer above it until we added the new layer.
The reality in complex systems is often less pretty than the ideal model. If the vision, roadmap, or knowledge base is missing from any level then the teams need to spend time understanding that context and defining a vision themselves. They need tools to identify how to move forward and where they need to coordinate with other teams.
Building a plan from scratch may be agile. But if everyone is building their own plan by themselves, once you scale that up to hundreds of teams, the Enterprise will probably not get the results they were looking for. As we added the Program, Value Stream, and Portfolio levels, each level provided more guidance and support to the one below it. The actions at the Enterprise level can help make the teams stronger or add to the chaos.
And chaos and inefficiency can easily happen in complex organizations or systems of systems. Organizational change takes time as ideas spread from early adopters, and if communication channels are weak or missing, groups will probably duplicate efforts and reinvent the wheel. If enterprise standards are weak, integration problems will distract everyone. And finally, if executives are dealing with a mix of external pressure and internal issues, it can be easy to focus on fighting isolated fires.
In this scenario, executives might see problems and think that “special ops” or “tiger teams” will solve everything. But tiger teams can only solve so much when the problems are systemic. And without the right approach, they might make systemic problems worse. Then you have problems everywhere and feel like you need to deploy 100 more tiger teams.
To break the cycle, the Enterprise level should focus on work that they are best positioned to handle. That includes issues that impact multiple Portfolios, such as setting high-level values and targets. It also means creating the systems and environments that will allow the rest of the organization to deliver, collaborate, learn, and improve.
An Enterprise Support Role
The Enterprise level should use their resources to research and maintain knowledge for other levels to consume, validate, and add to. The Enterprise should also be defining and streamlining policies and enterprise architecture standards. They should work on obtaining modern tools for knowledge management, supporting new funding, and helping create recruiting processes that can support the rest of the teams.
In the rest of this section, we’ll talk in more depth about the activities at the Enterprise level.
Sharing a vision
The Enterprise should express a mission, vision, and the core values of the organization. Emphasizing more of the why behind the enterprise’s actions, instead of the how. They should also set the tone of how success is defined and which indicators are tracked and valued. That’s a way to connect the enterprise vision to the success criteria at each level.
Defining and sharing a vision for the business model will help guide further analysis and design work. For example, is the business aiming to move towards greater standardization among the business lines? Or differentiation? Defining a target operating model allows you to build a to-be business and technical architecture that can support shifts in customers or business offerings.
If there isn’t a vision yet, sharing a goal to create one will also help align everyone. An Enterprise Design Sprint may be helpful to rapidly test business models, sort through cross-cutting issues that impact multiple Portfolios, or explore how the Enterprise could respond to industry trends.
If we think about a boat metaphor, if no one is deciding and communicating which direction the boat should go in, everyone may start paddling in different directions. With their visibility and authority, the Enterprise C-suite is in a good position to help focus the troops on areas of the business to examine and improve first.
Even if you’re working with a complex problem or organization, setting priorities at the Enterprise level is relatively straight-forward. First, the highest level leadership needs to prioritize a set of customer journeys and themes. If the business already exists then the journeys would just be a collection of all of the product or service journeys that the organization provides or is considering providing. Themes could be general areas of improvement that cross-cut customer journeys, such as shared customer data.
The initial priorities will most likely come from Enterprise strategic leadership. They could be based on business goals, customer feedback, modernization initiatives, SWOT analysis or other motivations. If they used a value framework to make that determination, then they should share it with the rest of the enterprise to help prioritize their own work.
At this point, the definition of the theme could be very short and lightweight. One sentence to a paragraph describing which areas are a higher priority and why. When the journeys and themes are prioritized, then customer research, business process analysis, and technical analysis should occur simultaneously. In this case, I’m assuming that the Enterprise is able to have a team or set of teams modeling and monitoring business architecture, enterprise architecture, customer research, and enterprise analytics. Their work helps inform the C-suite as well as being available to other levels in the Enterprise.
Prioritizing the customer journeys and themes helps to focus analysis efforts on the areas that are most likely to receive funding. Or areas that need some extra validation before deciding whether to move forward with further investment. This is slightly different than traditional Enterprise Analysis which aims to understand the whole Enterprise. That’s helpful, but this method can work well if you’re starting from scratch. It will help you quickly move items through the pipeline and into production while you’re still learning about and codifying the business.
Continuous customer research
Each level, from Teams to Portfolio, will be talking to customers as they validate their ideas. However, once an Enterprise grows to a certain size, it may make sense to have a dedicated team that collects information about customer lives, needs, and pain points. They could be the go-to resource for teams setting up user tests and customer interviews. This is the group that will be doing ethnographic research, interviewing a larger number of customers, running surveys, or reviewing other usage analytics across the enterprise. They can work with implementation teams to brainstorm questions to ask and to support validation sessions. This customer research team can also manage the database of customer feedback that is collected across the enterprise.
Collecting, organizing, and sharing the highlights of that information can save other groups a lot of time. It can also be an input to Enterprise Design Sprints at each level. Since the as-is learning phase and validation phase are the longest parts of the Enterprise Design Sprint, streamlining that process with shared resources could result in huge gains in delivery speed. It doesn’t replace the as-is learning phase of the sprint, but it can give the team a solid base to build from.
Continuous business process research
At the same time, business analysis is being conducted to better understand the business processes and rules related to that journey or theme. Insights from the business process can inform customer interviews that should occur. For example, you might realize that you need to discuss a step with a specific user group because they go through different processes. Insights gathered from customer interviews can also help prioritize areas of the business to analyze. If your main goal is to improve customer satisfaction, you might want to start researching the business process around the current pain points and expand from there.
Your customers’ needs, pain points, and lives are changing. In a large enterprise with agile teams, the business will also be constantly changing. Dedicating a team to researching and modeling how the business works, especially how core processes are run, will save a lot of time for implementation teams. It will also help provide more visibility into where problems and opportunities are.
The business process team can also model the as-is and to-be business architecture that supports the executive operating model. This information will help to guide the other levels as they build out more detailed roadmaps that can support that transition. This business process team can also play a role in defining standards for how other teams will model their processes and how to store and share information. They can also identify and manage business process analytics to help the Portfolios, Value Streams, Programs, and Teams prioritize.
Continuous technical research
Information from customer research and business process analysis can tell you which technical systems to research. In particular, they’ll point you to problematic data flows or rules. In the opposite direction, technical insights can help explain why user issues are occurring. Or can help highlight where the technical representation of a solution is not in line with business needs. For example, how data is stored, how authorization is controlled, or which security measures are in place could indicate serious issues that might not have been noticed by the business or customers yet. Technical research can also surface enabler tasks that might go unnoticed in the business or user research work. Those could include maintenance improvements or software upgrades.
Note that the process is not waterfall, with each group waiting to start work until the previous group has finished. The identification of the journey or theme itself should be enough for all groups to start high-level analysis. Customer interviews may be more open-ended, covering other topics like their daily lives and interactions outside of your business or technology. The business process analysis will focus on your core business (or industry analysis). Technical analysis will focus on your technical systems, applications and offerings, along with industry trends.
This ongoing research helps to ensure that you have an accurate representation of the current customers, business, and technical systems. That picture will evolve over time as user needs change, processes change, and technology shifts. While it may require extra work upfront, in the long term you should be just tweaking an existing knowledge base. After defining and sharing a solid understanding of the current state, the enterprise research teams could shift to spending more time looking externally. That could include analyzing industry trends, scientific research findings, and new concepts in the experience, business process, and technology spheres.
All of the groups will be looking for questions to answer and data to track. If the Enterprise wants to further streamline those efforts they can include a data analysis team. That team would create and support shared infrastructure and tools, plus run their own analysis on enterprise datasets, build simulations, and create new visualizations.
Impact on the other levels
The Enterprise support role is not about doing the hard work for the teams. It’s about standardizing some of the decisions and providing information that every team needs. That way teams can focus on adding the most value that they can from their position.
The Enterprise analysis teams will share the information across the Enterprise for use as inputs to Enterprise Design Sprints. That sharing can happen as soon as possible. There’s no need to wait for a 6-month research project to conclude before acting on that info.
There are many projects that don’t follow this process. Some plans exclusively focus on user experience analysis. The drawback is that they do not incorporate known (and unknown) enterprise capability gaps, business process or data problems. Those issues are often a source of customer pain and potential quick (or just important) wins. On the other hand, if there is little user analysis then companies are in danger of creating products and services that no one wants. Creating these support functions can help everyone identify high-value problems and opportunities without sacrificing speed and agility.
This mini-series about scaling Enterprise Design Sprints was all about different ways to incorporate the EDS techniques and mindset. It doesn’t matter where you are in the org chart or how coordinated the rest of the enterprise is, there are ways to leverage Enterprise Design Sprints to make a difference.
If your organization has all of the levels of SAFe in place, here’s an overview of how they can work together:
- High-level executives prioritize customer journeys and strategic themes.
- Enterprise teams build out shared resources used by multiple Portfolios.
- Enterprise analysis teams conduct customer research, business process, and technical analysis at the same time
- Insights from the Enterprise analysis teams are inputs to the Portfolio(s) who organizes them into categories such as products, users, value streams, and epics impacting multiple value streams.
- The Portfolio gathers rapid feedback on potential epics via sequential Enterprise Design Sprints.
- A Portfolio Roadmap shows a high-level view of the themes and epics the Portfolio(s) are looking to address over time.
- Regular Enterprise Design Sprints at the Value Stream and Program levels result in continuous improvements to their roadmaps.
- Agile teams execute changes and move along their roadmaps, running an Enterprise Design Sprint as needed to validate ideas with users, stakeholders, partners, and executives.
- All teams consume, validate, and add to shared knowledge about customers, business, technical design, analytics, and new opportunities.
- Roadmaps are tagged and linked, so it’s easy to create different views of planned and potential work, that are customized for the audience.
I hope this series was helpful for understanding the ins and outs of running and scaling Enterprise Design Sprints. If you’re looking for more, visit the store to grab your copy of the Enterprise Design Sprints guide for facilitators.
When are you planning to host your first/next Enterprise Design Sprint?