I often find that companies looking for a Scrum Master want someone to run their standups, planning and retrospectives. They want an agile project manager to manage the projects, to report status, to track budget.
They seem to not want the change agent and process improvement aspects of the Scrum Master role. Or, they want a little change agent and process improvement to happen as long as it's directed towards the team and not management. And anything directed toward the team mustn't involve facilities or pair programming. Or HR. Or empowerment.
But isn't that what a Scrum Master is supposed to be, a coach?
I dislike this dichotomy.
There was a recent discussion on the Agile Alliance discussion group on LinkedIn about the career growth path of a Scrum Master. The question was, is there a growth path? I liked Irene Michlin's response:
Have they all brought their teams to "performing" stage? Process is perfect, as in "nothing left to improve" a constant motive in retrospectives?
They are either all very brilliant and need to go and become trainers and coaches, or they don't get what it means to be a Scrum Master.
If there is something left to improve, then your job as a Scrum Master is not done -- you haven't mastered Scrum Mastering. Or, at least you aren't done coaching. But there is that distinction again.
I dislike this distinction between Scrum Master and coach. Unfortunately, I find it useful. It's a tell, as in poker. It helps evaluate an opportunity. It's how the conversation goes. "No, I won't be your Scrum Master, but I'll gladly train your team to handle this role. I'll be your coach. Are you ready for a change agent?" Sigh. I find it useful, therefore I tend to perpetuate the distinction.
What should we do? Not use the term coach and elevate the term Scrum Master? Should we live with it because it is what it is? Once the dichotomy is there it's not possible to kill it. Is there a useful distinction between the two?