Succeed with the Scrum Framework: Don’t Break These 7 Rules
I find that many of my clients today are trying to improve their use of the Scrum Framework. Many of them are missing out on the benefits of Scrum without even knowing it.
The Scrum Framework is a simple agile approach 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. As such, 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 the Scrum framework, as published by the creators, Jeff Sutherland and Ken Schwaber.
1. The Scrum 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.
Frequently what I find happening is that someone outside the team tells the team what to do. Most often 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. 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.
Nonetheless, 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, given that they are often coming from other roles and carrying baggage from those roles.
Rather than make the team self-organizing, they feel compelled to make decisions and tell the team what to do, making these “Scrum Masters” themselves indispensable.
3. The Scrum Master Doesn’t Have to Attend the Daily Scrum
This is an interesting rule that aligns with 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.
In fact, 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 that they aren’t needed at the meeting. New or unskillful Scrum Masters can actually do more harm than good by attending.
Chiefly, 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. In particular, within the Scrum team you should not hear team members talking about the “front end team” or the “QA team”. Rather, 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. As a result, 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 canceled. Many organizations operate in a continuous cycle of firefighting and don’t see that adherence to a framework like the Scrum Methodology would help them to minimize those fires. Ultimately, 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. Recently, I observed a retrospective meeting that was held in the middle of the sprint.
Consequently, 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 Scrum 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. For example, some don’t assign a Product Owner.
In contrast, 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. Occasionally, 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
Essentially, 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.
Therefore, 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 down the field.
However, 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. Consequently, there is no clear sense of team and no team ownership.
If You use the Scrum Framework, Do This Instead
Ultimately, to succeed with the Scrum Framework, first, we need to follow rules. Scrum is simple, but difficult because it requires a 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 necessary to break old habits. Trying to change without bringing in outside expertise often results in conflict. You can read more about the qualities that make a good Agile Coach here, and What Makes an Agile Coach Effective here.
Lastly, Self-Check on Your Use of the Scrum Framework
Take a moment to evaluate how you are using the Scrum Framework. Do you and your teams understand Scrum the way it is described in the Scrum Guide? Do you see Scrum rules being bent or broken on your teams?
This article was originally posted on ProjectManagement.com, Succeed with Scrum: Don’t Break These 7 Rules
