Scrum: failing faster to succeed sooner
What is Scrum? Am I doing Scrum correctly? Scrum is the most popular form of agile product management, yet it’s surprisingly difficult to find a satisfying definition. This is because Scrum isn’t a process; it’s a framework for developing and evolving your own process. Teams should evolve their own process framework following the principles of Scrum. If a team does Scrum for a year and they still have a board with to do, doing and done columns, like many other teams: they have missed the point of Scrum.
Think of it like using a basic soufflé recipe to develop your own soufflé recipe. The goal isn’t to master the basic soufflé. That’s just the starting point. The basic recipe helps you understand why certain ingredients and steps are included, how they impact the outcome and what a soufflé should look and taste like. Following these principles, you can adapt the recipe to fit the ingredients you have available locally and your own cooking style. After each change you decide what worked and what didn’t. As you learn, you adjust both the recipe and the cooking process. Your soufflé recipe might look nothing like the original, but if it works for you then you’re doing it correctly.
What is Scrum, exactly?
Ken Schwaber and Jeff Sutherland co-created Scrum in the early 1990s. In The 2020 Scrum Guide, they define Scrum as “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” That might not feel like a satisfying definition, but as they explain, the Scrum framework is purposefully incomplete. It’s meant to be built upon by the people using it.
For those who need a more exact definition that includes the core components of Scrum, Schwaber and Sutherland state that:
Scrum requires a Scrum master to foster an environment where:
A product owner orders the work for a complex problem into a Product Backlog.
The Scrum team turns a selection of the work into an Increment of value during a sprint.
The Scrum team and its stakeholders inspect the results and adjust for the next sprint.
Repeat
Source: The 2020 Scrum Guide
While the The 2020 Scrum Guide offers a reassuringly detailed explanation of each element in the Scrum framework, rigid adherence to what Scrum “should look like” often leads to poor implementations. Just as you can have all the ingredients and still fail to make a soufflé, you can have all the components of Scrum and still fail to get the results you want.
Image Source: The Three Pillars of Empiricism (Scrum)
The three pillars of Scrum theory reflect its roots in empiricism — the belief that knowledge comes from experience. Scrum theory emphasizes that decisions should be made based on observation, which requires transparency.
Teams must start Scrum with an empirical process where they expect the unexpected and are defining the process as they go, because they haven’t implemented Scrum in that exact context before. As they gain experience, most teams should move quickly from an empirical to a defined process in which steps are clearly understood and repeatable.
The Scrum framework includes a Scrum team structure, Scrum events and Scrum artifacts (logs that show commitments and goals), but it also encourages teams to adapt the process as they use it. A good Scrum implementation preserves the core principles and elements of the Scrum framework, while applying those elements to adapt the Scrum process to the people using it.
Scrum is not a recipe for perfection, it's a recipe for continuous improvement. Those changes come from within the team as you observe and adapt the Scrum framework to fit your project goals and constraints.
Getting started with Scrum: What kind of projects is Scrum good for?
Scrum is designed to help teams manage complex projects that have many unknowns or changing requirements. It reduces risk by helping teams fail fast and change direction, instead of spending too much time on the wrong path. This ability to respond to changing requirements quickly is an advantage when developing digital products and services. Customer expectations, technology and the competition can change before a project is complete.
Scrum works well for complicated projects with several unknowns, such as unclear or changing requirements, questions around what technology will be used or how components will come together. It provides a framework that keeps projects moving despite these unknowns. Scrum isn’t a good choice for projects that already have an obvious solution with clear requirements.
How to pick your Scrum team: Mindset matters
A successful Scrum implementation requires a different mindset. Your Scrum team needs to embody the five values of Scrum so that they can use the Scrum framework to improve both the product and process.
Scrum teams need to be brave. The work is not always clear up front, and neither is the technology. Still, you need the team to commit to a goal and persevere to reach it. The process only works if the team is able to focus and dedicate themselves to finishing the items in the order set by the product owner. It’s challenging, but the people you want on your Scrum team will thrive when given a challenge instead of a task.
Five values of Scrum
Commitment. Because we have great control over our own destiny, we become more committed to success.
Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
Openness. As we work together, we practice expressing how we're doing and what's in our way. We learn that it is good to express concerns so that they can be addressed.
Respect. As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
Source: The Scrum Alliance, What is Scrum backgrounder
Many of these values can be found in people with what we call the builder ethos. The builder ethos is a philosophy that recognizes that outstanding digital experiences start with those who build them — developers, content creators, marketers, editors and designers. These “builders” are defined by how they approach a challenge and create a solution.
Builders don’t just stop when they have a good idea. They work with others to find ways to bring good ideas to fruition, fast. They’re not afraid to expose problems and make mistakes — failure is an opportunity to learn. These are people in your organization who embrace new technology and are eager to push the boundaries to see what it can do for them and your customers.
Builders are people who get things done even when it's unclear exactly what needs to be done. These are the people you want to empower with flexible tools, collaborative support systems and an agile framework like Scrum.
Put the right people in the right role: Product owner, Scrum team and Scrum master
Now that you understand the mindset you want on the team, let’s talk about roles and accountability in Scrum. There are three roles in Scrum: The product owner, the Scrum team, and a Scrum master. Accountability among the roles is a core principle of Scrum. Defining each role’s area of accountability and measures of success provides transparency.
Product owner
The product owner has sole accountability for internal investment. Success in this role means getting the biggest return on the work completed. They own the product outcomes and are responsible for prioritizing the order of the work on the product backlog (list of related project goals). They are the only one who can change the order of the product backlog or remove goals.
Notice that the role is “product” owner, not “project” owner. Their goal is not to keep the project running, but to identify the steps that will deliver the most valuable product outcomes. A project mindset can lead to long development time and a complex product to maintain. A product mindset focuses on the value of the outcome, taking into consideration market demand and cost of maintaining the product. The product owner needs to be ready to say no, cut products that no longer add value and keep the team focused on the next step that will add the most value.
Scrum team
Team members are solely responsible for quality. In each sprint the Scrum team chooses new goals from the top of the product backlog. They need the freedom to determine how many goals they can accomplish in each sprint without sacrificing quality for quantity.
Success from the Scrum team means delivering work that is fit to purpose, fit to use and fit for change. It should meet whatever standards your customer uses to define quality and be quality work from an internal or backend perspective as well. The Scrum team is responsible for considering how hard a product will be to maintain and evolve from the get go. Just as you can’t fix a fallen soufflé quickly, you can’t remedy poorly built software without significant reinvestment.
Scrum master
The Scrum master is someone who has already mastered Scrum. They've implemented Scrum before and can help you develop your own version of the Scrum framework. Their goal is to ensure that the team is learning and implementing changes quickly.
Whatever success metrics your company chooses, the Scrum master will be accountable for the rate of change of these metrics. For example, if your company cares about reducing the support cost of newly delivered functionality, the team will be held accountable for bringing the cost down. The Scrum master of that team however will be held accountable for how fast the cost is coming down.
Follow the principles of Scrum and learn the reason behind them
Understanding the principles of Scrum and the why behind them is an important step in successfully getting started with Scrum. Once you understand how components of Scrum work and what they contribute to the process, you can begin adapting the process.
Scrum is iterative: Build >> test >> learn >>repeat
The core purpose of Scrum is to help teams learn faster and reduce the risk of a big investment in the wrong direction. Scrum teams operate on set requirements and assumptions during each sprint, testing at the end and then adjusting before the next sprint. They focus on the task at hand instead of trying multiple things at once. With each sprint they have an opportunity to learn and course correct. This enables the team to learn fast and keep moving forward without big setbacks.
For example, if a team assumes that customers want a cheese soufflé they could figure out all the logistics of sourcing cheese and test multiple cheese soufflé recipes simultaneously. But what if their customers are lactose intolerant? All that time invested has been wasted. By contrast a Scrum team that uses their first sprint to produce and test one type of cheese soufflé, would learn that cheese soufflés were not viable sooner, saving time that can be invested in developing and testing more products.
Use timeboxing to reduce risk
When you dive into Scrum, you'll notice that Scrum events are timeboxed: the daily Scrum meeting is 15 minutes, a sprint is typically two weeks, and so on. This reduces the risk of investing too much time up front before testing your assumptions. The goal is to make a decision and then focus on delivering a high quality piece of work that tests that decision and provides the opportunity to learn and adapt quickly.
It’s worth noting that the time limits proposed in the Scrum framework can be adapted to your business. Two weeks is the most common, but some companies with longer release cycles find that longer sprints work better for them. The key is to limit the time and resources you invest before testing and adapting as needed.
Learn faster than the competition
Scrum is not about delivering a perfect product in a short sprint. It’s about learning and adapting, faster. Learning faster helps companies get to market faster and adapt to market changes midstream. This is critical in a fast-moving market where products can become outdated before they even launch.
Take time to reflect on the product outcomes and the process
A key pillar of Scrum is inspection. Reviews and retrospectives are built into the Scrum framework so that teams can inspect the product and process to determine what needs to change. The external market is always changing. Scrum is a way to enable your internal process to keep up through iterative change not just to the products, but to the process itself. If done correctly, you shouldn’t need to overhaul your processes in a few years because they will be continuously adapting to everything you learn each time through.
Visualizing the work provides transparency for better decision-making
Scrum artifacts (the product backlog and sprint backlog) are used to visualize key information such as goals, commitment and the definition of done. In many processes, knowledge work is internal so it's hard to see the waste. Scrum shows these steps so that everyone is conscious of how much work goes into each sprint. A simple Scrum board categorizing tasks into “to do,” “doing” or “done” can serve as a starting point that can be adapted as you continuously learn and change your process.
Set yourself up for success
Scrum is easy to explain, The 2020 Scrum Guide maps out all the components, but it's hard to do effectively because it should be changing. Set yourself up for success by considering the people, playbook and platform that will support your Scrum implementation.
People: Use Scrum to bring together people who embody the builder ethos and have digital skills the team needs to complete the project. Choose a Scrum master who has successfully implemented Scrum before. They play an important role in helping your team implement and follow the Scrum framework, keeping teams focused and ensuring that they take time to reflect and tweak the process.
Playbook: The way businesses deliver digital experiences is changing. Digital leaders are adopting agile practices to deliver better digital experiences faster. Teams need permission to fail and learn as they define the new playbook for the digital-first era.
Platform: Agile teams need tools and technology that support faster work flows, collaboration and autonomy, and are flexible and extensible giving users more opportunities to push the boundaries of what’s possible.
