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.
In the Enterprise Design Sprint follow-up post we talked a little bit about how to move forward when you can’t deliver all of the value by yourself and need to work with other teams. We talked about aligning roadmaps, handling dependencies, and running more Enterprise Design Sprints together.
That process can work well if you’re coordinating schedules and sharing information with a few teams. It’s a quick way to merge Enterprise Design Sprints with other product development processes whether you’re using agile or more waterfall approaches. You could fit in an Enterprise Design Sprint whenever you need to break down a big problem or establish a vision.
Why you might want to scale
If you have a lot of teams working at many different levels, both within and outside of your organization, then you’ll benefit from a more organized structure. Without a plan to scale you’ll probably end up spending all of your time in meetings. Or there will be inefficiencies if other teams are working on initiatives that you’re unaware of. Interviewing the same set of users multiple times, two teams building the exact same app, or one team accidentally breaking something another team is working on, is not a great use of time or money.
Some people might think, let’s just build an “innovation team” that will tell everyone else what to work on so other teams can focus on execution. Centralizing all of the analysis and design work is detrimental because it will slow down progress as the centralized team becomes the bottleneck. Teams also have critical on the ground information that could influence the value added and success of a project. Centralizing analysis also means that information could be stale by the time the people actually building the solution are ready to tackle it.
Not to worry because in the next few posts we’ll talk about ways to use a combination of Enterprise Design Sprints and a few shared resources to get around those problems. Enterprise Design Sprints can work at the team, department, or enterprise level to share system understanding, explore ideas, gain user feedback, and build out roadmaps. You’ll need the same range of perspectives at each level, including business, user, technical, internal and external stakeholders. However, the nature of the problems you tackle and the level of detail may depend on the mission of the groups involved. For example, some groups may be exploring business models for the next few years while others may be looking optimizing interactions via one channel over the next few months.
To better illustrate how Enterprise Design Sprints can be used we’ll look at how they can fit into the different levels of the popular Scaled Agile Framework. The framework helps provide a structure for managing software and systems engineering projects that include hundreds or thousands of practitioners.
Intro to the Scaled Agile Framework
If you’re not familiar with the Scaled Agile Framework, or SAFe, it’s a methodology for thinking about how agile practices could scale across multiple teams and programs, which they define as “release trains.” The general idea is that there are cascading backlogs of work at each level, informed by the enterprise strategy. Various owners and managers help shepherd changes through the process. SAFe describes how to manage the flow of work and features to be delivered, and provides some information about the types of modeling and knowledge you might want to capture and store as you figure out what you want to add to your backlog.
Review their site, www.scaledagileframework.com for more information about the details and terminology. The diagram on their site is completely clickable so you can learn more about each part.
Using the general levels of SAFe as a model, let’s walk through how you could incorporate Enterprise Design Sprints throughout the enterprise, starting with the most basic example and working up to more complex situations. We’ll start at the bottom, with the team level.
Team Level
The smallest unit in SAFe is the agile team. General principles here will be familiar to anyone with some agile experience. The agile team is a self-organized team that gets work done. They work together to deliver demoable changes in regular increments (usually every two weeks). The changes might also go into production (aka the real world) or the team may decide to wait until a few increments have gone by before releasing a package of changes.
The Product Owner is in charge of deciding what value to prioritize and when enough value has been created to go live. They’re usually a business representative. They create and prioritize a backlog of “stories.” A story is a small increment of work that either provides some value to end users or enables future value. The team estimates the work they can take on, pulls stories from the backlog to deliver, and the whole process runs more smoothly with the guidance of a Scrum Master.
So, our protagonist here is the Product Owner. They need to figure out what to build and as one person that’s going to be difficult unless they’re the sole user and stakeholder of the solution. They’re going to need to consult with others to identify opportunities and problems to solve, figure out what processes are used and which people and systems are involved so they can tell the technical team what’s missing. They need to sort through big ideas and small changes, break things down and handle relative priorities. That and they’re expected to attend daily Scrum meetings with the team and be available to answer questions at any time. Sounds like a lot of things to keep track of.
What’s missing
Agile is biased towards action. And for some good reasons. If you spend too much time in analysis paralysis then you might not get anything out the door. You can try to predict what could happen but the best way to know for sure is to get a product or service out in the real world.
The downside of this is if your product could be potentially dangerous to someone’s health, safety, security, or reputation. Then it might make sense to take a deep breath and a step back.
Another problem is that stories are small. They have to be if you expect to finish one in a few days. So Product Owners are encouraged to sort their backlog by the highest value/cost ratio. That means the highest value and cheapest or easiest items are implemented first. However, in my experience in a complex system, that meant that the easiest stories tended to be implemented, regardless of how valuable they are. For example, updating content on a portal can be useful, no doubt. But if you’re not careful you can end up with a backlog completely full of content updates with no interactive functionality changes because those involve more work to define, plus they might require partner support.
Working from a list of stories can also be demotivating and frustrating for some team members. If they have no business, user, or roadmap context beyond whatever was written in the story then they’ll probably design their component making certain assumptions. And then get frustrated when a new requirement comes in and it seems like the business “completely changed their mind” and now they have to restructure the entire architecture.
Product Owners need a way to take in all of the disparate information they’re gathering from different sources, organize it, decide what to focus on, and communicate the context to their team. Which is where an Enterprise Design Sprint comes in handy. The facilitator of the sprint could be the Product Owner or someone else, but for now, we’ll assume that it’s the Product Owner. We’ll also assume that we’re the PO and have decided that an Enterprise Design Sprint is needed.
Enterprise Design Sprint Timing
Non-stop sprinting is helpful for delivery but not for creativity and analyzing complex problems. And even if a Product Owner has some free time to whiteboard they probably need to pull in other people from the team who are too busy building. The good news is that agile has some built in opportunities. At the end of each sprint, there’s an IP period which stands for “innovation and planning.” And good news because an Enterprise Design Sprint easily fits into that period. Product Owners could run an Enterprise Design Sprint in the first week, gather feedback, and perhaps even finish writing the stories for the next increment in that two-week period.
Even better news is that running an Enterprise Design Sprint gives you a head start on identifying changes to make in future increments. And if you pull in your development team then they have some visibility into what could be coming and can help you brainstorm functionality that you might not realize would be feasible in the short term. If you need extra time from development to support analysis then consider tracking the sprint work as an enabler task in the backlog so time spent on it can be accounted for during planning.
The sprint itself
With an idea of when to hold the Enterprise Design Sprint, it’s time to pick a topic. Pick something from the backlog to refine, review customer feedback, look to other initiatives going on that the team already does or could play a part in.
For the sprint itself, you’ll want to invite people who can represent the user, business, and technical viewpoints. In this case, your technical viewpoints will come from your team itself and any outside partners.
For the as-is day explore the daily life of your customers, the business needs, what you’re trying to accomplish and the current state. Day two is about imaging what could be. And on day three you’ll be storyboarding and working through the details. You might even be able to knock out all of your requirements and technical designs on this day too. The prototype could be made out of throwaway materials or working code. Whatever’s faster to build and easier to maintain. You definitely still want to create prototypes of both a minimum viable product (MVP) and a long-term vision.
Teams also need a roadmap. A backlog is not descriptive enough to highlight the dependencies between items and how a product and experience could evolve over time.
The Product Roadmap you create during the Enterprise Design Sprint won’t have dates because it just outlines how this problem could be solved over phases. It doesn’t take into account other priorities, architecture, and defects your team might need to work on. Your team’s Release Roadmap will show what you think you can accomplish or are thinking about working on over the next few iterations, while a Product Roadmap can help you lay out a plan for how you can go from where you are to where you could be over a few months or years. Keeping those in separate views will help with communication. If you’re working on multiple projects or initiatives then you’ll probably need multiple Product Roadmaps. For example, if your agile team works on products supporting two different business lines then you might want two Product Roadmaps but one Release Roadmap.
Finally, you’ll validate with stakeholders to see whether you’re on the right track. If you’re completely off base then there are some decisions to make. Maybe you focus your next development increment on something else like different backlog items or fixing defects. Or maybe it makes more sense to defer development as you run another Enterprise Design Sprint to identify changes that are helpful. It’s really up to your team, your risk tolerance, and how quickly you can receive feedback or deliver value to solve people’s problems.
Linking sprint outputs and the team backlog
Let’s say that you went through the Enterprise Design Sprint and identified an MVP. Those stories were written and the technical designs were defined. If you needed to add any new functionality to track metrics then those stories were written. During the increment planning session then the team will just work through the stories and estimate them. Since you already identified the value of the ideas in connection to your goals and roadmap, figuring out the relative implementation priority will be easy.
Demos
For demos, pull in the same stakeholders you invited to your Enterprise Design Sprint. You may get slightly different feedback once they see the result vs. what you learned with the prototype. Add any of their comments or questions to your knowledge base. Whether you decide to pivot or not, you’ll already have extra information for your next Enterprise Design Sprint.
Making progress on medium term to long term items
With your extra time during the development sprints, get unresolved questions answered and action items completed. Maybe you needed to identify partner schedules to see when you could tackle your long term goals. Maybe you wanted to learn more about the needs or process of a particular group. Schedule some short meetings with stakeholders. If you have a regular development cycle, then it will be easier to schedule these sessions in advance. You could also use this time to gather analytics, research industry trends, and stay up to date with broader initiatives so you’ll have new information to describe the as-is and potential to-be state.
Repeat the process
A few weeks have gone by, you’ve done a few demos and let’s say the chunk of work the team implemented is ready to go live. While you’re waiting for customer feedback to roll in, run another Enterprise Design Sprint. This time, look at the next phase in your roadmap and go through all of the steps again. Then just rinse and repeat, either working down the same roadmap or running an Enterprise Design Sprint on an entirely new topic. The feedback from your product in real life becomes an input to the as-is phase and the final to-be documentation just replaces the as-is models.
Next steps
This was the first 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 agile teams working together within a Program.
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 been a Product Owner on an agile team? What were your biggest challenges?
