Scrum Dysfunction #1

I was talking with a friend of mine, a seasoned Finnish sw specialist having worked as tester, developer and Scrum Master. It was interesting discussion because I’ve lived outside Finland for almost 10 years now, and a bit lost the touch with Agile Finland.

What he told me surprised me and terrified me at the same time – that most Finnish Scrum Master positions contain up to 80% coding! I really thought he was joking. My friend was horrified also, but seemed to have accepted this fate as “normality”.

Later that day, I ran internet job searches, which only confirmed my friend’s sad notion; basically all (only 3 open in the whole country!) Scrum Master-like positions were hybrid ones containing either classical Project Manager-stuff or programming. Typical open position was titled “Coding Scrum Master”.

I’ve seen this anti-pattern emerge also in Germany, but in much smaller scale. Scrum Masters four operational areas are roughly:

  1. Coaching and Facilitating Events for the Dev Team
  2. Coaching the Product Owner
  3. Optimising Technology & Tooling
  4. Optimising the Organization (Collaboration, Innovation, Delivery)

If we make Scrum Masters do developer or project manager work, then that’s all counter-productive to the essence of what Scrum Master’s role is all about. Therefore, the number one Scrum Dysfunction is Scrum Master’s wrong work assignment. Scrum Master’s should never be programming nor running classical Projects. If companies get this role wrong, then there’s no rescue after that and organisation’s old behaviours will be repeated ad infinitum. But if companies get this bit right, then at the very least the basis for learning organization exists, making success and process agility achievable.

“Coding Scrum Master” is an anti-pattern. Don’t do it!

I further asked my friend the rationale for these hybrid roles, and to his opinion it was a cost-saving thing. The thinking seems to go “if we combine a scrum master and a programmer, then we’ll get more out of that team while saving money…”.

I don’t think this is sound logic at all, but merely a fear-based reaction. There’s simply no proof (theoretical nor practical) that forcing someone context-switch between two roles would make them more effective in either. I’d think this will only piss off SM-Programmers, because eventually they’ll realise they’ve been scammed by getting only one salary for two person’s work. (btw, been there, done that…)


Companies who create hybrid roles ought to brainstorm about productivity. There might be alternative viewpoints coming from those sessions. One of those viewpoints might even be, that committing to long-lasting teams with dedicated Scrum Masters, might actually improve the performance, shorten delivery cycles, or improve predictability. That in itself would be a huge discovery yielding in direct and indirect cost-benefits.

These brainstorming workshops, could be even being facilitated by their Scrum Masters, if they didn’t have to program. Wink-wink, nudge-nudge… 😉



One thought on “Scrum Dysfunction #1

  1. Agreed. However I’ve also sometimes seen a dual-role be designated, not for cost savings, but because of cost restrictions: e.g. there was only enough funding for 3 developers and a BA.

    What can be done when the customer simply cannot afford a scrum Master?

    At what team size do you make the jump to having a dedicated scrum Master?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s