Dialogue with a Scrum Master

I’ve had the privilege to work with a several teams and Scrum Masters over the last few years. On many occasions I had some interesting discussions. I’ve combined some of these subjects into one virtual conversation with an imaginary Scrum Master.

Scrum Master:  My Team believes I don’t give them enough room for error.  I try to facilitate them but I feel responsible for the result. So if they don’t do what I think is best, I believe I’m entitled to tell them what to do.  After all, I’m the Scrum Master and so I determine the process.  Right?
Me: It depends on the context. Most companies start with Scrum to move away from the “good” old-fashioned way of working on a product. They have to try something else, because the current way of working is NOT working. Even when we think we are doing something different, we tend to hold on to the things we were used to do. Which isn’t necessarily a bad thing, but if you really want your team to change, you’ll have to change too. Being the traditional Project Manager or Technical lead in a Scrum team is different. A Scrum Master is supposed to facilitate change and keep the learning curve as high as possible. Controlling the team or process is too old school. And you already have seen it fail before. Right? Yes, you can take the lead, but so can other team members. And please let them feel safe to take a step towards change. Make it safe for them to fail. Many great ideas and improvements come from mistakes. That’s how we learn.
Scrum Master: Yeah I understand, but the symptoms of the team are bad estimates, not having the commitment to deliver high quality software. If I don’t take the lead in that, no one will!
Me: I don’t believe that anyone wants to deliver low quality software. Everyone has a different opinion about quality. Some think it’s in using code patterns or standards, others think it’s about having all your Test Automation tools “green”. I’m not so sure. I think quality of a product reflects from the people who are responsible for building it. So if someone really feels bad about the product, process or organisation, it reflects on the product.
One day I’ve asked the team to write down their imaginary Nightmare Headline of the companies’ newsletter to stimulate creativity around our next exploratory test session. One of them wrote down “Nobody is using our software”. And everyone else was nodding and agreeing with the statement. Suddenly I understood the commitment of the team. They didn’t believe in their product! I understand you feel responsible for delivering high quality software, but if no one feels proud or passionate about building the right product, you have a bigger problem than not delivering your product right on time.
Scrum Master: Wow! That sounds scary. And worst thing is… It’s kind off recognizable with our team. I should work on that! I’m still responsible for the standup meeting right?
Me: Well… You are not the only one responsible for the standup. I’ve actually seen really good standups without a Scrum Master being present. Most teams think that a standup is a daily status meeting. Especially when a Scrum Master is present. The team reports to their master. The same thing you were doing before? Remember? Try to stimulate and inspire the team to really collaborate on tasks. Just look away when someone is reporting to you. Look at your Scrumboard and let the team talk to each other about the burndown and the steps they need to take to reach the sprint goal.
Oh… and it’s really important to keep these meetings as short as possible. Sometimes you don’t have to use the Past, Future, and Impediments format. No one likes to be in status meetings. So keep the focus on the next steps (future) instead of the things that have been done yesterday. Let the team members feel engaged about the Scrum process. Like they own it. Not you.
Scrum Master: So let me get this straight. The team leads the standup. And the standup format is just a guideline. I can live with that. I’m worried that no one will take responsibility of the impediments and other issues. We still need some sort of structure in the process right?
Me: Yes! We should try to use these guidelines, but don’t let the perfect process drive you and your team. Achieving some goal never had to do with following some process. It’s still the effort and commitment of the team that made a difference. When no one takes responsibility of the impediments and issues, guide the team with ideas. Give them inspiration to solve the impediments themselves. When some issue or impediment is outside the scope of the team they will ask you for help!
For example: The QA and IT Operations departments are doing too much manual work. So the team gets feedback and bug reports outside the sprints which delays every release. And yet, you are still pushing your team to estimate better and chasing their commitments. Maybe you should change your scope towards engagement that extends beyond the team?
Scrum Master: I see… I really should try to give them a chance. I just don’t trust them you know. And I agree that I could help the team with issues outside the scope of the team. Maybe I could ask our management to get some QA and Ops guys in our team. That would help speed up the feedback loops.
Me: Yes! You should! The team will take you where you want, but in a way the team wants, the way the team knows!
Scrum Master: What about all these Agile Software Tools, spreadsheets, charts and metrics?
Me: You feel responsible for our performance. And you try to come up with a process and metrics. I understand that you want to make the team look good, but be careful overdoing things. Think about the things you were doing before adopting Scrum. If you want to change something, you’ll have to let go of your old habits. I’ve worked with teams who only cared about the amount of users using their system after a release. And they kept track of these numbers and reacted / changed their plans accordingly. Be open for new things. And don’t try to take over control of the team. The whole team should be held accountable and feel responsible for the work. If they come up with a cool new way of keeping metrics that matter. Let them! And you’ll see that they feel empowered to do great things and even become more engaged with the business.
Scrum Master: Yeah… Engagement, commitment and empowerment. I’ve tried to work on that during our retrospectives, but they suck! No one likes to attend them.
Me: I noticed. It’s OK to be in charge of the retrospectives, but leave some room for creativity in solving impediments or any other kind of issues by the team. You don’t have to come up with solutions. Just inspire the team with great ideas and give them a feeling that they had a choice in doing it your way, or maybe their way. One other thing I noticed is that the team doesn’t take time to evaluate their progress regarding the improvements of last retrospectives. Whenever you decide to improve something, make it measurable and evaluate the outcome, so the team can see their effort towards improvements.
Before I forget! Make sure that at least one person in the team is held accountable for chasing the retrospective actions (like stabilizing the test automation). That doesn’t necessarily mean that it’s you. In order to create group responsibility towards improvement, it’s also important to let someone else take the responsibility for solving problems.
Scrum Master: So this whole Scrum Master role is not about authority or managing people?
Me: Again it depends on the context. I’ve actually worked with a Scrum Master who was directive, but he also inspired us to do better. We had a tight schedule and deadline. He let us see / evaluate the strengths and weaknesses of several options. From his superior experience, he always made the right choice. And we trusted him.
It all depends on who you want to be. If you want to improve your team regarding engagement with the company, you should help them build greater awareness and responsibility, so it can make its own choices.
In the end you want your team to feel safe and comfortable making mistakes. Failure should not be given. We should embrace learning. For me it’s important to be happy at my work and doing my best for making our environment a great place to work, since we spend most of our time / life at work! I want to wake up the next morning knowing we did a good job and wanting to go to work again.
So please. Dear Scrum Master… You can be so much greater than what a Scrum Master is.

Don’t look for the I in team, because it can be found in the ‘A-hole’ 😉