I was fortunate enough to be the MC at the Happy Melly Exploration Day event in Waterloo recently and was asked this question that I think deserves some exploration.

I do have a question for you about transitioning from Scrum Master to Agile Coach. I heard opinions that say that it’s just a title, and that in fact Scrum Masters often do very similar things to coaches anyway. I agree that this can be the case in some companies, but my observation has been that Agile Coaches usually get a wider mandate and hence are able to better foster overall organizational growth. Also, Agile Coaches could potentially coach more than Scrum. And, here I have limited evidence, but I think there is usually a salary difference, too. So I’m curious about your take on it. What are the biggest differences between Scrum Master and Agile Coach?

It is true that Scrum Masters and Agile Coaches do similar things, however at different levels. It is also true, as you state, that Coaches to get a wider mandate, not only to coach the executives but SM and teams as well. You are seen as the overall expert, answering questions, reviewing sessions, providing feedback and guidance and helping to plan the journey. What are the next steps? What training is necessary? Who should be trained? What do you do about a SM that isn’t performing? About a team?

There is a salary difference, but that depends on the expertise of the Coach, the industry, and the mandate.  It can be a pretty wide range, and that again depends on the maturity of the organization that is hiring you as companies new to the agile process might not place as much value on the role as it deserves.
The biggest differences are what you are expected to do. A Scrum Master works with “A” team. An Agile Coach works with ALL teams, AND executives AND other teams/groups. A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way. An Agile Coach helps to define what is to be done, how, who does it, when, why, how it fits in with the organization, change management, people management and interactions between agile teams and other parts of the organization (like Dev Ops, Hosting, Build teams, Education, UX/UI, etc).

The main difference is the level that the two are operating, single team or enterprise.

Ugh. What are you supposed to do when the executives ask for an “X”% improvement in the performance of your agile teams?

I’ve been researching and reading a bunch of things to try and come up with a solution to this problem and so far it seem like there is no solution. Any way you try and measure a team’s performance can be ‘gamed’.

• Velocity. Easy enough as the team tracks velocity each sprint. As soon as they become aware that they are being evaluated on velocity it is simple enough to make a 3 point story a 5 point story, or an 8 point into a 13 point. Boom! Instant productivity gain.
• Stories completed. This is a better metric, however it sets the team up for some  bad practices. Product Owner needs a simple change? I need a Story for that.  We are being measured on stories? Okay, let’s break the stories out into Dev and QA tasks, also let’s add a CRT task and start putting in tasks for our Agile Ceremonies.

In addition to the bad practices for the stories the good practices that you may be trying to instil, like breaking large stories down to smaller stories, will again lead to a false result in productivity improvement.

All the articles I have read about Agile Metrics have not been any help either.

• Five Agile Metrics you won’t hate list “Sprint Burndown”, “Epic & Release Burndown”, “Velocity”, “Control Chart” and “Cumulative Flow Diagram”
• Measuring Team Performance states that you should use the ability to hit the Sprint Goal, with the caveat that if a team continually hits their sprint goal then they are under performing. This might be a good way to evaluate how the team is doing, but not for measuring any kind of improvement.

The overall goal is definitely to make the teams better, more productive. The issue comes in when the metrics are to be used to evaluate the teams against each other. This can not and should not be done. A team that has a velocity of 120 points per sprint is NOT better than a team that does 40 points.

Executives that are not as experienced in Agile are looking for ways to either judge teams against each other or measure success of improvements through the use of metrics.  In “Metrics you can bet on” Mike Cohn discusses how metrics can be misinterpreted and that as an organization you need to be very careful to measure at the correct level.

Great care must be taken when going down this path. Executives have investors and boards that they are accountable to and have to show value for the money they are spending on these activities.

I think better metrics are turnover rates, happiness factors and improvements made. Look at the teams’ retrospective action items, how many are they solving? How often are people leaving the organization?

No matter what metric is being gathered it is very difficult to use any of it to evaluate team against team or team performance over time.