In our recent article “Why You Shouldn’t Modify Scrum,” we discussed five reasons why modifying Scrum is counterproductive. We’ll expand on the topic in this article by exploring five more ways organizations sometimes change Scrum and the impacts they might experience as a result.
Remember that Scrum is a framework, not a set of work instructions. The Scrum framework is very lightweight, but what it includes is essential. Every piece of the framework is there for a reason. Making the following modifications can come with negative consequences.
1. Not having a Product Owner
There are three accountabilities in Scrum:
- The Scrum Master is primarily responsible for improving the adoption of Scrum within the organization.
- The Developers do the work of the Scrum Team.
- The Product Owner is accountable for maximizing the value of the Product through the content and ordering of the Product Backlog, which is the team’s to-do list.
Each of these accountabilities is critical to the success of the Scrum Team. The omission of any of these accountabilities negatively impacts its ability to deliver value to the organization.
And yet many Scrum Teams do not have anyone fulfilling the Product Owner accountability.
The result of not having a Product Owner
The Product Owner ensures that the Scrum Team works on the right things. Without a Product Owner, the Scrum Team is like a ship without a rudder. They might go somewhere. They might do work. But is it the right work, and is it taking the product in the right direction? Scrum Teams without a Product Owner lack a strategic approach and drift from priority to priority without anyone charting a course for the product’s overall direction.
2. Skipping the Daily Scrum
The Daily Scrum is a 15-minute daily event for Developers. Its purpose is to increase the likelihood of delivering a Done increment that meets the Sprint Goal. Many teams skip the Daily Scrum to save time, increase efficiencies, or reduce interruptions.
The result of skipping the Daily Scrum
Eliminating the Daily Scrum significantly reduces the chance of delivering a Done increment that meets the Sprint Goal. Without it, the team identifies impediments more slowly, Developers suffer in silence longer, the Sprint Backlog is less transparent, and Developers do not collaborate with the rest of their team as frequently.
The Daily Scrum often eliminates the need for other meetings. Without the Daily Scrum, teams often need MORE MEETINGS to resolve the issues that were allowed to fester because they weren’t collaborating daily to resolve them quickly.
3. Skipping the Sprint Review
The Sprint Review is the second to last event within the Sprint. It is an opportunity for the Scrum Team and its stakeholders to discuss the work completed during the Sprint and collaborate on what to do next. It is the Scrum Team’s opportunity to showcase their work and engage in discussion with their stakeholders. Teams might be tempted to skip the Sprint Review for a few reasons. Perhaps it’s been a lousy Sprint, the team’s morale is low, or there are pressing deadlines.
The result of skipping the Sprint Review
Short feedback loops are invaluable to the Scrum Team because it allows them to change direction quickly to focus on the most valuable deliverables. If a team skips the Sprint Review, they miss an opportunity to get stakeholder feedback on what they delivered during the previous Sprint and the most valuable thing to do next.
4. Blowing the time boxes
Each of the five events in Scrum has a time box. The Sprint is time boxed to one month or less, the Sprint Planning event is time boxed to 8 hours or less, the Daily Scrum is time boxed to 15 minutes or less, etc.
Time boxing each of the events has many benefits. For example, by time boxing the Sprint to one month or less, learning cycles are more frequent, and risk is limited to the cost and effort associated with the shorter time frame. Other benefits of time boxing include reducing waste. For example, by limiting the Sprint Planning event to 8 hours, the Scrum framework reduces the waste that might be created by excessive time spent building the Sprint Backlog.
The Daily Scrum has a 15-minute timebox, making it the shortest event. The 15 minute time box for the Daily Scrum is important in order to eliminate waste. However, the Daily Scrum requires focus to stay within the timeframe, and it’s easy for this event to run long. For this reason, the Daily Scrum is the one event where it is most likely for the team to blow the time box.
The result of blowing time boxes
I once had a team whose Daily Scrum frequently exceeded one hour. After the first time, Developers gave it a second chance and still came to the next one. But when we continued to blow the timebox over a few days, no one attended the Daily Scrum. It became a drain on everyone’s time, energy, and momentum. Extending the discussion problem solve an issue rather than simply focusing on identifying the issue as well as those who should later get together to solve it caused a lot of wasted time for the team. Scrum is founded upon empiricism and lean thinking. By blowing the time box of the Daily Scrum, the team was introducing waste - and frustration - which is not in alignment with lean principles.
5. Team size too large
The Scrum Guide does not set a maximum team size but does say that Scrum Teams are typically ten or fewer. The guide states, “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint.”
Sometimes teams newer to Scrum think it’s harder to deal with having multiple, smaller teams than one large team, so they ignore the direction to keep team members low.
The result of a large Scrum Team
I have heard of Scrum Teams with 20 (or more) team members, and the result is they struggle with conducting any of the events within the timebox. They engage in minimal collaboration, and the interactions they do have are wasteful because collaboration activities are impossible with too many people.
More mature Scrum practitioners have smaller Scrum Teams supporting a single product. These teams handle their collaboration activities by sharing in the refinement process or using the Nexus framework to scale.
Conclusion
It can be tempting for those newer to Scrum to think that adjusting the framework will make it easier to adopt. However, when teams modify Scrum, they don’t experience its full benefits, resulting in lower-performing teams and slower value delivery to the organization.
New to Scrum? I recommend the Applying Professional Scrum (APS) course. APS allows those new to the framework to understand the Scrum roles, artifacts and events. Both public and private classes are available. Contact me to learn more.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum trainings or contact us to discuss private training and consulting options for your organization.