On Being a Developer and a Scrum Master

One thing that I continuously harp on about is agile software development, or as I’ve recently learned from Dave Thomas, developing software with agility. I work in a large enterprise level company, and we have our share of hurdles, and obstacles to overcome, but I recently faced an interesting situation.

Our department was in need of a scrum master, and we needed one badly. The situation was fairly dire, with our technical leads and project managers serving as scrum masters. They were overworked, over burdened, and simply didn’t have enough time to be effective scrum masters. I had expressed my interest in changing our scrum and agile processes, and was asked if I wanted to be scrum master.

Now, keep in mind, our processes were very immature and ad-hoc. We didn’t have a lot of structure, but we had the basic scrum foundation. Daily scrums, planning meetings, retrospectives and the usual stuff. We were doing all the things of “agile development” without being truly agile, but just trying to check off a list of tasks we could do and try to make it work. It was a mess, and I knew we could do better, but as anyone working in large company knows, change comes slowly and there’s a lot of other parties involved which means that it’s always feels like an uphill battle.

So when given the chance to be a scrum master, I took it eagerly. I knew I was going to face some challenges and problems, and I had read that it was never a good idea to have the dual role and do two things, but I thought I could manage. “What’s the big deal, anyways?”, I remember thinking. “Schedule a few extra meetings in Outlook, facilitate them, and most importantly remove blockers from our team”. Our team was relatively small, with only two developers, one QA, and a part-time tech lead, so it wasn’t that big of a deal.

How did it go? It went well. Our team was successful for all the sprints I was a scrum master for, and we delivered three sprints worth of work (nine weeks) on time, and everything. But I would strongly discourage anyone from trying to do both roles.

The problems I faced were pretty bad — I was being called into a lot more meetings from project managers, and tech leads, and people I never normally interacted with. Product owners and managers would request me to be to part of meetings for their status updates, and what not, and this wasn’t too bad, but definitely distracting. Distracting. That was the common theme by juggling two roles.

When you are focusing on being a developer, you have one goal. To develop working software, and all the good stuff related to that. Being a scrum master requires you to adapt like crazy to whatever situation that will get thrown at you (and it will), and respond with agility, and remove blockers. Mentally being able to juggle these things was very difficult.

Remaining neutral was also very difficult at times, but doable with the right mindset. By nature, I am a very outspoken person who isn’t afraid to defend my thoughts and ideas. When dealing with QA, who is naturally trying to find bugs, and hammer your application, it was difficult to remain neutral, and I found myself wondering if I should be neutral, or if I should say what’s on my mind. This took some time to balance, but in the end, it definitely helped me mature more as a person because I truly forced myself to see other people’s perspectives.

The benefits were good too — being the primary developer on the team, I had intimate knowledge with the stories and the issues, and this allowed me to communicate updates to the external world of our scrum team very easily and effectively.

It also allowed our team to implement more agile development changes, and be very flexible. Our previous scrum master was not as technical as a developer or QA, so by removing this element, we were able to make changes that improved our agility. It required one less person to propose the changes to, and to agree — things just seemed to move more fluidly.

After our 3 month experiment ended, and we found a scrum master replacement, and I went back to being a simple developer, and it was a huge relief on my shoulders. I had learned a lot, and I began questioning why I even served as scrum master, and what the benefit of it was. In the end, I’m glad that I took the chance to work as a scrum master, and I would only suggest it as a brief experiment or a temporary thing to keep a team going. It’s definitely not sustainable, because with the split focus, you won’t be able to juggle the responsibilities and do both jobs well.

What I learned is that I became a scrum master for the wrong reason — I had a lot of suggestions and ideas on how we can run scrum, and what we can do to improve our agility. And for whatever reason, I thought that being a scrum master would allow me to do these changes more easily, and give me the authority to do so. I was right and wrong — I did have more authority, and I was able to make those changes I wanted a little bit more easily, but I realized I didn’t need to be a scrum master to do it. In the end, just because you have the authority to make changes or have a fancy title doesn’t mean anything. What really matters is leadership. I could have implemented all those changes by being more proactive as a developer, and just focusing on what ultimately matters — help the team work with agility, don’t be afraid to step out of my self-imposed bounds as a developer, and do whatever I can and is necessary to produce great, working software.