Scrum Masters are the champions of Scrum in the organization and they are accountable for establishing Scrum and helping everyone understand Scrum theory and process. They are also accountable for the Scrum Team’s effectiveness and most Scrum Masters take that role pretty seriously by taking charge of how things work.
What happens when that goes wrong? Could the Scrum Master actually be the problem?
We were having a coaches huddle recently and my esteemed colleague Tom Cagley brought up an issue that he thought was relatively common. Some very adept Scrum Masters were inadvertently undermining the agility of their teams. I found the exchange fascinating and invited Tom to an interview to discuss this. Here is our conversation.
Puzzle Pieces, Transactive Memory and Other Scrum Master Problems
Anthony: So Tom, before we discuss Scrum Master problems, you shared a personal anecdote that you said reminded you of this issue. It was related to your Dad – can you tell us what happened?
Tom: I missed my Dad’s birthday…
Anthony: And how is that related to problems with Scrum Masters?
Tom: I rely on my wife to remember birthdays and other dates. Unfortunately for me, she was away with our children and grandchildren having a great time and didn’t remind me. I remembered 10 days later at about 2 AM. It was unpleasant. The concept is called transactive memory. Teams store specific knowledge in one person and then have a way to know who has that information. In this way, teams can know more than the sum of individuals. I know my wife knows the birthdays and I know my Scrum Master knows how to do the Daily Scrum — therefore I don’t have to know. It usually works.
Anthony: Transactive memory sounds like a positive thing unless you consider situations like the one you encountered. That is when that key person is not available. That sounds like what happens with a top. By itself, a top will just sit there on the floor. But if you expend some energy, you can make the top spin. For a while anyway, until it runs out of energy and then you have to expend energy again. This is how the team behaves when the Scrum Master isn’t around. They just sit there until the Scrum Master expends some energy.
You used the word puzzle piece. Can you say more about that?
Tom: Teams are a puzzle they have to fit together. The parts support each other and lock each other in place. Without all the pieces the internal structure falls apart. Transactive memory is part of making the puzzle more than just a pile of parts. You hit the nail on the head of one of the issues. As an example, I recently saw a team cancel their Daily Scrums for six seemingly random days. I asked a colleague what was up, and they informed me that they were going to be out of the office on those dates and NO ONE else knew how to hold the Daily Scrum. Using your term, the team intended to “just sit there”. They got my best stone poker face.
Anthony: Yikes! I’ve seen that poker face before. In fact, you used it on me a lot when you were first coaching me 10 years ago.
Tom: I am sure you have seen issues like the puzzle piece before?
Anthony: You mean teams where only one person knows how to hold the Daily Scrum? Sadly yes! In fact, I wrote a blog about 5 years ago about trying to be indispensable. It was based on an email that I got from PMI that said I should be striving to be indispensable to my organization. They aren’t alone – I think that there are many people who feel that being indispensable is the best way to add value to an organization. Come to think of it, Seth Godin wrote a book in 2011 called Linchpin: Are You Indispensable? Have you heard of or read that book?
Tom: Have you been reading my bookshelf again? While I agree with Seth’s premise in general, I do not think he meant the metaphor to be extended to agile teams and most importantly to those playing servant leader roles. How can servant leaders make themselves indispensable? Shouldn’t they be striving for dispensable? Another problem with indispensable occurs in organizations that are still using last century’s matrix management approach to teams.
Anthony: Well yes, servant leaders should be striving to be dispensable if they want to get promoted. Otherwise, they could be stuck in the same job for ten or fifteen years while others are promoted around them. But I like Seth and what he has to say so I am not going to blame him for it.
The question I have for you is what can be done about it? Let’s say you are a Scrum Master and you are reading this and thinking, wow, this is me. What would you recommend that they do to avoid being a Problem Scrum Master?
Tom: Make sure you have a buddy for each of your roles. Pair people up, rotate who is facilitating events (I hate the word ceremonies), and in some cases write down, or video how to do certain things. In short, ensure you are not the knowledge bottleneck.
Anthony: That works for the Scrum Master who is trying not to be the problem. I think as a Scrum Master you could also practice being quiet at a meeting like the daily Scrum – or monitoring how much you speak up in each meeting vs. just listening and letting others speak up. IMHO many Scrum Masters get too involved in meetings and they speak way too much and that is a problem. They don’t leave space for the team to figure things out. I wrote a blog saying the Scrum Masters need to be good listeners.
What if you are a coach, leader in an organization, or even a member of a team and you see a problem with Scrum Masters and teams behaving this way – what do you do? Would you recommend printing this article, framing it, and sending it to the errant Scrum Master?
Tom: As a coach, and almost all roles have some degree of coaching embedded, our role is to help people recognize when there is a risk and to help them find a path to mitigating the risk. Printing and framing copy might not elicit the best reaction. Start with a conversation and then consider asking them to read it. I have recently used a retrospective to highlight a potential issue.
On a cautionary note, if a team is about to put their hand in the proverbial running garbage disposal – for example, the Scrum Master or someone else with specific information is about to leave – then more direct action might be required.
Anthony: Are there any situations where you feel like being the puzzle piece or the linchpin is warranted?
Tom: At an individual level, heck yes. It is a way to ensure employment safety for a period of time and increase your bargaining power. But not for a team or organization – having all your eggs in one basket is risky.
Anthony: Any other recommendations?
Tom: Transactive memory is useful until it isn’t and you forget your father’s birthday. Add identifying your skill and knowledge gaps to a retrospective or two. Let’s all remember that T-Shaped people can support each other.
Anthony: Great coaching Tom! Thanks for your insights and for taking the time to explore this issue.
As usual, I enjoyed your work on this article. And need to apologize for the delay in posting this thought. The clever debate on “indispensable” scrum leaders brought up a justifiable perspective, and even a whole new way of working the topic.
As Tom suggests, perhaps the scrum leader becomes indispensable by being dispensable. That is, by being a model for the organization that the scrum / sprint / increment / process is not the purpose… it’s the product… the value to the organization. Because this is or was my understanding of the topic of the whole idea that the scrum master could be the problem.
I currently advise a program of some 400 MEUR with eighteen teams working in dependency with another score of teams in four other multi-agile programs. The major impediment in these teams is the tendency for scrum masters to insist on conformity to their perception of their own team’s scrum rules, and to foster smoldering resentment at the intrusion of coaching and program management into their autonomy. In general, the scrum masters’ view of the product ends at their team’s deliverable, and their idea of rules about how agile should work.
In keeping with your point that scrum masters should lead by serving rather than impeding, IMO ours is clearly a case where The Scrum Masters May Be The Problem. We are currently struggling with how to inspire a cross-organizational product vision in these scrum masters (who, in case it is indicative, chose to call themselves Agile Masters) without de-railing the healthier aspects of their agile mindset. In keeping with one of your recent favorite authors, General McChrystal, it is our hope that we can subtly remind of good training in a disciplined agile context, and celebrate good models.