5 Comments
User's avatar
Cleon Fernandes's avatar

I believe I understand your reasoning behind the one developer taking SM accountability, but it doesn't seem correct. Have you seen that work? I've been there juggling accountabilities between Dev vs SM, it's a path to misery.

As suggested by your LM definition, SM accountability should go to LM, who is actually empowered to pave the Team's road. Ryan Ripley would also agree with LM taking SM accontability: https://www.scrum.org/resources/blog/your-next-scrum-master-should-be-your-manager

Expand full comment
Brett Maytom's avatar

Hey Cleon, thanks for the thoughtful reply!

Yes—I’ve absolutely seen it work in many companies. The key is realising that the Scrum Master accountability is often bloated far beyond what it actually requires. A lot of people fill the “SM job” with fluff and tasks just to justify a full-time role, but at its core, the accountability is about keeping the team focused on empiricism, flow, and continuous improvement. That doesn’t need to be a full-time job when a team takes ownership of what they do.

Jeff Sutherland actually made a LinkedIn post a while back highlighting that in the original design he and Ken created, the Scrum Master was not a separate, full-time role. He advocated a developer take on that accountability. When I was training PSM courses as a Professional Scrum Trainer (no longer one), I made it very clear that Scrum Master is an accountability, not necessarily a full-time position.

On the line manager point—I’m not suggesting they become the Scrum Master. The team still needs to be self-managing, with someone on the team ensuring Scrum is being followed and impediments are being addressed. But the line manager can play a vital support role from outside the team: handling organisational blockers, budgeting, logistics, recruiting, and using their position to influence change. In that sense, I completely agree with what Ryan Ripley is saying too, and I’ve often said the same—line managers are well-placed to support self-managing teams without disempowering them.

Appreciate the exchange—it’s good to challenge each other on these things.

Expand full comment
Cleon Fernandes's avatar

Hey Brett, late reply on this, I just wanted to take the time to think about it.

"That doesn’t need to be a full-time job when a team takes ownership of what they do."

Well, that's true. If they take ownership and are focused on empiricism, flow, and improvement, there's probably no need for a full-time SM in the team.

But, what if they don't have any of that? What if they don't even know what ownership looks like and how could they leverage Scrum to their advantage. Isn't there potential from Zombie Scrum? "Ownership" is also a skill that is absent more often than not. Can we just tell people "Please go, own your stuff!"?

Once most organizational challenges that prevent or limit empiricism are overcome, yup, sure, no need for full-time SM accountability.

Help moving the needle to ownership sounds incompatible with the responsibilities of a Software engineer. When I worked as SM/DEV, I was in a not-so-good position, the team couldn't rely on me to work on PBIs that would help them to achieve the Sprint Goal. So was working on something else feeling like and appendix.

It's not about organizations bloating SM with stuff, it's more about SM knowing what he needs to do.

Expand full comment
Brett Maytom's avatar

Your points valid. I see challenges more in the leadership than with the team as those leaders do not know how to solve and support the teams. They are the ones that need the coaching; i.e. help them help their teams.

Expand full comment
Cleon Fernandes's avatar

That's exactly one of the aspects of SM accountability

Expand full comment