Your Scrum Is Probably Missing Agility
Special thanks to Jim Highsmith and Simon Orrell for their feedback and validation
It is very possible to do Scrum without being agile. It’s a tool, and many (most) companies have found a use for it without embracing an agile mindset. Companies often use Scrum to control employee productivity and predict output delivery, expecting it to lead to better business results. And it does to a small extent, which explains why the practice is so common.
However, Scrum was designed for agile organizations. It is designed for empowered teams that can adapt and make strategic decisions in service to business goals. It is intended to embrace the uncertainty of ever-changing markets and the complexity of customer needs. And it improves options for how product teams can respond to change. When Scrum is used for its intended purpose, it is potent. Scrum does not make an organization agile, but it can support an agile organization.
My Journey
When I first started doing Scrum, I thought we were being pretty agile. We were doing the steps, so how could we not be?
Years later, when I began to work in organizations rooted in an agile mindset, I discovered just how different that implementation of Scrum was compared to anything I had ever experienced before. It was the same steps but a completely different experience. It changed my perception of agile forever. I realized that most agile organizations are leaving a tremendous amount of value on the table.
Today, I work with dozens of “agile” companies full of agile coaches. They all have an idea of what being agile is and where it can take them. And yet, they continuously fail to imagine just how different working in a much more agile environment can be. Once, I worked with a client whose agile coaches and product owners read the book Inspired by Marty Cagan. It’s a book that highlights the value of empowered teams led by context and measurable goals. Yet, when I asked them what they thought, they felt it largely confirmed what they already knew. Judging by their behavior though, they had completely missed the point of the book, continuing existing patterns of solution design coming from internal stakeholders and metrics focused on delivery output rather than customer behavior and business outcomes.
When I first read that same book many years ago, I had the same impression as them. I too thought it was reinforcing what I already knew. It wasn’t until years later when I reread the book that I realized he was talking about something very, very different. My younger self, just like my clients, failed to imagine the world Marty was talking about, and I effortlessly rationalized his lessons to fit my current way of working.
Most of us who aspire to be agile, have never seen its potential, and cannot imagine it.
I want to change that in this article. I hope that by using Scrum as an example, I can show the practical difference between a team doing agile and a team being agile. And, I hope that you will have a new appreciation of what’s possible. Please note that what most agile teams do is NOT bad. It is better than many other ways of working I’ve seen, but it can be MUCH better.
Let’s test if your team's behavior is actually approaching Scrum in an agile way.
The Daily Scrum
(often mistakenly called the Stand-Up)
Most Agile Teams: Each person provides their status, detailing what they did the day before and what they plan to do today, maybe raising a concern if the specific work they’ve volunteered to do is blocked in some way. If that issue exists outside the development team, it goes to the Scrum Master to resolve. Usually, these teams are more concerned about the meeting not going over 15 minutes than about how they can collaborate and adjust their plans. The product owner is almost always there to push for solutions and report status back to higher-ups.
Improved agility: The team uses the meeting to collectively plan their day together. Each person focuses on the needs of other development team members to meet a sprint goal and adjust the sprint backlog to help meet the sprint goal. Blockers are identified and the team takes responsibility for resolving them, sometimes with help from the Scrum Master. The developers own the plan for the day, and each would be able to summarize that plan by the end of the Daily Scrum.
Why is an improved Daily Scrum better?: Developers become empowered and focused on the overarching needs of the business and customer. That means better alignment, chances for innovative solutions, product quality, and motivation. They become more team-oriented, rallying around other team members in need because they collectively own the solution, not just the work they’re assigned.
Sprint Planning
Most Agile Teams: After reviewing their capacity, developers pick up the top items from the backlog. This is often the first time they’ve seen many of these items, and they estimate how much time it will take during that meeting. The product owner looks for things that could fit into the sprint, and the developers decide on what they can commit to so that stakeholders have a clear expectation of what features they will be getting. If there is a sprint goal, it’s a summary of the general theme of the work that will be done.
Improved agility: The product owner sets the tone for the goal of the sprint, working with the developers on what would be the most valuable thing they could do in the next sprint. Developers then decide on the items that they have reviewed and improved over the previous sprints that they want to pull into the sprint backlog. They take into account dependencies, similar work, and sequence to deliver the most impact and learning possible. The team commits to the goal of the sprint, while the expected work to meet that goal continues to unfold, recognizing the work as a forecast that changes as the effort becomes more certain. They will also discuss potential risks and contingency plans.
Why is improved Sprint Planning better?: Developers have better context and an opportunity to utilize their skills, knowledge, and expertise to identify novel solutions. They will deliver better system architecture because they will have a longer view of what it will be used for. And, they will be able to more easily adapt to any issues that happen during the sprint because they are focused on a goal, not on the arbitrary work selected.
Sprint Review
(Often mistakenly called Demo)
Most Agile Teams: The latest product changes are shown in front of internal stakeholders. This may solicit additional changes or feature requests from stakeholders. There tends to be either applause for work well done or, unfortunately, frustration when the work doesn’t meet stakeholder expectations. Often, the product owner is responsible for demoing the completed work.
Improved agility: Customers and users are part of the review group and take primary focus over internal stakeholders. In the beginning, the product owner sets the stage for the outcomes that the sprint intended to create including the sprint goal. Throughout the review, the team asks probing questions to solicit feedback and help inform them on what work they should consider for future sprints. The product owner reviews longer-term plans and again solicits feedback to validate if those goals are truly the most important. Ideally, the customer demonstrates the completed work in a user acceptance or higher-level environment.
Why is an improved Sprint Review better?: The most important learning comes from customers and users. Their decision to use and purchase products is what drives business results. They are also a source of purely objective learning. Having customers in the room creates deeper empathy, often in ways a business would never consider, and it gives the work a tangible sense of meaning that further motivates Scrum teams.
Retrospective
Most Agile Teams: Retrospectives operate as a place to blow off steam from a challenging sprint and create a list of problems that no one expects will ever be resolved. This often follows a “what went well, what didn’t go well, what can be improved?” format. The meeting is generally on the shorter side of meetings because people often think it gets in the way of productive work.
Improved agility: The team takes dedicated time to celebrate their work and new learnings. But they mostly think about what they can do to learn faster and deliver greater value. Formats are varied to keep it fun and offer new perspectives to brainstorm areas for improvement. Areas that can be improved are turned into 1-2 changes to the way they work and what they’ll use to test that they improved/impacted their way of working. These are added to the SPRINT backlog, which team members take responsibility for enacting.
Why is an improved Retrospective better?: With focus and validation, the small improvements that the team delivers have an exponential impact over time. It helps to develop deeper and more shared learning. And it further reinforces the autonomy and mutual support of the team.
Product Backlog
Most Agile Teams: There are 200 plus stories that define requirements for features provided by stakeholders and the product owner. Often, the stories start with “as a user”. The details of the story either lack any context or are extremely specific, broken down into a long list of QA-ready requirements. Often, stories are split up based on who is doing the work, such as front-end versus back-end development. If stories have been estimated, they are usually estimated by how much time they will probably take even though this may be represented in story points. A person outside the team would not understand the goals or longer-term plans for a product by looking at the backlog without extreme effort.
Improved Agility: The backlog shows only the most important and relevant items without planning much beyond the level of certainty of the work that will be coming up (generally around 30 items), keeping the priorities clear for everyone. Items are often removed as the team learns to maintain clarity. Only items expected in the next couple of sprints have details and often include experiment metrics to determine if each item provides the intended value. The backlog includes more than just feature work, but all work that the team will do in coming sprints. Items focus on the needs and challenges of the users the product plans to solve. Details and requirements of the solution to those needs are defined by the team. Each story is owned by the team collectively, aligning different skill sets as needed to solve a customer's need. Last, there is a structure in place to clearly show how the items in the backlog equate to the team’s and organization’s longer-term strategy and metrics. A person on the outside looking at the backlog would have a pretty good idea of what the team is working on and why without much effort.
Why is an improved Backlog better?: The backlog can align everyone in the organization on customer needs, sparking greater unity, deeper conversations, and novel ideas. Developers gain a much deeper context of the needs they are solving and how they support business goals. They also gain a sense of autonomy and commitment by owning the solution and staying focused on solving customer needs over stakeholder pressures to deliver features that don’t align with business goals or customer needs.
Act of Refining
(Often confused with a Refinement Meeting)
Most Agile Teams: The product owner shows stories with a full set of acceptance criteria, often with little detail about the user or the problem to be solved, instead focusing on the solution that needs to be delivered. These stories may also be segmented by functions, such as frontend and backend to make it easier for developers to work on them separately. The team reviews the story to see if it is too big to be completed in a single sprint. If it is, the story is split into smaller pieces. Then, the developers break the story into tasks and estimate how much effort it would take in story points or hours to help create predictability for other stakeholders, establishing a velocity. They also determine if there are any dependencies to the story being completed. The goal is generally to estimate stories as quickly as possible.
Improved agility: The product owner sets the stage by sharing the long-term vision and desired outcomes, primarily focusing on the “why”. This is where the product owner can really shine as the voice of the customer, sharing the deep problems and needs of users and customers without diving into solutions. While most refining focuses on work in upcoming sprints, the team also takes time to review the bigger picture to make sure that work is effectively achieving team and organizational goals. If it is not, the team, along with other stakeholders that may be able to help, brainstorm possible solutions to achieve those outcomes, thus creating or refining the items that can be pulled into a sprint backlog later. There are many ways to achieve an outcome, so often they use divergent and convergent brainstorming methods to come up with many ideas and then narrow it down to the best options. Those items are further refined into the tasks needed to complete the item. There may be further discussion to see if the work can be sliced more to get the most value while reducing the level of effort (for example, can you get 80% of the value by doing 20% of the tasks?). Often, estimation is used to ensure everyone on the team has a shared understanding of the work and that they are completing work sustainably.
Why is improved Refinement better?: Context matters a lot in both innovation and product quality, and leveraging the entire team in solution design and brainstorming amplifies the quality of decisions, commitment to those decisions, and important diversity of thought often missing from many products including knowledge of new technologies, individual skillsets, and deep understanding of organizational systems that could impede a solution otherwise. Similar to other improvements, improved refinement reinforces accomplishing goals, learning, and outcomes over completing tasks.
Closing
Hopefully, I have succeeded in this article where many others have failed, to give at least a glimpse into the workings of the world’s most agile organizations and how very, very different they are from the vast majority of the 70% of US companies that use agile processes but have not adopted the mindset. I have worked with dozens of teams and organizations on agile and Scrum practices. I’m confident that while many people have experienced Scrum, few have experienced a fraction of Scrum’s potential.
I had a hard time deciding where to stop this article. There are many other topics I wanted to touch on like what outcomes and sprint goals look like, deadline management, project budgets, cross-functional teams, safe-to-fail, product discovery, and so much more. If you want to chat about any of the things omitted from this article or want to challenge anything I’ve written, please connect with me at https://www.linkedin.com/in/mikebermanproduct/
