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.
Last week we talked about how Enterprise Design Sprints can be helpful if you have one team that’s delivering value by itself or coordinating with outside teams. Let’s move up one layer in the Scaled Agile Framework (SAFe) and think about how you could use an EDS if you have multiple agile teams working together under the same management.
Program Level
In SAFe, the “Program” runs a collection of teams that form one “agile release train.” The train aggregates value created by each individual team into larger releases of value that can be shipped in regular increments. All of the teams work independently but they plan, demo, and deliver at the same time. There are also additional roles outside of the teams, who are there to support and manage the work, such as the Product Manager.
The Product Manager is in charge of the Program Backlog, which is the set of upcoming work for the program. Product Managers are similar to Product Owners, but they manage larger sets of work called epics or features. Features are sized to be delivered in a program increment, while epics could be split up into many features and delivered over multiple increments. Product Managers look at what’s being delivered across all of the agile teams while Product Owners are mainly responsible for what their own team delivers.
Additional roles like System Architects/Engineering, User Experience, DevOps, a System Team, and other shared resources support infrastructure and provide standards and guidance to the teams. They can also suggest items for the backlog and support their definition. The Release Train Engineer helps coordinate the delivery side to make sure that the “train” is moving on schedule.
What’s missing
The Product Manager, like the Product Owner, needs to deal with multiple inputs and stakeholders to figure out what to prioritize in the Program Backlog to achieve the business goals. The biggest difference between the Program and the Team level is that the Product Manager is focused on identifying, decomposing, or aggregating changes until they are around the size of a feature, while the Product Owner will be looking to break down changes to as small as a story.
To build a backlog of high value items, the Product Manager needs methods to review user needs, the business process, and technical landscape and break down problems and opportunities into plans that could be implemented. Enterprise Design Sprints can provide a short, timeboxed framework for accomplishing these tasks. If the program doesn’t already have a vision or roadmap then Enterprise Design Sprints are also great for establishing an initial draft, to be refined over time.
Beyond defining features for the program to deliver, joint Program and Team Enterprise Design Sprints are also a chance for teams to get a head start on defining stories and other tasks for their own roadmaps. At the Program level, with 5-12 agile teams working together, more value can be provided with every increment. However, that usually comes with increased complexities, including cross-team dependencies. The more teams you have working together under one program, the more difficult it is for organic coordination to occur. Enterprise Design Sprints can play a role to help programs navigate those complexities, by creating a shared vision and roadmap that breaks down how the work should be sequenced and split across teams.
Timing
Once again, the Innovation & Planning (IP) parts of the development cycle are good times to hold an Enterprise Design Sprint. The findings from the sprint can influence planning decisions for the next increment. If necessary the Product Manager could also create an exploration feature and add it to the backlog to carve out extra time for analysis. The benefit of an Enterprise Design Sprint is that it’s timeboxed so you know how much time will be required to complete it. You just don’t know for sure if a fully defined backlog item will come out of it, which is why it’s helpful to be prepared for a follow-up and have a mix of pre-defined work and exploration for the team to tackle during the development sprints.
Product Owners and Product Managers will need to work together to determine if a Team level or Program level EDS will be more effective for the topic. You could also run Team and Program Enterprise Design Sprints simultaneously. Maybe you end up with one team running an EDS by themselves while two other teams run through a sprint with the Product Manager on a topic that has cross-cutting implications.
Enterprise Design Sprints are also a good tool to use during the analysis phase of the Program Kanban. Maybe as the Product Manager you have some ideas of what you’d like to explore but you’re not convinced that it’s worth investing development dollars yet. By setting an initial priority and running the topic through a sprint, you can then decide whether to move forward with the first phase. If so, then the MVP will be an approved feature in the Program Backlog and appear in an earlier phase on the Program Roadmap. Any additional research work or architectural work to set up for the next phase would be tracked as an enabler feature in the backlog.
Enterprise Design Sprints at the program level will most likely require some input from people on the agile teams. If Product Owners have difficulty getting some time from their team members, Product Managers will have more difficulties pulling in people from multiple teams. Therefore it is very important that the program management understands the value of spending time analyzing the context, system, value, and risk of items before moving forward with development. It doesn’t have to take forever but skipping this step will cause an unfortunate cycle of dealing with surprises, costly patches or rework.
The sprint itself
Inspiration for topics could come from sources like users, leadership, the Program Roadmap, or from cross-cutting issues identified by the teams. If a roadmap exists, then the Product Manager will look at the next phase in the roadmap and pull in the next program epic or feature.
Other roles like system architects, UX, DevOps, and so on can also champion and facilitate an Enterprise Design Sprint around a topic. Regardless of the source of the topic, you’ll want to run through the same steps. For example, if you’re running a sprint to improve code maintenance, then your “customer” might be your operations team.
Depending on the topic it might make sense to invite one or more Product Owners and relevant members of their team to the sprint. If you’re running a sprint at the program level I recommend also including system architects and UX governance.
The sprint itself at the program level is very similar to the team level sprint but you may be looking at issues that cross-cut teams vs. ones that are mainly a concern for one particular team. However, a high-risk topic could also be a good candidate for a program sprint. At the program level, use Enterprise Design Sprints for more complex issues, defining and breaking down epics and features, or creating a general vision.
There are two types of the roadmaps that Product Managers need to keep track of. The one that shows current commitments and likely changes, which is the Program Release Roadmap, and a set of “Product Roadmaps.” If your program works on one main product together then you might only need one Product Roadmap but you will probably be making progress along multiple products once you gather 5 to 12 agile teams together in a program. The Product Roadmap shows potential phasing of changes with no set dates. That’s because the dates will depend on when the teams commit to the changes, which depends on priorities, capacity, and other dependencies.
The Product Roadmap is updated and maintained as items are implemented. That Product Roadmap will have swimlanes for the different teams, which means that each Product Owner will also have their own Team Roadmap and Product Roadmap that shows how the team’s work contributes towards the Product Vision. A Team Roadmap could include items from multiple Products and a Product Roadmap could include changes and initiatives required for multiple teams. Having a tool specifically designed for roadmapping and product management will help a lot to save time and reduce confusion about what you’re working on when. Most of the tools allow you to create these nested roadmaps with special views for different audiences.
Whether or not teams complete Enterprise Design Sprints together, they should share results and store information that they gathered about the as-is state, customers, business process, and technical design somewhere that is accessible to everyone. That will avoid duplication of efforts and knowledge gaps. It will also be helpful for onboarding new team members. The outputs of one sprint can inform the inputs of another, so you can build upon your earlier work. Referencing insights from older sprints can also provide a steady stream of new topic ideas.
There should also be metrics defined at each level and an effort to view not only the feedback and insights from one product but the impact of those metrics across the entire experience. This will help to communicate the value added by the investment, to identify new problems and opportunities, and to motivate the team to work towards improving the quality of the experience and business. For example, at the program level, you could be looking at how individual stories contribute towards solving the business problem that the feature aimed to address. Product Managers will also want to look across “features” and epics to see if they are contributing towards general business goals. This real world feedback will help you calibrate your prioritization framework to make better estimates about what will end up providing value.
Linking sprint outputs and the Program Backlog
By the end of the Enterprise Design Sprint there will be an MVP, roadmap, and long-term vision prototype. The Product Manager will use that information to determine which features will make it into the Program Backlog, where they will be available to be picked up by teams. Any stories that were identified during the sprint can also be attached to that feature. If the feature requires multiple teams to implement it, then there will need to be some coordination between the teams. Perhaps you have one team implement a set of stories before the other does, in which case your roadmap should include not only the features you want to deliver in the first phase, but also some information about which stories are needed and who can do what. This is why pulling in Product Owners to the Program Enterprise Design Sprint is beneficial so you can work out these issues during the sprint.
System demos
Teams will work on their components of the feature separately but demo together, so each team can invite their own stakeholders, plus any stakeholders that were involved in the Product Manager’s sprint. This helps with keeping everyone on the same page without spending time in multiple reviews.
Making progress on medium and long-term initiatives
Product Owners from each team are encouraged to meet with each other and the Product Manager regularly. They can use that time to share knowledge, updates, and brainstorm ways to sequence their roadmaps or work through issues. It’s also a forum for everyone to share risks and issues, customer feedback, and successes. If there’s a lot of follow-up or coordination required to move something along then the Product Owners and Product Manager could split up the tasks. The Product Manager can also use the time between the system demos to review metrics, supplier progress, industry trends, and new initiatives coming up, or brainstorm with the system architects and UX governance team.
Repeat the process
After gathering feedback during each system demo, the program is updating their knowledge base, perhaps tweaking the order of the backlog, and thinking about new Enterprise Design Sprint topics to cover. With a few weeks or months between program increments, it’s a great amount of runway to start planning a sprint on a more complex topic before the next program increment starts. Just keep iterating and cycle through which Product Owners you bring on. One Enterprise Design Sprint with the Product Manager and two Product Owners will probably set the POs up with enough information and direction to keep moving for at least a program increment or more. POs can then run their own individual sprints while the Product Manager works with other Product Owners, architects, DevOps, or UX on another sprint.
Next steps
This was the second 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 programs working together within a Value Stream.
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 an agile program? How did you manage the backlog across multiple teams?