Going full Scrum Master

31 May 2017

Tales from DTSMA

In a previous post, I described my life as it was then; part-time Developer, part-time Scrum Master. Things change, and I’ve left the development side behind, taking on the role of Scrum Master full-time.

I’m very fortunate to work with two other Scrum Masters who have gone through a similar career change. So we decided to get together to talk about what we thought of the transition - from full-time Developer to full-time Scrum Master. Welcome to “Developers-Turned-Scrum-Masters-Anonymous”…

What to do?

Upon becoming a full-time Scrum Master, the first thought we each had was the same: “I’m definitely keeping busy – but am I working on the right thing?”

This manifested as two distinct problems to solve.

On the one hand, there was the challenge of understanding how your work now translated into value for the team, and the company. The immediate sense of achievement that came from committing code, greening tests, and delivering obvious, tangible value was lost. Where were we to get our dopamine hits from now? How would we know if the actions we took were valuable? Is any developer going to take us seriously again?!

On the other hand, the role of Scrum Master comes with greater autonomy – but this can be difficult to handle initially, if you lack a clear sense of your purpose. So how do you decide on the right thing to work on? Where does your remit begin and end? What’s within your power to influence?

Coming from a developer background, all three of us had the same intuition when it came to adding value: jump in and help solve the technical problems. This was sometimes good, sometimes bad. Developers naturally lean towards solving their own technical problems, and don’t always want to hear solutions from Scrum Masters! That said, it doesn’t hurt to be able to contribute to technical conversations and communicate with technical folks using a common language. In my case, I went from Developer to Scrum Master in the same company, so I could bring my technical experience and standing with me when I transitioned, which was a definite bonus.

However, once we had spent some time with our teams, we found ways to work within the team’s systems without being directly involved in the products being created. We found our strengths lay more with understanding the team systems, reinforcing the business value of the work being done, and raising our heads up to look outside the teams at wider issues or common problems. While it’s fair to say we were doing some of this work already as part-time Scrum Masters, we found a different set of challenges that we now had the scope, remit and appetite to attack! Our focus took in more longer-term problems, or the sort of issues that live in-between teams.

A large part of our daily work is now in connecting people and information, to reduce FUD and friction. Knowledge is our currency, and communication is our trade. Realising this, and understanding that “simply” improving communications and sharing knowledge underpinned so many of our endeavours, was a big turning point.

You’ve changed…

We all had to make some changes to the way we approached our days. Self-organisation became key to keeping on top of our work. Personal Kanban boards, bullet journals, goal setting, Scrum Buddies – all have been incorporated and heavily leaned on!

And, with the acceptance that our value lay in longer-term strategies, aggressively sharing information and, of course, clearing the blockages that our teams regularly hit, came the acceptance of where we were to find the dopamine – the sense of accomplishment that will continue to drive us forward. It’s rare that your work will be directly and obviously responsible for success within the team; after all, your focus is to ensure success for the team, not just yourself. So you need to recognise and remember the moments that you guided, shielded, nudged, or improved, and have the presence of mind to say to yourself: that was me. I made this happen.

“Egoless arrogance” was an excellent term that came up in our conversation. It refers to the approach you need to take as a Scrum Master if you’re going to take any satisfaction away from your daily work. Take credit where it’s offered. Don’t be humble. (But don’t be a dick either. Egoless arrogance.)

Some tips

Don’t make yourself the Single Point Of Failure in the team. It’s tempting to carve yourself out a niche and become an indispensable part of the team, to give yourself that feeling of fulfilment and satisfaction. But you’re actually doing the opposite of your job – you should be trying to make yourself as dispensable as possible! Or at least: start by trying to make things better when you’re there. And if things stay better when you’re not there – fantastic!

You’ll probably find you develop a thicker skin as you face more obstacles than you might be used to; after all, when you were a developer, you may have had a Scrum Master who was shielding you from a lot of external challenges. But now – well, that’s you, isn’t it?

Coincidentally, each of us started journaling when we started our new roles (by coincidence). Although the practice didn’t last, we found this to be a great way to reflect on our progress in the beginning, and help us to come to terms with the changes to our working rhythm.

So, that’s that. Hope it is of use to you, whether you’re a budding Scrum Master or a veteran of the trade. Thanks to my fellow Developer-Turned-Scrum-Masters for the conversation! They are Martyn Frank (@MartynFrank) and Paula Stepinska (@disdatdot)