Apr 4, 2014

The notion that a Scrum Master should in any way review teams or team members goes against core scrum.

‘… when it comes to [Scrum Master] … participating in the annual appraisal, ratings, or rankings, my answer is “No. No. No!”

– Thoughts from Esther Derby, author of Agile Retrospectives.

The assumption that the team (or individuals) should be reviewed and rated by the Scrum Master is toxic to transparency and the servant-leadership relationship of the Scrum Master.

Teams have the following characteristics: They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; (scrum guide, p. 5)

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. (scrum guide p. 6)

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. (scrum guide, p. 15)
Thoughts from Mike Cohn, founder of the Agile Alliance:

“Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority.”

“… the ScrumMaster’s authority does not extend beyond the [scrum] process …”

The idea also assumes that people need to be measured and commanded in order to do a good job (Theory X).

The 5th Agile Principle encodes Theory Y:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

Let us avoid ScrumBut. (“We use scrum – but our Scrum Masters rate the team or team members”)

Digging Deeper

Digging deeper to find the question-behind-the-question, we might ask “how can we ensure teams e.g. implement Architecture 2.0 even when the Product Owner neither understands nor cares? (or worse, the PO is actively lobbying for short-term solutions).

If THAT’S the problem, then consider:

• this is a systemic problem that requires a fix to the system, not a local fix
• it is not resolved by having the SM review teams or team members; that will just make things worse for the team

There are some things that we (management) are able to declare as “required”. We need to make those items painfully clear and unambiguous. Furthermore we need a conflict resolution protocol that will allow teams to get relief rather than dialing up the stress. Given the immaturity of some of our Product Owners it seems this sort of conflict is inevitable.

Is the Impediments Removal Service this conflict resolution protocol? Should teams that find themselves caught between a PO short term demand and e.g. Architecture 2.0 raise this to the management team to sort out? Given the power relationship between the Product Owner and the teams (teams work for the PO; we’ve given the PO input to performance review), then when these sort of conflicts arise, senior management need to step up and address them, not create a situation with conflicting messages and high stress for the teams.