Bas Vodde

The best Scrum Masters I’ve encountered spend part of their time as technical coaches for their teams. 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, as it was 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. In the checklist, one of the four focus areas for a Scrum Master is, “How are our engineering practices doing?”

A Scrum Master doing technical coaching has three important benefits:

• It improves the team’s development practices.

• It lets you experience the real problems 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.

There are many activities for a Scrum Master to “do.” Some examples from my own work as a Scrum Master are:

• Pair up with team members. (This is the most common activity.) Just announce during the Daily that today, you would like to pair.

• Set up 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 an example.

The biggest risk is of becoming too involved in design decisions, as the team could start depending on your contributions. You can avoid this by:

• Never planning your development time in the Sprint.

• Never picking up a task from the Sprint Backlog.

• Avoiding making decisions. When asked for your opinion, provide many alternatives and keep reminding the team that it is their decision.

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 they will become annoyed.

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