It took me over a year after I became a scrum master to learn to stop making technical decisions. (I still do it sometimes.) This is a common pitfall for former individual contributors who are placed in a leadership position: they focus too much on what they used to do as individual contributors, and not enough on the big picture. It’s natural — that’s what you spent years doing and perfecting, and what you feel most comfortable with — but that doesn’t mean it’s right. Especially in a framework like scrum, where the team members’ roles are specifically designed to keep them from overstepping their bounds with one another.
One of the teams I worked with had a project that involved a lot of Python. Despite my having only a few months of experience in that programming language, it was still more than the rest of the team had and I was excited at being able to contribute my knowledge. I pushed for coding standards, participated in code reviews, discussed how the documentation should look, debated the use of third-party modules, encouraged the use of Git over SVN, and tried to understand in detail what the developers were working on. I felt proud of myself for providing some of the technical leadership on the project.
Then one day, an issue I had raised in a code review was rejected. Had I been more familiar with the code, I wouldn’t have incorrectly pointed out what was really not an issue at all. Then it happened again. I found myself flip-flopping on dependency management because I didn’t fully understand the ecosystem the library would be used in. I started asking more “how” and “why” questions. There began to be some friction between the senior developer and me. My technical advice soon began reaching its limit, even though there was plenty of work left to do on the project. I started to get self-conscious and wondered if I was making a fool out of myself. (The team was nice enough not to say so directly, but I’m sure I did.)
My technical participation did have some benefits, but I insisted on continuing to do it even when it should have been clear that there were diminishing returns. I was not adequately fulfilling my role as a scrum master because, even though I was helping the team to create a high-value product, I was telling them how they should do it instead of letting them self-organize and decide on their own. And even worse, I did not have the necessary knowledge to continue providing useful guidance more than a few months into the project. A better way to help the team would have been to organize an overview of some practices I thought would be valuable and then let them decide if/how they wanted to adopt them, rather than practically dictating how they should do things. This would have allowed them to be more self-organizing, and possibly increased their sense of ownership and accountability for their work. I’m sure you can think of other ways that I could have handled those interactions better.
A lot of scrum masters come from a development background. They bring knowledge and experience that can help their teams produce high-value software. But as scrum masters, we need to remember that our role is not one of technical leadership, but of servant-leadership. Our mindset must shift from helping the team to helping them help themselves. Keeping this in mind and acting accordingly with our teams will help them do better work and foster a better working relationship with them, as we “respect each other to be capable, independent people.”