Succeed with Scrum: Don't Break These 7 Rules
By Anthony Mersino
Is your organization undermining the benefits of Scrum without even knowing it? As an agile coach, I find that many of my clients today are trying to improve on their use of Scrum. Scrum is a simple agile framework that can be difficult to implement. For some, it is difficult because people continue to do things the same way with Scrum as they had done previously. Or they misunderstand or disregard the rules of Scrum that they don't feel are important. And when they keep doing things the same way and disregard the rules, they don’t realize the benefits of Scrum and agile.
What follows is my take on the seven most commonly missed or abused rules of Scrum. These rules are based on the Scrum Guide, which is the definitive guide to Scrum.
- The team is self-organizing. The Scrum Guide is pretty clear on this, stating that "No one (not even the ScrumMaster) tells the Development Team…” how to get work done. The team is comprised of motivated individuals and is intended to be empowered and trusted by the organization.
What I frequently find happening is that someone outside the team tells the team what to do. Frequently it is the ScrumMaster; sometimes it is the development manager or another functional manager. Either way, the team is not trusted or set up to operate without being told what to do. And this lack of autonomy undermines team member buy-in and motivation. - The ScrumMaster is a servant leader who teaches the Scrum team how to self-organize. The role of the ScrumMaster is widely misunderstood. As the name implies, the ScrumMaster is supposed to master scrum. They are not a project manager. Rather, they are a servant that teaches everyone Scrum and helps the team to self-organize. Done well, the ScrumMaster would be working their way out of a job as the team learns and grows.
I frequently see ScrumMasters who don't know Scrum, don’t know how to be a servant leader and don’t know how to help teams self-organize. They are often coming from other roles and they carry baggage from those roles. They frequently feel compelled to make decisions and tell the team what to do. Rather than make the team independent, these ScrumMasters make themselves indispensable. - The ScrumMaster doesn't have to attend the Daily Scrum.This is an interesting rule that aligns to the previous rule. Traditional thinking is that one person—typically the project manager—hosts and directs the status meeting. This is not how things work in Scrum.
The Daily Scrum is not a status meeting, it is a meeting for team members to coordinate their work and make sure they are on track to achieve their sprint goal. The reason it is okay for the ScrumMaster to miss the meeting is because they aren’t needed at the meeting. New or unskillful ScrumMasters can actually do more harm by attending than good.
The ScrumMaster is responsible to make sure the daily Scrum Meeting happens, that it is effective and that it is kept within the 15-minute time box. The team should have the meeting whether the SM is there or not. - Scrum teams should work cross-functionally without handoffs. Traditional teams work as if they were running a relay race: specialist team members hand off work in one phase to different specialists in the next phase. The handoffs between the silos are usually the biggest area of risk.
Scrum teams are expected to collaborate and to work cross-functionally on one or a few items at a time. Within the Scrum team, you should not hear team members talking about the "front end team" or the "QA team." The Scrum team should be operating as one team. - Hold Scrum events at the same time and place. Scrum events should be on the calendar and held at the same time and place each sprint. This practice helps to create consistency and avoid the waste associated with rescheduling meetings or double-booking people and rooms.
What I see occurring is that meetings are re-scheduled, held out of sequence or simply cancelled. Many organizations operate in a continuous cycle of firefighting and don't see that adherence to a framework like Scrum would help them to minimize those fires.
Also, have the meetings in the right sequence, the way it was designed. I observed a retrospective meeting last week that was held in the middle of the sprint. Team members had already forgotten what happened in the previous sprint and were not able to incorporate improvements into the next. - The product owner is the sole source of work for the team. The point of this rule is to have one decision maker who prioritizes work for the team. No one else is allowed to tell the team what to do, and the team shouldn’t act on what anyone else says. The product owner owns the backlog and all work is reflected in the backlog.
There are a few ways that organizations break this rule. Some don't assign a product owner. Some have a product owner but don't let that product owner actually own and prioritize the backlog; instead, the ScrumMaster, project manager or functional manager does. Sometimes there is a product owner prioritizing work, but team members are still directed to work on other items. - There are no titles on the Scrum team besides developer. The reason for this rule is to encourage cross-functional behavior, avoid sub-teams and foster team ownership. Scrum seeks to avoid the inefficiencies of team leaders and specialty sub-teams within the team. Each team member is responsible to participate fully in the team. Scrum teams work like rugby teams with the single goal of moving the ball downfield.
What I sometimes see is that new Scrum teams operate with team leads, onshore/offshore coordinators, QA leaders or other specialties. They allow hierarchies that undermine the team’s self-organization and full engagement. In those environments, team members sit back and wait to be told what to do, rather than take initiative and ownership.
What You Can Do to Succeed
To succeed with Scrum, first we need to follow the framework and the rules. Scrum is simple, but it requires change from old ways of operating. The Scrum Guide is an excellent reference and it is only 17 pages long. Another resource I found useful is this video, Scrum by the book by Per Beining.
Second, look underneath why the rules are broken. Sometimes, it's not just about education—sometimes it is a resistance to change or lack of desire to adopt Scrum. Consider whether you have the right people in the right roles. Have you cast a vision for the change?
Third, consider hiring a good Scrum or agile coach. If you have the right people in the right roles, perhaps they just need some coaching to adopt new ways of working and thinking. Coaching in real time is needed to break old habits.
Anthony Mersino is an enterprise agile Coach with Vitality Chicago, Inc. He has over 30 years of experience delivering large-scale business programs and IT projects. He specializes in helping organizations effectively apply Lean and agile principles and the Scrum framework to gain true business agility. He teaches a wide range of agile and Scrum training courses as well as the cultural elements that are necessary for agile to succeed. Anthony is the author of numerous blog posts and articles and two books: Agile Project Management and Emotional Intelligence for Project Managers. He has an undergraduate degree from Michigan State University and an MBA from Loyola University of Maryland.
This article can be found at: https://www.projectmanagement.com/articles/352182/Succeed-with-Scrum--Dont-Break-These-7-Rules