Mission Possible: ScrumMaster and Technical Contributor

Someone with technical skills might tell team members how to approach a problem rather than providing guidance and input. He wants to be able to share his experience to help the team avoid pitfalls, but he also wants everyone to understand that his technical advice is not dictating a choice of action, as making all of these decisions can ruin the dynamic of self-organizing teams. The other extreme of avoiding technical discussions when he can help a team resolve an issue is equally risky, as he no longer is filling his role as a technical contributor.

There are no easy answers to finding and keeping this balance, but there are helpful technical facilitation techniques, such as ensuring that teams consider three options and find three problems with each option before agreeing to proceed with it. Gerald Weinberg provides more guidance on finding this balance in Secrets of Consulting [1] and Becoming a Technical Leader [2].

Tips to Balance the Roles

When you are in this dual role, consider the following:

• Whoever manages the ScrumMaster should agree with the balance between the essential project tasks.
• The ScrumMaster should not be in a position of handling many critical-path tasks so that he can work on removing technical or organizational impediments.
• This works better with smaller teams, where the coordination and training effort within the team can be smaller and the effects of leading by example can be greater.
• The manger of the team needs to support this effort and be willing to work on the larger organizational impediments. And, the technical contributor’s manager should be careful to set consistent expectations on the priority of the ScrumMaster activities, so that the technical contributor knows that he will be measured on team output, not individual output.
• The person in this role needs to be aware of facilitation and collaboration techniques to streamline both project and technical meetings. [3]
• Most importantly, the technical contributor who assumes this role has to want it. It's too easy to fall into the comfort zone of solving the technical problem instead of the organizational one. In some respects, project and organizational problems are the most challenging and interesting systems engineering problems.