Should A Scrum Master Participate In The Team's Evaluation Process?

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

In many ways, a scrum team functions just like any other project development team, in the same manner as teams following traditional waterfall methods do i.e. they fundamentally develop and deliver projects. Even though a scrum team functions in a manner which is subtly different as compared to non-Agile teams, it is nevertheless subjected to the annual evaluation process – an activity undertaken by all companies associated with project development. A frequent dilemma often experienced by the project owners is deciding whether a scrum master should ideally participate in the annual evaluation process, in which the performance of individual scrum team members is apprised and evaluated, and the increment in remuneration is determined.

Why should a scrum master take part in the evaluation process of team members?
The scrum master is closely involved with the project development activities, and knows about the quality of work delivered by the development team. He or she knows each team member on a personal basis, and is well aware about the potential possessed by the ...
... particular team member. Moreover, during the sprint review meetings, when the completed user stories are exhibited to the product owner, the scrum master also gets to know about which of the team member is actually delivering successful and shippable stories. Since the role of the scrum master involves frequent and prolonged interaction with the scrum team, the stakeholders often feel a scrum master is a perfect person to adjudge the overall performance of each team member, and should therefore participate in the annul evaluation process.

In practice, should a scrum master actually participate in the evaluation process?
In direct words, the answer is “No”! Considering Agile scrum practices and principles, the scrum master is an important team member, and even though he or she is fundamentally responsible for implementing the scrum process, the person should not be invited to participate in any activity concerning the evaluation process. The reasons are many and can be summarized in brief:

• The collaboration process gets disturbed and loses its effectiveness
Scrum is all about collaboration and adaption to changes. Team members need to interact and share their ideas and opinions to uphold and facilitate the collaboration process. The scrum master is closely involved with the team’s day-to-day activities, and is responsible for promoting the collaborative atmosphere while scrum is being implemented. For the collaboration process to be successful, a lot depends upon how the feedback is received from the team members. Timely and proper feedback fosters collaboration. If the scrum master starts participating in appraisal related activities, the team starts hesitating in sharing important feedback related to certain aspects pertaining to the development of user stories. The team may feel discussing technical difficulties with the scrum master may create an impression that the particular member is not effective while dealing with sprint related issues, and may be incompetent. As a result, the transparency aspect, which is so very important during scrum implementation, is deliberately comprised upon, and the members try to resolve the issues on their own. The collaboration process is disturbed, and over the weeks, the team starts working independently on its own. Instead of working in unison and delivering work jointly as a “whole” unit, each member starts working independently, and begins taking personal credit for shippable stories developed by him or her. This is in antithesis of what scrum stands for, but the team feels whatever work it delivers will be “looked upon” critically by the scrum master, and it may further affect and hamper each member’s growth in the long run.

• The “trust factor” starts reducing
In many ways, the scrum master and the product owner are looked upon as ideal scrum leaders and their saviors by the scrum team. Issues relating to the acceptance criteria and the definition of “done” is resolved by the product owner on behalf of the team, while the scrum master tries to make sure any technical difficulties faced during the daily sprints are looked into, and properly resolved, so the development activity does not suffer. The entire team looks upon the scrum master as its mentor, and confides in him or her, even on a personal basis, when the team members face any impediments or problems. The primary reason why the team is able to put a lot of trust on the scrum master is because it feels he or she is an “inside” person, and a well wisher, who will go to any lengths to ensure proper action is taken for a specific problem, and the person will help the team members on a “personal” basis if required. For the team everything is lost when it starts feeling that the scrum master “belongs” to the management and not the team per se. The trust, which is so easily given otherwise, is reconsidered and evaluated. The intimate gap between the scrum team and the scrum master starts widening on a consistent basis. This harms scrum implementation.

• The scrum master is looked upon as a management person
There is always a “natural conflict” between the management and the development team as far as delivering productivity is concerned. While the team always feels it is putting in everything it can, the management tends to think otherwise. The team is often at cross roads with the management while delivering the project goals, and this is quite often reflected in the manner in which it approaches and communicates with the management. As far as scrum is concerned, the scrum master is an inherent part of the entire team, and is looked upon as a person belong to the “team”. The role of the scrum master is to facilitate the scrum proceedings, and put in a good word for the team whenever it is possible. As a result, the team looks upon the scrum master as its mentor. All this changes when the scrum master starts participating in the evaluation process. Uncertainty and diffidence seeps into the team with regards the role of the scrum master as he or she is looked upon as a management entity, rather than as a scrum associate and mentor.