Scrum Master + Team Lead = Team Master?

Last week, I gave the Scrum Guide a fresh read.  I did this for the simple purpose of making sure I was remembering the rules of the game correctly, and not just having conversations based on echoes of memories.  It turns out that my understanding and recollection had not drifted very far, which was good news.  But it also turns out that I still think of “Scrum Master” as somewhat silly.  I re-read the manifesto, had the same impression, and was somewhat gratified to learn that I have the same taste as myself.

What is a Scrum Master, Anyway?

There’s a lot to like in the Scrum guide, but Scrum Master, in my opinion, just isn’t in that bucket.  At best, it’s a built in sales role for Scrum, and one that should become unnecessary as time passes.  The guide itself is pretty unambiguous about this: “the Scrum Master is responsible for ensuring Scrum is understood and enacted.”  Presumably, once Scrum is “understood and enacted,” the role need not exist.  At its worst, “Scrum Master” is an escape hatch for non-technical project managers in an agile world that largely proclaims them unnecessary (unless re-cast as BAs, product owners, or line managers).

Unfortunately, and in far too many organizations, I think that Scrum Master winds up at its worst.  Scrum falls under the umbrella of agile methodologies, and it says something right there in the agile manifesto (or, at least, the principles behind it) about how to organize teams: “the best architectures, requirements, and designs emerge from self-organizing teams.”  This describes a scenario in which empowered and engaged technical folks figure out how to deliver value to interested stakeholders without relying on traditional command and control structures.

In other words, agile teams (and, by extension, Scrum teams) don’t need managers or masters.  They need a “product owner” to represent the interests of the business and… well, that’s it.  They need someone to explain to them what’s needed out of the software and then it’s up to them to go do it.  It’s refreshingly grass-roots.

The promise of the agile movement is that you don’t need layers of managers and hierarchy between CIO and line-level developer that could rival the military.  In fact, you don’t need managers at all.  So what is this Scrum Master thing, then?  It sure feels like a refuge for displaced managers, be they product, process, program, or project managers.

So all of this was going through my head this week when I opened the backlog of reader questions to pick one to write about.  The question is as follows.

I’m the lead developer of my team on a consulting project. While shopping for new jobs, most other lead developer roles include being a scrummaster. This is not something I am interested in and I have avoided successfully in my current job. If I want to take a new lead developer job, do I have to suck it up and be the scrummaster until I can pass it off? I can’t help but feel I come off as inexperienced during phone interviews if I don’t call myself the scrummaster even though I am the dev team lead.

Is Scrum Master a boss role?

First of all, this is somewhat alien to me.  I must admit that I’ve rarely encountered an organization that rolls Scrum Master in with “team lead.”  That’s probably reasonable, since Scrum itself doesn’t acknowledge the existence of such a role.  To wit, the guide proclaims, “Scrum recognizes no titles for Development Team members other than Developer.”  So if an organization is making the ask, “we want a Team/Lead Scrum Master,” they’re probably a “Scrum-But” team.

Now, this isn’t intrinsically bad.  “We have no role but Developer” is a nice, egalitarian sentiment, but in a corporate world with experience matrices, dotted line reporting relationships, leadership roles, and variable pay structures, it tends to be something of a false promise.  In other words, if you show me a team where everyone has the title “Developer,” I’ll show you a team with a bunch of different salaries and varying “unofficial” responsibilities.

So the reason I mention Scrum-But isn’t to dissuade from considering such companies, but rather to provide some context.  Specifically, these organizations most likely don’t grok Scrum or implement it faithfully.  This allows for some wiggle room in how you and the organization define your role, and that wiggle room will come in handy.

When doing interviews, you can engage in a bit of opportunistic expectation management.  They’ll ask questions about whether you’re comfortable in that role, and there’s no downside to saying that you are.  After all, the only real requirement for this is understanding the rules of Scrum, which you can achieve with a few reads through the Scrum guide.

But you can also introduce a subtly impressive credential that sets the stage for positioning yourself not to do it.  You can explain that on teams you’ve led in the past, you had such success with Scrum that the role became unnecessary, since the team understood it well.  Then, once you’re hired and you make sure the team knows how to conduct its affairs, you don’t really need to worry about playing daily standup referee and other such things (though I would argue that part of a good lead’s responsibility is to take on the Scrum Master’s task of fending off distracting outsiders).

However, to circle back to the original premise, I don’t think it’s actually necessary to agree to a Scrum Master role in order to get a team lead role.  Trivially, you don’t need to agree to it if the team isn’t doing (or pretending to do) Scrum.  This doesn’t mean that the team has to be strictly waterfall, either.  You can seek out a lead role for an XP team or any sort of generic “agile” team that doesn’t define Scrum’s roles.  Or, you can interview for the role but stipulate during the interview process that you prefer to delegate this role to someone without leadership responsibility to avoid a conflict of interest.

But in the end, I wouldn’t really advise letting this bullet in a job description be a deal breaker.  It’s too hard to evaluate meaningfully and too easy to delegate.  And, besides, if you’re being given the role, “team lead,” it really ought to be up to you to determine who fills which role.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

Get the content!