I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
(And to be clear, everything I'll write here is going to apply to any personnel manager, whether that's a manager, director, vice president or even CEO.)
While I don't think it's desirable to have team members also have a reporting relationship to their ScrumMaster, I don't think it is always horrible. Much depends on the person who is filling both roles.
One of the common arguments against a manager as the team's ScrumMaster is that team members will become reluctant to raise issues. For example, a programmer who is behind on a task will not be willing to say so in the daily scrum if his or her manager is also the ScrumMaster.
That’s simply not true. With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue.
If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it. If the wrong person is in place, there are lots of problems.
But it’s time to stop defining processes to prevent problems and create workarounds for the troublesome people in the organization. Instead, assume the right people are in place and then work to create a culture that puts the right people in place.
With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world.
And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.
I have contrary experience to Mike in this case. Let me explain.
My View
I think Mike’s view is too personal…to him. I would imagine and rightfully expect him to be able to balance multiple roles in an agile context and not diminish his effectiveness in any role. But that’s him.
In the real world, I have observed that having any “people manager” serve in either of the Scrum roles is 95% of the time…a disaster. It just doesn’t work.
That is – IF you’re goal is to create a high-performance, self-directed agile team. I’ll give you two examples to make my point.
First – Mary
Mary was the Director of QA at a company where I worked. She was a wonderful agilist and leader with deep and broad experience. She also had a heck of a lot of experience building automated frameworks and we were trying to increase our automation at this company.
To lead the automation effort, we decided that Mary should be the Product Owner of the team building it. It was composed of a hand-full of testers with strong development skills. It also had connections to other teams to test their work.
Over several months we noticed something. The team seemed to be doing just what Mary wanted as far as implementation. She was inspiring all of the design creativity and the team seemed be going along for the ride.
When I spoke to her about it, she was aware and also frustrated by the pattern. You see the team was not “owning” the automation design/architecture or the strategy. It was Mary’s. Upon more discussion, we decided that the root problem was:
- Everyone on the team reported to Mary
- Everyone on the team respected her agile experience
- And everyone on the team really respected her as their leader
So no matter how “good” she was at hiding it or abstracting it, her ROLE had influence on the team.
When we later replaced her with a “normal” Product Owner, the team emerged and began taking ownership of our automation efforts.
Next – Josh
Josh is a good friend and colleague of mine. He was working at one company as their Sr. Director of Engineering. He led a relatively small group, so he operated as their coach and ScrumMaster. The organization was slowly growing and I occasionally would chat with Josh around how he was scaling things.
One day in a conversation he expressed frustration with his teams. It seemed that in retrospectives, they were generally not taking initiative or action in any continuous improvement efforts. It seemed as if Josh had to “drive” everything with the retrospective.
After a few months of hearing this same pattern, I got frustrated with him and asked him if I could give him feedback. He agreed.
I said…
Josh, you know what the problem is. It’s you. You shouldn’t be the ScrumMaster and you shouldn’t be facilitating the retrospective. Your teams really respect and appreciate you too much to disagree with or suggest anything that you might not like. They’re being quiet and acquiescing because YOU are in the room. Get out of the room and get out of the role. Now!
To his credit, Josh did that not long after our conversation. And within two sprints, the teams started “behaving” the way Josh had wanted/envisioned them to behave.
Wrapping Up
Both Mary and Josh are incredibly solid leaders with great agile chops and even they struggled to make the balance work. And that makes sense because it’s not solely about the leader in the Scrum role. And this may be where Mike Cohn missed the mark. It’s also about how the team perceives and reacts to the person in the role.
If this dysfunction occurs with experienced agile leaders, imagine what happens with those who lack agile skills and knowledge?
That’s right, it’s usually a disaster.
Finally – Brian
Brian was a manager of a team of backend engineers at a company I worked for. The ScrumMasters at the company used to complain to me that Brian would “swoop in” to their teams 5-10 times a day to try and tell folks what to do.
It would be an emergency that he wanted to drive closure on or a story the team was designing that he wanted to weigh-on on. There were always a myriad of reasons that Brian felt the team needed his “help”.
The ScrumMasters would do their best to “defend” their teams from Brian’s intrusions, but they also escalated Brian as an impediment to me for coaching.
Imagine Brian being a teams ScrumMaster. How do you think that would turn out?
I do understand where Mike is coming from and I respect his opinion. However, I am going to continue to recommend that leaders and managers not adopt Scrum team roles, as it’s just TOO UGLY and simply too challenging to get the balance right.
And that includes me assuming the roles as well!
Stay agile my friends,
Bob.