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.
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.
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.
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?
Before I forget! Make sure that at least one person in the team is held accountable for chasing the retrospective actions (like stabilising 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.
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’ 😉
