Myths can hold us back from our highest potential by creating confusion and misdirection. In this article, we will debunk 10 common myths about Scrum. Now, I'm not saying that chaos dragons are real, but I am saying that Scrum is not chaos.
Myth #10: Scrum/Agile is More Expensive than Waterfall
Reality: Cost-Effectiveness Through Waste Reduction
Contrary to popular belief, Scrum teams are not more expensive than teams using waterfall; in fact, they often prove to be less costly. This cost-effectiveness is achieved by significantly reducing waste through incremental delivery, ensuring that resources are directed towards what is truly needed. Why is this important? According to the 2019 Feature Adoption Report by pendo.io, 80% of features in the average software product are rarely or never used(!). This means that companies have invested significant amounts of time and money on functionality that no one is using!
Scrum can help. The iterative nature of Scrum allows for continuous assessment and adjustment, preventing unnecessary expenses associated with developing functionality which is not needed. Because value is delivered incrementally each Sprint, stakeholders can provide earlier feedback about what features are actually valuable and which are not needed. Scrum teams can adapt based on feedback received and can shift their focus away from unnecessary features towards features which deliver the most value. By shifting towards what is more valuable, Scrum teams actually save the organization money.
In addition, there are two key accountabilities within Scrum, the Product Owner and the Scrum Master, which are sometimes perceived as expensive additions. However, the Product Owner maximizes product value by steering the team toward high-priority features, while the Scrum Master's role in improving Scrum adoption and enhancing organizational agility is an investment that pays off in delivering value consistently and efficiently.
Myth #9: Documenting Business Requirements Upfront Reduces Risk
Reality: Mitigating Waste, Not Reducing Risk
The idea that extensive upfront documentation reduces risk is a fantasy. In reality, creating a colossal requirements document up front often leads to waste. Think of it like this. Creating a large requirements document is an investment in time and money. Investing that time and money up front assumes that the team will learn nothing new from the customer about what is needed. What a waste!
Rather than spending a lot of time up front creating a massive requirements document, a better approach is to take what we know and get started. Agile teams deliver value incrementally in small, usable pieces of the larger product. By delivering value this way, an Agile team has the opportunity to solicit feedback from the customer each Sprint. This means that each Sprint, the team learns more about what is useful to the customer - and more importantly - what is not useful to the customer. After each piece of functionality is delivered, the team can change direction based on customer feedback.
Myth #8: Scrum Means No Documentation
Reality: Balancing Working Software with Essential Documentation
While Agile frameworks value working product over comprehensive documentation, this doesn’t mean that Agile teams have no documentation at all. Instead, each Agile team or organization determines the right amount of documentation that is needed for them in their unique environments. Heavily regulated environments may need more documentation than less heavily regulated industries. Striking the right balance for each organization’s unique environment ensures teams focus on delivering valuable products without unnecessary documentation.
Myth #7: Sprints Must Always Be Four Weeks
Reality: Flexibility in Sprint Duration
The Scrum framework places a maximum duration for the Sprint. The maximum duration of the Sprint is set at one month. The Sprint can be any duration of one month or less. This means that Scrum teams can choose a one month Sprint, a one-week Sprint, or even a one-day Sprint.
The most popular Sprint is two weeks, but the Scrum team should select whatever duration will allow them to create a usable product and coincide with any other organizational timeframes or events. The Sprint is an investment in time, so in riskier environments, a shorter Sprint duration is better than a longer Sprint duration.
Myth #6: Scrum Doesn't Allow Changes During a Sprint
Reality: Acknowledging and Managing Change
While it's generally recommended not to change the Sprint scope once it begins, Scrum acknowledges that change is inevitable. Sometimes the Product Owner has a change that they would like to add to the Sprint, and sometimes Developers are coming to the Product Owner to say that they may not be able to complete everything that they had originally planned for the Sprint. When this happens, the Product Owner and Developers should collaborate to determine the best path forward. In the first example, if Developers can add scope to the Sprint without putting the Sprint Goal at risk, they may collaborate with the Product Owner and agree to add the additional change. In the second case, if the Product Owner has some scope that they can remove from the Sprint to help Developers increase the chance of delivering a done increment which meets the Sprint Goal, they should work together to identify and remove that Scope. See our recent article, “How to handle unplanned work in Scrum” for more on this topic.
In the worst case scenario, if the Product Owner decides that in light of recent changes the Sprint Goal is obsolete or no longer necessary, they may decide to cancel the Sprint. See our recent article “Scrum is not an excuse to ignore an emergency” for more on how to handle emergencies in Scrum.
Scrum is used in complex environments more is unknown than known, and in this context sometimes change is necessary. This recognition of the need for adaptability ensures that the Scrum team remains responsive to evolving requirements without compromising stability.
Myth #5: Scrum Only Works for Small Teams
Reality: Scaling to Large Teams and Beyond
As organizations grow in their adoption of Scrum, sometimes there are situations where 3 or more Scrum teams are working together to support a single product. For example, there may be 3 or more Scrum teams working together to support a particular software product, such as a data processing system or a reporting system. When that happens, sometimes the team needs to select a scaling framework.
Scaling frameworks help manage dependencies, ensure alignment, and facilitate communication across teams. Scrum can scale effectively to large teams through frameworks like Nexus, Large-Scale Scrum (LeSS) or the Scaled Agile Framework (SAFe). Its adaptability makes Scrum applicable to various team sizes and organizational structures. For more information on Nexus, see our recent article Why Nexus is the Best Scaling Framework for Scrum Teams.
Myth #4: Scrum Requires No Planning
Reality: Adaptive Planning for Project Success
While Scrum emphasizes adaptive planning, it does not eliminate the need for planning altogether. Scrum teams plan on many different levels. Not only does the Scrum team create a plan for each Sprint, but the Product Owner works together with the Scrum team(s) to create a forecast which crosses multiple sprints.
In my experience, Scrum teams plan more than teams using a traditional waterfall approach because rather than creating a plan once at the beginning - as traditional Waterfall teams might - Scrum teams are continuously monitoring their progress and adjusting their forecast - or roadmap - accordingly. See our recent article “Forecasting for Scrum Teams with Roadmaps” for a few roadmap templates which you may find useful.
Myth #3: The Scrum Master is the same as a Project Manager
Reality: Facilitating, Removing Impediments, and Coaching
The role of a Scrum Master is often misconstrued as that of a project manager. In reality, while they share some responsibilities, a Scrum Master focuses on facilitating the Scrum process, removing impediments, and coaching the team. The emphasis is on empowering the team to self-organize and deliver high-quality products. Unlike traditional approaches, Scrum teams welcome change - even late in the process - rather than focusing on strict adherence to a predefined plan.
Myth #2: Scrum is Chaotic
Reality: Structured Framework for Managing Change
Some perceive Scrum as a path to chaos due to its flexible nature. However, the reality is that Scrum provides a structured framework for managing work. It embraces change while maintaining transparency and control, ensuring that projects evolve efficiently in response to shifting requirements.
Myth #1: Customers Know What They Want
Reality: Experts in the Problem, Not the Solution
Assuming customers know precisely what they want from the outset is a common misconception. The reality is that customers are experts in understanding the problem but might not have a clear vision of the solution. Agile frameworks recognize this uncertainty, fostering collaboration between development teams and customers throughout the project to ensure continuous alignment with evolving needs.
Conclusion
As a trainer, I believe that knowledge is power. By shedding light on common Scrum myths I hope to empower individuals, teams and organizations to make better decisions. Shedding light on the truth behind the myth can improve the way that people and teams approach value delivery for the better.
Comments