Anyone with a basic knowledge of Scrum, and certainly everyone who has taken Agile Software Project Management With Scrum, knows the role of the ScrumMaster—to be a servant leader, to act as guardian of the Scrum process, to remove obstacles for the delivery team, to negotiate any tension between the Product Owner and the delivery team, to encourage the team to self-organize and be cross-functional, and so on. These are so well understood they’re almost clichés. The difficulty is learning how these abstract ideas apply to day-to-day software engineering.
For example, a common question is “Does Scrum permit a ScrumMaster with a technical background to help deliver features for the team he or she leads?” While this is a common practice and some teams have made it work, the general consensus answer is “No” or at least “Not ideally.” The primary reason is that a ScrumMaster can’t be an honest broker when resolving disagreements between the Product Owner and delivery team if he or she is writing code as a member of that delivery team. No one likes a conflict of interest, right?
However, there are other ways that a ScrumMaster with technical skills can apply them to provide significant value to the project and dramatically increase velocity without compromising credibility or the Scrum process.