Scrum Rules: Your Scrum Master Avoids Doing Hands-On Technical Work

The Scrum Master is focused on two main goals: to remove obstacles of all sizes and to help the team become better at using Scrum. Both of these jobs require much work and plenty of skill.

To do this well the Scrum Master will need to refrain from doing hands-on technical work. If the Scrum Master does this then the team will be protected from interruptions, move faster, and feel supported. If the Scrum Master doesn’t do this then the team will be interrupted often, become slow, and feel unsafe and in harms way. A Scrum Master doing hands-on technical work is wasteful and distracting. Although the Scrum Master may appear to be idle at times, this is an investment in readiness: readiness to help, readiness to shield, readiness to learn. We don’t want our firefighters to be constantly busy fighting fires – and we don’t want our Scrum Masters to be constantly busy solving critical problems. Time to think allows for strategic problem-solving that is difficult if a Scrum Master is also expected to contribute to the technical work of the Scrum Team.

As this is not a core rule of Scrum, it is important to understand the context in which it is best applied: mid-size to larger Scrum Team (6 people up to 12 people). If the team is small, then the overhead of having a Scrum Master not contributing technically can be infeasible. In this situation, some organizations choose an even worse option to have a Scrum Master work with multiple small teams – this is strongly discouraged. Rather, a Scrum Master for a small team should still be a full-time member of just that one team, and contribute to the hands-on work in a way that is non-disruptive to their work as a Scrum Master. The Scrum Master work should always take precedence, even (or particularly) in situations of technical urgency.

The Scrum Master who is doing technical work may be motivated to do so for a number of reasons including a desire to help the team, management request, or personal interest. Although there might be some differences depending on the reason for doing the work, in general, the way to improve the application this rule of Scrum is to provide motivation to the Scrum Master to change their behaviour. In the simplest terms, if the team can identify non-technical areas where they need help, this can often provide enough motivation to the Scrum Master. Some common non-technical areas where teams need help include:

• effective retrospectives
• physical collaboration environment
• breaking dependencies to work done outside the team
• distractions from the focus of the Sprint
• overcoming bureaucratic waste
• constantly shifting priorities
• people “on the team” who are also working on non-team activities during Sprints
• limited access to technical and financial resources
• slow decision-making
• fear of making mistakes (usually a leadership issue)
• HR policies and practices that are incompatible with Agility and Scrum
• … and many more!

Just seeing this long list of problems that a Scrum Master needs to deal with is often enough to motivate a Scrum Master to reduce or eliminate their motivation to do technical work – after all, the Development Team is responsible and capable for that work!

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…