The Scrum Master as a Technical Coach

(this article is the first in a series of posts. Some of these might be published in the upcoming book “97 Things every Scrum practitioner should know” in the O’Reilly series, which will be edited by Gunther Verheyen)

The Scrum Master as a Technical Coach

The best Scrum Masters that I’ve encountered spend part of their time as a technical coach for their team. Unfortunately, it seems that most Scrum Masters do not do this. To me, this seems like a lost opportunity since spending effort on technical coaching for your team can help them enormously, and it will help you with your other Scrum Master responsibilities.

It often comes as a surprise when I suggest that a Scrum Master could (or even should) do technical coaching. It shouldn’t! Technical coaching isn’t explicit in the Scrum Guide [1] as it is written to be applicable to both technical and non-technical work. Therefore, technical coaching is only mentioned as “Helping the Development Team to create high-value products.’’ That is unfortunate. However, some other great Scrum resources do refer to technical coaching explicitly, such as Michael James’ Scrum Master Checklist [2]. In the checklist, one of the four focus areas of a Scrum Master is “How are our engineering practices doing?”

Scrum Masters can (should) do technical coaching and that shouldn’t come as a surprise.

Why should a Scrum Master doing technical coaching?

Regular technical coaching has three important benefits:

• It improves the team’s development practices.
• It lets you experience the real problems that the team faces. This helps you in deciding where to focus the team, the Product Owner and organizational improvement work.
• It keeps your technical skills up-to-date.

What kind of activities can a Scrum Master do?

Some examples from my own work as a Scrum Master are:

• The most common activity: pair up with team members. Just announce during the daily that today you would like be pairing.
• Setup your computer so that you can build and run tests.
• Refactor some tests and code and have a sharing session with your team.
• Create some unit or acceptance tests.
• Organize a learning session about technical agile development practices. Use your team’s code as examples.

What to avoid?

The biggest risk is to become too involved in design decisions, and the team starts depending on your contributions. You can avoid this by:

• Never plan your development time in the Sprint.
• Never pick up a task from the Sprint Backlog.
• Avoid making decisions. When asked for your opinion, provide many alternatives and keep reminding the team that “it is your decision.”

How to start?

It shouldn’t be hard to add technical coaching to your work as a Scrum Master when you have development experience. It just requires you to prioritize and plan for it. One option is to plan one or two days a week to focus on this. As the context switching might make it hard, alternatively, you can dedicate a Sprint on technical coaching and try to limit other Scrum Master activities.

If you do not have development experience it will require more effort. It is possible to learn the basics of development and the purpose of agile development practices while being a Scrum Master of a team. You can ask your team for help. Tell them, “I want to improve my development skills, could you help me with that?” Work out a plan together and dedicate time for learning. Spend a lot of time pairing, but avoid asking too many questions as it will slow down your pair and he/she will become annoyed.

Good luck with the technical coaching as Scrum Masters and I hope you will find it as rewarding as me.

1. Schwaber, Ken, et al.https://scrumguides.org. November 2017
2. James, Michael. https://scrummasterchecklist.org. Revised 2 Feb 2016.