Now that you became a Scrum master

When I started to work with scrum, the scrum master was irritating, “create a story for that, or an epic for that other thing”, “remember to change the status of the ticket”, “can you estimate this ticket based on a fictional meassure called points?”, and my favourite, “let’s use poker cards to show the team what’s the number of that fictional scale I have decided to estimate work”. At some point I hated him… well, we all did, we were happy just throwing the changes to production with little testing effort.

But month after month, the introduced changes began to pay off and the performance of the team increased quite a lot, also the number of bugs found after our deliveries were lower.

I was quite impressed with the scrum framework and the scrum master position, and how understanding a team and the problems they have, the performance can be highly improved. My interest in the subject grew even more after reading some books and articles, so I decided to take that position, and eventually I did it!.

So now that you became a scrum master, what’s next? First step, don’t be annoying, seriously. I think I have a good position to understand the most usual scrum master pitfalls, because I have been in both sides and annoy the dev team is never a good idea. Many scrum masters never have been into development, got their scrum certificate and landed in a team, with the scrum guide under their armpit, trying to shovel the scrum principles into the team’s mouth.

I can understand this kind of scrum master, you have been hired to accomplish a mission, to coach the team, to predicate the scrum principles, you are an evangelist of this new religion… but think on that, do you like the mormons knocking at your door asking you to talk about Jesus? if you are not mormon I assume the answer is “no”, so stop behaving like that.

The key thing is to wait and observe, be invisible the first 2–3 weeks of your work, where of course, you won’t be with the arms crossed just looking what the team does. You will start to analyse the teams, and the characters, having separated talks or interviews with them, asking about their expectations on scrum, meassuring if they think it’s bullshit, or if they are open to adopt it, researching on the previous scrum experiences, if they do exist, and starting to design your action plan for the team. Many people cannot wait this long, they feel like they have to give input, right here and right now, to justify the salary, but believe me, you cannot arrive to a team and make drastic changes, so be patient!

Second step… don’t be annoying (yes, once more), don’t interrupt the meetings, everytime you hear a new concept or when you try to understand what the team is working on. As a scrum master you are obligated to understand what your team does, at least in a high level. But never interrupt anybody just asking about concepts, just use one on one interactions, like the interviews mentioned above, or through the product owner, who will have also all the information you need. Of course, this is not about not asking or not raising your hand in a given moment, but please, don’t try to get the knowledge you need asking everything in meetings.

Third step… again… make your changes gradually. Imagine you have identified there’s a lack of refinements, retrospectives are irrelevant, and the board is total mess where nobody can track the tickets. Never try to do all the changes suddenly. Introduce one, see how it works, if it doesn’t work, try something else or discard it if the team give good reasons to do so, go for the second one… always in order, gradually.

Final step, this is very, very important, it doesn’t matter what your scrum guide says, if it doesn’t work for the team, it doesn’t work for you, scrum is not a goal, it’s a mean, and if only a little part of it works fine for the team, then no need to enforce more. It’s your task to analyse the team and evaluate the outcome of the changes you make.

Be seamless, don’t push, be kind and helpful, schedule the needed meetings and rooms on time, relieve the people from tasks as communications, presentations, and delivery management. And never ever, under no circumstances put in practice the famous retrospective games, nobody likes them, invest the time getting some budget to treat the team to some beers if you want to make team building.