Scrum Confessions – Part 2

In the second part of the confessions, I would like to talk about the scrum masters and the role itself. It is a difficult topic to approach, many companies and teams are very convinced of their love or hate for the masters they have or had. I personally also do not have any strong belief about the scrum muster function. I think the company culture, size and experience of the teams and the specific facts about the project are important to decide if and how scrum masters should be working with the agile teams.

I have experienced countless situations where the contribution and existence of scrum masters played the biggest role for achieving results. And I am not judging if the role is needed or not. My confession aims  to discuss about the difficulties and dilemmas related to the role that not many managers and agile coaches do not even mention about.

Confession 3:  Scrum master role might help or hurt companies and teams

88% of the scrum masters take on additional responsibilities beyond that of a scrum master. I think it is a natural outcome in many companies.  A self-organizing and gut performing team will be able to run the scrum process and minimize the need for coaching after a an initial peak phase of its teaming. Each organization has to consider the values, opportunities and risks of the scrum master role implementation that it has.

A scrum master who is supposed to act as a servant-team member or an agile couch can easily become a overshadowing figure who replaces the people manager in time or turns into a “master” in the team that gets all the air time with the senior management, tells the qualified engineers what to do, introducing rules and create an invisible authority on the qualified developers in the team. It is important to judge what personalities would match to the expectations for the role and make sure that the doers (developers) do not get frustrated, limited or exposed to pressure by this role. I have seen cases where developers underperformed or left to company because they were not extrovert enough to resist to such misplaced “masters” in their teams.

Another issue is the people management. Scrum masters in many organizations take on people management responsibilities, often without being qualified or without having the accountability. Many developers can spend months without talking to their direct people manager and they get regular “couching” from  “the master” who possibly does not have any engineering background or management experience to handle important issues regarding the developers’ career and development. Such situation creates an atmosphere of management attention vacuum for the developers. He loses contact to management, communication meetings and decision platforms while scrum masters run the show with middle management in the name of the sacred team. I have seen teams that enjoyed the sick leaves and vacation times of their scrum masters and performed better with this relief.

In case that it does not happen and the scrum master sticks to his role of making sure the scrum process in run correctly and remove impediments for the team, it takes no more than 2-3 years that a scrum master starts feeling underutilized, not challenged enough professionally and not recognized by his colleagues regarding his skills and potential. It becomes a management challenge to offer attractive career opportunities for these individuals within the technology departments.

Finally I would like to repeat how I appreciated working with many great scrum masters. The role and the implementation in the corporate world is not easy and it is time to discuss for the sake of the dev teams and the great masters to figure out how this function should evolve.

In the next part of the confessions I will continue talking about other scrum challanges like lifecycle management and architecture.

%d bloggers like this: