I had a lot of questions as a beginner Scrum Master. I’ve read the Scrum Guide over a hundred times. But I still didn’t know how to interact with the team, what should I expect from them, and what they expect from me.
I’ve put together a list of things that I would’ve liked for someone to tell me. I didn’t learn the easy way to do it or have someone to teach me how to be a good Scrum Master. I learned it by putting myself in difficult and embarrassing situations sometimes. But, what can I say, this is a way to learn too after all.
1. How can you remove impediments your team is facing
Self-organizing developers can manage impediments
Developers will often have impediments standing their way. They can remove them by themselves, or sometimes, they have to turn to other people for help. But speaking of impediments they can remove, they comprise mostly technical obstacles. However, we should not exclude the obstacles that appear in team members’ communication and collaboration.
Technical impediments I’ve found to be common among Scrum Teams:
- environment configuration
- software installation
- understanding code that someone else has built
- technical dept
Being a self-organizing team, they should help each other or ask for help from other technical people in the organization. The Scrum Master can rarely help the team with any of these impediments. The most he or she can do is to point the team at the right people.
The Scrum Master clears the path for the team
I pay a lot of attention to what my team is saying during each Scrum Event. Sometimes it simply doesn’t cross their minds to ask for help when they have an impediment and they try to find solutions by themselves. While this is good, because they show responsibility and involvement, sometimes they’d solve it faster if they would just involve the Scrum Master.
Impediments where the Scrum Master can help:
- a sick team member can affect delivery
- lack of management support
- someone not understanding Scrum
- distraction to people on teams
- insufficient skill sets
- identify who can help another team member from inside and outside the team
I always ask my team if they need help with anything. Even if I cannot help the developers with tips for how to write the code, or I won’t write User stories, there is always something that you can do for the team.
Impediments that need to be escalated
There are some impediments that the Scrum Master can not remove directly. And he has to escalate these to various other people. He is still helping the team by raising concerns and risks, but he doesn’t have the power to remove them.
Some of these impediments can be
- Team members want to leave the team
- Team members that want to change the project
- Team members not being satisfied with the technology they work with
- Team members wanting to leave the company
2. The Scrum Master is not the team’s secretary
Am I a Scrum secretary
A Scrum secretary can take many forms. Are you writing statuses after every Scrum Event? Are you writing a plan for each Sprint planning, taking notes during refinements, and keeping all calendars up to date? These are signs you are becoming a Scrum secretary.
It’s fine to help your team from time to time, but these are things they can do too as a self-organizing team. Be careful what kind of position you take when someone expects you to do these things. Your job is to spread the Scrum knowledge within the team and organization and make sure the Scrum values are being comprehended.
What is servant leadership after all
Servant leadership is still leadership. Accountability and authority are part of the servant-leader role. Servant leaders have the same scope as autocratic leaders, which is helping their teams accomplish their objectives.
The fundamental difference is how they perform the role. Servant leaders are supporting, not demanding, but they are still leaders. Many fall into this trap, thinking that as servant leaders, you have to do everything your team asks of you.
As a servant leader, the Scrum Master is responsible for
- Help the team self-organize
- Teaching, coaching, and mentoring both the team and organization in adopting the Scrum values
- Shield the team from external threats
- Help the team identify and remove impediments
- Creating transparency
3. The Scrum Master is a teacher
My team doesn’t know Scrum
As a Scrum Master, you’ll have the chance to work with experienced teams and teams that know nothing about Scrum. You should know that you need a slightly unique approach to each one of them. But before you apply any techniques, understand what is the level of knowledge each one of them has.
When I join a team, or a new team member joins my team, one of the first questions I ask is if they’re familiar with the Scrum framework. You’re looking in this phase to know if they’ve worked before in Scrum teams, had taken part in any Scrum events or sized User stories. You’ll figure out early if they are just following Scrum rules and not the values.
If your team is new to Scrum, begin by discussing the Scrum values, roles, events, and artifacts. But don’t expect them to get it all right since day one of the Sprint. Have patience and remind them when each event takes place, and what’s its real purpose.
For example, in the Daily Scrum, you can have the sprint goal displayed for everyone to see and guide the team to discuss it. Are they closer to meeting the goal than yesterday, what should they do today to get closer to the goal?
We follow Scrum rules, but what about Scrum values
This is a situation many Scrum teams find themselves in. Having Daily Scrum meetings without having in mind the Sprint Goal and planning the day accordingly won’t bring you any benefits. Having Sprint Planning sessions without having a Sprint Goal gives no perspective to the team about what are they working for. They are only finishing some tasks.
- Commitment: People commit to achieving the goals of the Scrum team
- Courage: Scrum teams dare to work on tough problems
- Focus: Everyone is focusing on the Sprint Goal and the goals of the Scrum Team
- Openness: Scrum teams and the stakeholders are open about the work and challenges
- Respect: Scrum team members respect each other’s decisions and opinions
Teach the Product Owner Scrum Techniques
Product Owners can struggle sometimes with Scrum too. They might be new to this role, coming from a Business Analyst or Project Manager position. As I do with the developers, one of the first questions I ask the Product Owner is if he is new to Scrum.
If he’s not, I would ask them how did they apply Scrum in the past, how are they writing user stories, is it collaborative work with the developers or not? How does he organize the Product Backlog, and how early he involves the developers in discussions about the feature they will implement?
See, it’s crucial to understand where the team is coming from with Scrum so that you know what areas must be improved.
4. Technical skills are not a must for Scrum Masters
When a Scrum Master with technical skills can be helpful
It is not a mandatory aspect for a Scrum Master to have technical skills, and by technical skills, I am referring to writing code. However, a Scrum Master should have some technical knowledge and understand the technical processes used by the developers. For example, knowing how the code review process occurs. Or, what it means to commit the code to the Master branch.
By understanding how they work, it’s easier for you to understand how and when you can help. Remember that one of the Scrum Master’s responsibilities is helping the team to remove impediments. So if the Scrum Master has technical skills, he can help the team with technical decisions when the team feels stuck.
The technical Scrum Master can be an obstacle
When the Scrum Master has technical skills, they can be more of a distraction and can feel much more interested in coding than in coaching the team facilitating, training, or removing impediments.
If this happens, then the value a Scrum Master should bring into a team isn’t there anymore.
5. The Scrum Boss
Scrum Masters do not lead with authority, they lead by example. People respond to authority with compliance, they are afraid that something bad will happen if they don’t do what they’re asked to do.
So I’ve been asking myself in my early days as a Scrum Master, why don’t we receive this authority? And the answer is that this is a transformational role, a role that’s based on positive influence (not in the sense of authority).
We cannot decide how the developers will do the work or how the Product Owner will conduct their meetings with the stakeholders. But we can help them improve their processes, respect and value each other, be committed to the work they do and be open. We can suggest techniques and explain what benefits they can bring.
6. Scrum Master – a backstage role
If you like to be the one in the spotlight, the Scrum Master role might not be a role that fits you well. As leaders, Scrum Masters let the team take credit for their success, no matter how much work they’ve put into their success. You shouldn’t chase attention and praise, your work should be about the team.
You shouldn’t solve the team’s problems, coach them to do it and let them experiment. Don’t increase your visibility and show your contribution for attention.
7. Make sure no Scrum Event is being skipped
Scrum Events are an important piece in the framework. Skipping them, or not doing them regularly, will limit the benefits of Scrum.
Each event is an opportunity for the Scrum team to inspect and adapt. I skip none of them even if there’s a big release coming, and the team has a lot on its plate. Also, I do not skip events because one of the team members is missing.
We just started a new project and our Product Owner and the Software Architect often had discussions with the client. It happened before one of the Sprint Retrospectives for them to have a meeting with him. One that got extended. So they couldn’t attend the retrospective and asked me if we could skip it. What I did, in that case, was to reschedule it for the next day.
It can happen sometimes to have something urgent to solve but just reschedule the event for another time, never skip one. Otherwise, the team will think there’s no problem with skipping them. And they’ll ask you to do it every time something they consider more important comes up.
8. Learn about estimation techniques
There are many ways to size User Stories, the most used one I would say it’s Poker Planning. This is what I usually use for User Stories and T-shirt sizes for Epics.
But there are many other techniques that you can use, such as
- The Bucket System
- Big/Uncertain/Small
- Dot Voting
- Affinity Mapping
- Divide until Maximum Size or Less
You can experiment with them in the beginning, but once you’ve decided on one, try to stick to it. Otherwise, it’s difficult to use previous data when you switch to a different sizing technique.
9. Expect your ideas to be contradicted
Some people you’ll work with will be very open to your suggestion and trust you. But there will be others who will question everything you say. They’ll reject any suggestion you have and say that they are the ones who’ll do the work, and they know how to do it.
My suggestion to you is to have patience and don’t give up. Of course, that won’t be enough, but it’s the first step. Your team has to trust you to follow your lead, as you would too.
So when you see something going wrong and you come with a suggestion that you know will work, ask your team to just try that out once or twice. And if it doesn’t work, gather them together, explain the problem and let them find the solution.
10. “One more question”
As Scrum Masters, we have to get used to asking a lot of questions. Even if they seem dumb, it doesn’t matter. We have to make sure that we received the correct message before taking action or forwarding the message to other people.
When I’m having a conversation with the Product Owner, stakeholders, or Developers, I’m making sure that I let them know that I’ll be asking a lot of questions. I tell them I need to understand very well every aspect of the conversation. And at the end of the discussion, I confirm with them that what I understood is correct.