Technical background: the extra mile on scrum mastery

Among other things, scrum is very “trendy” lately. Virtually any company that I know of has either adopted it or attempted to do so or at least considered it. The software industry needs change rapidly, evolving the scrum master in one of the most sought after roles. However, the inability of the offer to meet the demand and the absence of required technical skills to become a scrum master has made the role appealing to a number of people outside the industry, giving birth to an ongoing debate. Should the scrum master have a technical background?

The scrum guide does not prescribe technical skills as a prerequisite for a scrum master. However, desired qualifications in vacancies range from concrete experience as a software developer to no technical requirements specified at all.

Before we endeavor to address the topic, let’s take a step back and think a little bit of Agile. Why do all these people and companies favor Agile over waterfall? After all, waterfall was used for so many successful projects. This can be a surprisingly hard to answer question for a lot of people.

In my opinion, the key benefit is the establishment of a short feedback loop.

Daily stand-ups, open space offices and loads of sticky notes only serve to alter the process, being merely means to an end. The short feedback loop is an end in itself.

Agile suggests that we leave behind the old days when the requirements were specified all upfront and the developers worked isolated for a few months only to deliver software needing change. A very short loop is established, allowing for a small chunk of software to be produced, inspected by the stakeholders, adapt to their feedback and repeat the cycle. Indefinitely. The illusion of the end state is eliminated.

This radical process modification requires profound changes in the heart of our work. Potentially, the most common pitfall is to change the process, but continue writing code in exactly the same way. A lot of companies, perhaps unwittingly, opt for only changing the process, starting walking down a road that is doomed to lead to failure. The scrum master enters here, forced to distance herself from solely the process and look at the bigger picture.

Guarding the process is essential, but it means nothing without guarding the practices that lead to better software quality.

Of course, quality cannot be measured, but there are disciplines that lead to it. Pair programming, test driven development (TDD), refactoring and code reviews among others, bring a set of very important advantages like collective code ownership, improved code design, living documentation (tests) and automated regression test suites (more on this on Agile code).

Returning to the original question, in my opinion, technical background is a critical skill for a scrum master. Things are rarely black or white, but how is a scrum master coming from (say) a business school able to deeply understand the importance of TDD? Why would she value pair programming against the common belief that it slows the team down? How is she in a position to understand the significance and implications of deploying on production or how much does a defect cost and how it should be prioritized and treated by the team?

Now, don’t get me wrong. I don’t mean that the scrum master should be an expert software engineer, but a decent level of familiarization with the complex field of software engineering would be really beneficial to the team.

Of course, the team itself should be primarily responsible for these techniques, but I wouldn’t want a scrum master just to set the meetings up, book the room and bring the sticky notes. I want one who is enabling the team to work in a better, more efficient way. One that is coaching the team members and guards the process and practices in a meaningful way, encouraging increased code quality.

This post is based on a presentation I gave on the 39th Athens Agile/Scrum Meetup