When a Scrum master starts a new job, two things are usually true: Everyone wants you to start your work right away, and nobody’s quite sure what work you should be doing. Management often expects you to rush into the process and start solving the problems that have been building up for some time. They want the Scrum master’s team to perform right away but have only vague expectations of what the Scrum master’s role should be.
The combination of urgency and ambiguity in these early days can lead a Scrum master to make any number of missteps. Let’s look at some of the more common mistakes made by Scrum masters in a new role, project team, or organization. I’ll explain how best to direct your time and energy to optimize your team’s performance as an effective servant-leader and change agent.
Common Scrum Master Mistakes
I’ve worked with Scrum for more than a decade, both as an Agile coach and Scrum master. Over that time, I’ve noticed several patterns and have identified common mistakes Scrum masters make. Here are four I see most often:
1. Overfocusing on Ceremonies
The most obvious part of your job as a Scrum master is facilitating ceremonies, so it might seem logical to begin by setting up, scheduling, running, and following up on these events. Ostensibly, from there, you could settle into other easily defined aspects of your role: optimizing the project management tool, creating boards, opening tasks, checking in after their completion, helping the team understand the right backlog techniques, and so on.
While this may seem like a safe way to start, focusing solely on ceremonies and daily tasks during your early days on the job runs the risk of misrepresenting the duties of a Scrum master as primarily administrative. Faced with limited guidance, team members will stay the same, only interacting with the Scrum master to move their tasks through workflow stages, add comments and notes for the product owner, or resolve impediments. Rather, from day one, think about how to act as a change agent, not a steward of the status quo. Events and ceremonies are important but not to the exclusion of your less visible responsibilities, like aligning team dynamics to company culture or setting long-term goals.
2. Assuming Management Knows the Real Problems
As a Scrum master, you may be hired, at least in part, to fix process problems on a particular team. But remember to cast a wider net when looking for solutions: Issues may arise from within the team but can also come from a lack of proper support, poor alignment between business and IT, low empowerment levels, wrongly shaped teams, or lack of mentorship and learning.
There are many tools that can help you pinpoint problem areas, including the Competing Values Framework, AgilityHealth Radar, and the Path to Agility. But you could start even more simply, by speaking with your team, other departments, and management. I’ve created this downloadable worksheet with a battery of questions you should ask to help identify where process difficulties have set in.
The information you gather will enable you to prepare an action plan for improvement, yielding more effective processes that will more readily address management’s concerns. Management may have several ideas about what the top-level issues are, but they typically care more about products and company growth than the day-to-day process of development. If the solutions you identify are broad and profound, creating concrete value, management will be happy with them.
3. Never Deviating From the Scrum Guide
It’s understandable—and advisable—to wait until you can follow the rules of Scrum before trying to break them. One popular model of breaking them “safely” draws on the Japanese martial art concept of ShuHaRi.
In Shu, teams follow the main rules and practices to get the best results. Once they can apply those consistently and predictably, they enter Ha, digging deeper into Agile values and principles. Knowing why the rules exist, they learn from others and integrate that learning into their practice. Finally, in Ri, they have a pool of knowledge they can use to adapt the rules to specific needs and contexts.
ShuHaRi is useful because it illustrates a clear path to becoming a mature Agile team. However, it’s a mistake to assume your team is at the beginning of its journey, at Shu. What if the team already knows the rules and has been applying them successfully for some time? What if the problem is not in adherence to the rules but in areas like knowledge-sharing, learning, observation, or reflection? For such teams, if you start by focusing on the rules, your efforts may be counterproductive, or your team might dismiss you as someone who just does things by the book. Have patience and make sure your opinions are backed by data, and never answer questions with “Because the Scrum Guide says so.”
4. Treating Every Team the Same
You may be assigned to a new team that was formed especially for you. Or you may join an existing team that’s worked together for months, or even years, and has its own way of doing things. I’ve worked with both kinds of teams and found that applying a one-size-fits-all approach doesn’t work.
In a new team, you’re likely to be welcomed with interest and friendliness. The setup phase will probably be deceptively easy: Your team will be enthusiastic (and idealistic), and you’ll hear a lot of slogans like “We want changes” and “We want improvements.” But as time goes by, resistance will likely mount: Team members will complain about the lack of time for development, too many events, not being T-shaped, confusion in roles, or no ability to split stories. You have to be prepared to answer a lot of questions as you guide your team through the values and principles. When explaining Scrum events, artifacts, and roles, don’t forget that empiricism and trust are vital for Scrum teams to flourish. Learn where your team members are, and be flexible enough to meet them there.
With an existing team, you may be stepping into an environment where bad habits aren’t immediately apparent. You’ll want to listen more and talk less, observing what each team member does and how they do it. You might start with a Team Radar evaluation to understand what they lack and where the pain points are.
Creating a Team Radar is simpler than it looks. Start by identifying eight areas that the team needs to discuss or evaluate. Draw eight axes emanating from a midpoint (as shown in the illustration), label each axis with one of the discussion areas, and have team members collectively evaluate their performance on a numbered scale for each axis. When all the numbers are plotted, connect the points among the axes, and brainstorm actionable solutions for the three lowest-scoring areas.
Once you’ve identified the problem areas by their scores, start to work on the ones that have the primary focus and more straightforward implementation to create quick wins within the team. The significant problems might be larger: Events are tedious, improvements are not implemented, growth is not visible, things are not changing, quality is low, or delivery is lagging. If the team expected that implementing Scrum would solve all their problems and it hasn’t, you’ll have to go deeper to understand the company culture, attitude, support level, and psychological safety.
New Scrum Master Best Practices
We’ve talked about what not to do. Now let’s talk about tasks a new Scrum master should start performing right away to help establish a focused, productive, and mutually agreeable working environment.
1. Hold a Team Introduction
Arrange a getting-to-know-each-other session and invite team members to bring snacks and drinks. The atmosphere should be casual, and you could do a structured go-around where everyone shares a small anecdote about themselves to break the ice.
2. Conduct a Kickoff
A well-run kickoff will establish what tools you have and where to start. As a team, you should use the kickoff to collaboratively answer key questions across multiple areas:
Product
- What are the product’s vision, goal, strategy, business model canvas, roadmap, objectives, value streams, stakeholders, partners, customers, business value, backlog, and ordering?
Technology and Tools
- What is the technology stack?
- What development, DevOps, project management, and communication tools do you have available?
People
- Is the team newly hired or brought in from other teams?
- To what extent is the team aware of the company culture?
- What are team members’ specialties, expertise, skills, and roles?
Process
- How will the workspace be organized? Are there boards?
- What does the workflow look like?
- Is the project/product management tool organized appropriately?
- Are there any company standards that need to be implemented?
- Where are the documents kept?
- Where are the events being held: on-site or remotely?
- What metrics are used?
3. Define the Terms of Work
Make a concrete plan for how the work will be done. Hold brainstorming sessions, using techniques such as global listening, emotional labeling, and visual facilitation, and take notes that the team can refer to in the future.
Set rules for the sessions: be transparent, listen, and focus; don’t blame, make noise, or interrupt. Establish timeboxes and stick to them for each session. Some brainstorming topics include:
What is Agile?
- Does your team have experience with Agile, or are they new to it?
- What are Agile values versus Scrum values?
Why are we here?
- What is our goal?
- What expectations do we have to meet?
Who are we as a team?
- What are the team’s roles, responsibilities, skills, and strengths?
- What does a great team mean to us?
How do we plan to work together?
What are we going to deliver?
- What is our product awareness?
- How will we handle the backlog and goal?
- How do we make sure we provide value for the customer?
- Are there any other initiatives we want to take on?
How are we going to deliver our product?
- What is our workspace?
- What are our workflow processes, frameworks, practices, events, and tools?
- What is our Definition of Done?
How are we going to evaluate our performance?
- What metrics matter to us?
- How can we experiment and improve?
Conversations are a powerful tool for building a positive and effective workplace. Your job is to act as a facilitator and a servant-leader—to help your team come together and define its own way of working.
4. Craft a Working Agreement
Using the questions you answered in the kickoff and the notes you took in your brainstorming session, work with your team to create an effective working agreement. A working agreement can take many forms, but I find it’s helpful to begin with a mission statement—a single, powerful declaration that unequivocally states what we do, how we do it, and why.
From there, construct a set of guidelines for workplace behavior and processes that everyone can agree on. It may be as simple as organizing the questions you’ve already answered or gathering new subjects that you’ll need to consider as they arise in the course of discussion. A good working agreement will help your team understand what expectations are in place—not only the expectations you have for them, but also the ones they have for you, for each other, and for the work they produce. Having a tangible working agreement will help promote team efficiency and camaraderie by reducing guesswork and misunderstandings.
When you settle into your tasks, make sure key roles and concepts are clearly defined for your team. The working agreement, the Definition of Done, the product vision and goal, and the backlog state all need to be understood by everyone involved. Additionally, the responsibilities of the Scrum master and product owner need to be clearly delineated.
The Beginning of Lasting Growth
The clear perspective that comes with a new beginning can be an advantage. You can assess the system without attachment to embedded processes and freely avail yourself of the opportunity to aid your team’s growth. It’s a big responsibility and a tremendous gift. How you use that gift is up to you. If you take on a trendy role without regard for what needs to be done beyond the administrative, people will feel it, and you’ll fail. If your only goal is to implement the Scrum Guide, you won’t affect change, you’ll only make people hate Scrum. However, if you live and breathe Agile, if you are a change driver and growth seeker by nature, the example you set will be contagious.
What common Scrum master mistakes would you add to this list? Please share them in the comments section.