scrum-master philosophy

[cellio]

I've mentored a few other scrum masters and am writing down some of my so-called sage advice for coworkers. This part isn't specific to our organization, so I'm posting it here and not just behind a corporate VPN.

--

Philosophy

The scrum master and product owner should work closely together and ideally be able to complete each other's sentences stand in for each other. As scrum master I'm not the one who makes decisions about priorities and technical direction, but I should know enough about everything we're doing to ask questions and prod gently. The SM and PO are partners and each strengthens the other. Have 1:1 conversations with your PO alongside the team discussions.

Asking questions is a great, non-threatening way to prompt conversations. Think Socrates.

According to Agile (not just SAFe, the specific framework we use), part of the scrum master's job is to remove roadblocks. In my opinion, a key aspect of this is a style of "servant leadership" -- if there are things that "anybody" can do and other things that require expertise, then to the extent possible, as scrum master I should take the former so that other team members can do the things that only they can do. This is why I do easy server backports, participate in PR reviews, and help with functional testing, none of which fit into my official job description.

To an outside observer a scrum master might look a lot like a project manager, but you're embedded in the team, not coordinating things from outside. You do need to do the management stuff, but don't let it keep you from being part of the team too. You know the work, you know the people, and you know how to talk with the latter about the former.

Comments

[madfilkentist]

My experience with scrums is that they assume that there's no such thing as expertise, that everyone is qualified to participate in decisions on everything. That was one of the things that pushed me to quit my job at HUL.

[cellio]

The people with the trademarked framework ("scaled agile") made claims like that in the paid training we all had to take, yeah. Our scrum teams were the successors to strong cross-functional teams where all the individual contributors already knew that's BS (and doc and QA had established seats at the dev table). We account for the individual strengths on the team, and over time the person in charge of this has backed off because we get stuff done.

I didn't get this "people are fungible" vibe from my previous experience with scrum. I've heard it said of Kanban but have no direct experience there.

[jducoeur]

Sounds right -- I've usually been acting as agile faciliator and architect at the same time, so the second point falls out naturally from that. But the best experience I've had was one where the first point was very true.

(The Product Owner was an older guy who had been doing Product Management and SME in the field for decades, so I was apprehensive of how he'd deal with it. But when I described the process to him, his response was basically, "This is what I've been looking for all along!", and took to it like a duck to water, picking up most of the nuances quickly. That was a truly excellent collaboration.)

[cellio]

That sounds like a great collaboration, yes!