Scrum Master: Influence Without Authority

A software development process is dividing development work into distinct phases to increase the speed of providing software solutions, improve the quality of software and manage the development process efficiently. The development team chooses the software development methodology that will work best for the project at hand to practice the standard development process. Scrum is common proclamation that contains values, and principles in which the software team follows it as the guideline. The core principle of Scrum philosophy is simple and practicing it abandons the risk of spending a lot of time on a process that ultimately fails.

Scrum is a Process Framework (PF) that guides people to understand which artifacts and when should be produced to adapt agility for the team to build a product. The traditional role of the project manager in the Scrum team gets divided between the Product Owner (PO) and Scrum Master (SM) to monitor and control the process framework. PO has some level of authority about the product; However, SM has a more challenging task since it doesn’t have manager authority. He/She must ensure that the scrum team is conducting the Scrum events within the time-box. SM should ensure that the Planning, Daily Scrum, and Review events take place and that attendants understand its purpose. Moreover, in the Retrospective event, the SM participates as a peer team member in the meeting from the accountability over the Scrum process to ensure that the meeting is positive and productive. SM not only facilitates the process and constantly improves it, and resolving impediments, but also makes sure that teams deliver. Thus, the successful SM is the coach who properly hosts Scrum events and guides the Scrum team to practice it properly.

With the above-mentioned volume of responsibility a certain amount of support from the team is needed because, if in certain situations the SM has to take action on certain aspects and if there is a disconnect between the team and him/her, it can lead to a situation that will make everyday operations challenging. So, the SM must show the team that he is on their side and is just another team member. He/She should not fill his time only with the administration tasks. If he does it, he is in the wrong place. Admin tasks are just a tiny fraction of SM’s role responsibilities. The goal of the SM is to deliver software and not to produce reports using fancy terminology. Therefore, administrative tasks undermine his sense of being useful and that can disrupt the team. To avoid it, the main role of SM has to be combined with other roles. Now the question will arise as to what roles can be combined with the SM role and what issues may be involved? 

It makes sense for the SM to have a Development background but does not necessarily make sense for the SM to be a developer. The reason is that the SM role workload is not determined, so there is an issue for the SM to commit to tasks during short sprints. Moreover, if the team must learn new technologies, the SM might not get the same opportunity as the rest of the developers due to the load of work. If the role of the SM is combined with the role of Quality engineer (such as tester), the sprint level commitment, and learning curve issues occur again. However, the learning curve might be less steep than in the development role so it might work better, especially if there is another quality specialist on the team and SM contributes when possible without being the bottleneck. Line Management might be suitable for the SM since the role changes from no authority into actual authority. This can work, but it depends totally on the personality of SM. Sometimes the PO brings requirements to the team, this PO will be called PO-Business Analyst. But sometimes the PO can define requirements by himself. I don’t think it will work for the SM to have combine roles of SM and PO; however, SM on the team can be a PO-Business Analyst. Again, it all depends on the complexity of the project and situation. But usually in the industry merging those two roles is not recommended, due to potential conflict of interest. Finally, SM can be a team expert on some topics such as security, UI designer, DevOps. Those roles don’t have hard commitments on a sprint level. 

It is important for the SM to be transparent with the team on what he is doing, since often the SM role and duties are not clear within the team, and his contribution and deliverable are not always visible to team members. However, in the case of a mature self-driven team, the SM role can be less demanding, and, in this case, the SM can commit on a sprint level. 

When you run the role of SM, you can easily become a shooting target to your team and to players external to the team. However, in this case, remember to use your manager to talk out your issues and to look for solutions. To conclude: The SM role is not simple. It takes a lot to be able to influence without authority and to be a servant-leader of the PO, development team, and the organization. The SM should act as “an insightful shepherd” who is responsible for supporting Scrum by bringing adaptation, transparency, and inspection to the team. Thus, SM optimizes the process in the team to help the team to achieve the most value and protects his team members from deviation and external interruptions. Finally, remind that Knowledge and Empiricism of Scrum build confidence, and confidence creates ‘Mastery’. 

References:

• The Definitive Guide to Scrum: The Rules of the Game - Ken Schwaber and Jeff Sutherland. 
• How to Kill the Scrum Monster - Ilya Bibik.
• Real Scrum and More - Alex Manfield.