Since 2020, the adoption of Scrum has increased rapidly. The following graph compares Scrum adoption in 2020 with 2021. In every industry, agile adoption has doubled.
This table shows figures from Digital AI’s 14th annual State of Agile Report contrasted with figures taken from its most recent report.
It is no wonder that with this rapid adoption of agile, several myths about Scrum — the most popular agile framework — abound. Many people using Scrum today have no formal training or are new to agile frameworks. It’s the perfect environment for myths and misconceptions to spread. In this article, we will discuss five common myths about Scrum.
(If you are new to Scrum, the Applying Professional Scrum course is the best way to get an understanding of the Scrum framework.)
Myth 1: Scrum should solve this!
Once, at the end of the first Sprint with a new Scrum Team, I was discussing the Sprint Retrospective outcomes with several supporting managers. In the Retrospective, the Developers expressed concerns about not having enough work items in the Product Backlog for the next Sprint. The few work items identified were complicated, and there were no details about how the functionality should actually work. One of the managers turned to me and asked, “Shouldn’t Scrum just solve this?”
It’s a fair question. Many new to Scrum discuss how the framework doesn’t use a requirements document. Instead, Scrum Teams use a Product Backlog to plan their work.
The Product Backlog is the to-do list for the team. It includes an ordered list of all the work the Developers need to complete to maximize the value of the product resulting from that work. The Product Backlog contains a list of new features for development, production bug fixes to resolve, fixes for technical debt, and anything else that the Product Owner believes would add value to the product.
When a new Scrum Team forms, they may not have anything in the Product Backlog. In those cases, the Scrum Team will collaborate at the first Sprint Planning meeting to decide the most valuable thing to do next. They will use that information to create their first Sprint Backlog. During the first Sprint, the Product Owner will begin documenting the Product Backlog for future Sprints. The Product Owner will also create a means for collaborating with Developers to refine and size items in the Product Backlog — usually through refinement meetings.
Development slowed down in the case of the team I mentioned that did not have enough Product Backlog items to support each upcoming Sprint. This slow down happened because the Developers spent lots of time going back and forth with the Product Owner during the Sprint to better understand what was being requested.
The team discussed the issue in the Sprint Retrospective and decided that they would amplify their focus on refinement. The Product Owner is accountable for the Product Backlog but assigned business analysts on the team to work with a developer for each feature area. From here, the analysts and Developers could break the Product Backlog items into more manageable sizes. Finally, the entire Scrum Team regrouped in a refinement meeting to finalize the Backlog item sizing. The framework itself did not solve the problem. Instead, Scrum’s built-in feedback loop allowed (and encouraged) the team to identify and solve the problem themselves.
Myth 2: Scrum would be better if we customized it!
Scrum is not a set of work instructions. Scrum relies upon the collective intelligence of those using it to figure out how best to apply it in their environment. However, some people take this to mean that they should figure out how to modify Scrum to suit their situation. That is not how Scrum works. Teams are free to explore and adopt complementary practices that work for them and a Sprint duration that is best for their environment, but they should not modify the Scrum framework itself.
Why? Scrum is a minimalist framework that contains only what is needed. Every piece of the Scrum framework is there for a reason. When teams modify any part of the framework, they don’t get Scrum’s full benefits. See our article Why you shouldn’t modify Scrum (rebelscrum.site) for more on this topic.
Myth 3: There are no managers in Scrum
I’ve heard so many people say, “There’s no manager mentioned in the Scrum framework.” My somewhat snarky response is that there is no CEO in Scrum either, but your CEO doesn’t need to begin job hunting because the organization adopted agile. Yeah, this myth really gets to me.
An organization might use Scrum for producing a product, but a traditional management structure might support the Scrum Teams. Scrum Team Developers might report to information technology managers, for example. The highest-performing Scrum Teams I have ever worked with were supported by managers who fostered self-management and engaged in removing impediments to the work. See our article Resource Managers and Scrum (rebelscrum.site) for more on this topic. For leaders who are interested in learning more about how to support an Agile team, I recommend the Professional Agile Leadership course. Professional Agile Leadership Essentials (PAL-E) is an opportunity for leaders to learn the ‘why’ behind the Scrum framework.
Myth 4: Velocity is the best way to measure team productivity!
Many managers new to working with Scrum Teams struggle to figure out how to support their teams best. They wonder how to measure success and hold team members accountable for delivery. Many of these well-meaning managers turn to velocity to measure Scrum Team performance.
Velocity is a subjective measure of how much work a Scrum Team can deliver in a particular Sprint. It’s a planning tool - not a measure of success. Why? Because velocity is not value. What matters is what is produced… not the conversation that goes into planning what is produced. Velocity is a tool used for planning, and nothing more.
Here’s how it works. Imagine a Scrum Team with a Product Backlog consisting of different types of work. Some Product Backlog items are requests for simple text changes, and others involve more complicated tasks. To better plan their work, some (not all) teams use the complementary practice of estimating each Product Backlog item using a point system, such as a scale from one to five. The team assigns higher points to more complex Product Backlog items requiring more effort. At the end of each Sprint, the Scrum Team adds the point values for each Product Backlog item that meets the Definition of Done. The sum of these points is the team’s velocity. Some Scrum teams use velocity to help them plan how much work they can accomplish in future Sprints and to forecast delivery dates, but it’s not a success measurement.
See our article “When will we get there” for more on forecasting.
Myth 5: Component teams can work everywhere
Many newer Scrum Teams try to transition to Scrum within their existing organizational structure. Consider a web team who is responsible for a website, for example. You need Java developers, content writers, testers, graphic designers, and database administrators to deliver the website. Each of these team members reports to a different manager. Testers report to the testing manager and graphic designers to another manager. In some organizations adopting Scrum, the Java developers become part of a Scrum Team, but the content writers remain in the previous structure.
In these scenarios, work will slow down because of bottlenecks. In addition, each team will have a separate Product Backlog, and the order of work in each Product Backlog may be different. Work that is considered of high importance for one team may be considered of low importance by another. If these teams have dependencies on each other, then the clash in priorities will drastically slow delivery for both teams. For these reasons, it’s important that organizations first consider what the end product is before forming Scrum Teams to deliver value.
The image above illustrates how defining products too narrowly often results in unnecessary hand-offs, where the Java team has to hand off work to a testing team or content writers to a Java team.
Instead, organizations transitioning to Scrum should first determine the product they support. Next, they should identify the skills they need to deliver that product, allowing individuals to assemble into self-organizing teams. For more on this topic, see What to consider in your transition to Scrum (rebelscrum.site).
Conclusion
The recent surge in agile adoption has meant there are a lot of folks working in agile environments without formal training. It’s the perfect breeding ground for myths, and the Scrum framework has not escaped several misconceptions.
Scrum will not solve all your problems; instead, it will make those problems visible so that the team can solve them, but only if the Scrum framework is used as designed and is not “customized.” Managers and those supporting Scrum teams must understand that managing work in a complex environment is different than managing work in a traditional environment. That means managing differently and focusing on value metrics to measure productivity rather than using simple measures like throughput. Complex work requires a different set of skills and requires collaboration across technology silos. Before forming an agile team, ask yourself, what is the product that is being delivered, and what are the skills necessary to deliver it.
For those who are new to Scrum, I recommend the Applying Professional Scrum course which offers the best overview of the accountabilities, events and artifacts necessary for a high performing Scrum team. For those who will be fulfilling the Scrum Master accountability, I recommend the Professional Scrum Master course. For those who are interested in learning about the simplest way to scale multiple Scrum teams working together on a single Product, I recommend the Scaled Professional Scrum class which presents the Nexus framework.
