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 for Scrum published by the creators, Jeff Sutherland and Ken Schwaber.
1. 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 Scrum Master; 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 commitment, motivation and productivity.
2. The Scrum Master is a Servant Leader Who Teaches the Team Scrum How to Self-organize
The role of the Scrum Master is widely misunderstood. As the name implies, the Scrum Master is supposed to master scrum. They are not a project manager, task manager or driver for the team. Rather, they are an enabler, a servant that teaches everyone Scrum and coaches the team to self-organize. Done well, the Scrum Master should be working their way out of a job as the team matures.
I frequently see Scrum Masters who don't know Scrum. Seriously. The "masters" of Scrum don't understand Scrum themselves and find themselves hard pressed to teach or coach others to use Scrum. They also don’t understand how to be a servant leader or 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 self-organizing, these Scrum Masters make themselves indispensable.
3. The Scrum Master 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 status meeting. This is not how things work in Scrum.
The Daily Scrum is not a status meeting, it is a meeting for the team members to coordinate their work and make sure they are on track to achieve their sprint goal. The reason it is OK for the Scrum Master to miss the meeting is because they aren’t needed at the meeting. New or unskillful Scrum Masters can actually do more harm than good by attending.
The Scrum Master 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. They can certainly attend but the team should have the meeting whether the Scrum Master is there or not.
4. Scrum Teams Should Work Cross-Functionally without Handoffs
Traditional teams work as a relay race with specialist team members handing off work in one phase to different specialists in the next phase. The handoffs between the silos are usually the biggest area of risk and information loss.
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.
5. 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. It goes back to a lack of understanding of the Scrum framework.
And please, have the meetings in the right sequence, the way it was designed. I recently observed a retrospective meeting 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.
6. 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 - the Scrum Master, 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.
7. 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 a single goal of moving the ball downfield.
What I see in practice is that Scrum teams operate with team leads, onshore/offshore coordinators, QA leaders, or other specialties. They allow handoffs and 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. There is no clear sense of team.
Do This Instead
To succeed with Scrum, first we need to follow the framework and the rules. Scrum is simple, but difficult because it requires change from old ways of operating. Strive for a solid understanding of Scrum. Bring in Agile and Scrum training for your teams, certified Scrum Master training for your Scrum Masters, and Agile Leader training for managers and executives. Read and fully digest the Scrum Guide; it 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 and the commitment to use Scrum?
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. Trying to change without bringing in outside expertise often results in conflict.
What do you think?
This article was originally posted in ProjectManagement.com, Succeed with Scrum: Don't Break These 7 Rules