Monday, March 4, 2013

Measuring the Success Of The Scrum Master

The Scrum Guide states, "[T]he Scrum Master is responsible for ensuring Scrum is understood and enacted." Scrum is defined in the Scrum Guide as follows: "Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." So, one could logically conclude that the scrum master role is responsible for ensuring the scrum team is "productively and creatively delivering products of the highest possible value." I think that the CEO, CTO, Development Department Manager will particularly note the "highest possible value" aspect of the scrum master role and want to know if the scrum master is coaching the team toward this goal. Here are a few points to track the success of the scrum master:
  • Is the scrum team (development, product owner, and scrum master) following the 12 principles of agile as defined in the agile manifesto?
  • Is the scrum master ensuring the scrum team (development, product owner, and scrum master) is following the rules of scrum as defined in the scrum guide?
  • Is the scrum master helping those outside the scrum team understand agile and scrum?
  • Is the scrum master protecting the development team from interruptions?
  • Is the scrum master removing obstacles and problems affecting the scrum team e.g. getting better computers, coffee, baby sitters, listening to problems ...?
  • Is the development team moving toward being self-organizing?
  • Is the development team moving toward being cross-functional?
  • Is the development team enjoying work or do they dread coming to work?
I think most measures for scrum master are subjective but that really means you must exercise greater caution when applying your scientific methods. For example, if the product owner randomly asked ten customers if they liked the user interface to a product and one voiced the opinion that it's bad, then you probably wouldn't change the interface. If however, nine of the ten voiced the opinion that the user interface is bad then this means something even though it's still all very subjective. What the product owner is doing is taking purely subjective measures and objectively applying them to the science of statistics. Could all nine customers be an anomaly with your other 991 customers happy with the user interface? Of course the answer is yes but it's also very unlikely.
Measuring the scrum master's performance against the expectations found in the Scrum Guide can follow the same principles as above. For example, measuring the scrum master’s service to the development team in "coaching the Development Team in self-organization", one could use several subjective measures together, with any weighting you choose, and reasonably determine over time if the development team is becoming more, less, or remaining static in self-organizing, assuming the method of measuring and weighting remains constant. These measures might include:
  • How does the scrum team rate itself in forming-storming-norming-performing?
  • Does the development team pull items from the product backlog rather than having them pushed onto them?
  • At the daily scrum, is the development team providing status to the chickens or are they planning the day's work?
  • At the daily scrum, does one development team member repeatedly advise others of what work they should be doing?
  • At the retrospectives, does the scrum team actively pursue areas for improvement and then execute on these improvements?
  • Does the development team often seek outside assist on how to implement a user story?
Enough subjective measures can be found to objectively determine if the development team is self-organizing.

What Is Success?

You may often times hear that working software is the measure of a scrum team's success and this is then used to determine the general success of every person in the scrum team, including the scrum master. I would argue that this is not enough since working software doesn't necessarily mean it's valuable. Think about delivering working software after the company had already lost a competitive advantage or delivering working software that no one wanted or bought. It's also conceivable that some customers, early adopters spring to mind, would tolerate software that doesn't completely work in order to see the concepts and the potential of the product. The Scrum Guide specifically allocates responsibilities to the product owner and scrum master with regards to adding value; not so for the development team. I think that "value" in the context of the Scrum Guide is value for the customer and, consequently, for the business. The rules and practices in the Scrum Guide are there to support the 12 agile principles including the very first, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." It's the scrum master's role to ensure that the scrum team "satisf[ies] the customer" through the “continuous delivery of valuable software". The scrum master does this by making sure the scrum team "adheres to Scrum theory, practices, and rules". It's the responsibilities of the scrum master, as defined in the Scrum Guide, that business can use to measure the success and effectiveness of the person given the role of scrum master.