Room 12A
As a new ScrumMaster, I spent more time than I’d like to acknowledge stuck in room 12A, having the Monty Python argument sketch about what is and isn’t Scrum.
“No it isn’t!” “Yes it is!” “No it isn’t!”
(Do an online search for “Monty Python Argument Clinic sketch” if you’ve no idea what I’m referencing)
It’s fairly easy to fall into this sort of “automatic gainsaying” dynamic.
Fortunately for my teams I learned to recognize this trap in the forming stage. That allowed me to shift the discussion to a deeper level quickly.
I’d love to share a lightly fictionalized coaching moment with you to demonstrate the trap and how to escape it.
Act 1, Scene 1
New ScrumMaster (NSM) enters through door stage right, sits down opposite Coach, already seated.
NSM – “My Product Owner is driving me crazy, they keep doing it all wrong!”
Coach – “Say more.”
NSM – “Like this week, they came in and said ‘Cancel the grooming meeting for Monday. And I need you to schedule a hack for the team this Thursday so they can look at TheNewHotThing that’s up next sprint. And bring SUX-1543 onto the sprint because Amir doesn’t have enough to do.’”
Coach – “I’m not a fan of how all that sounds. What happened when you tried to hold boundaries for the team and their agreed process?”
NSM – “I told the PO that they were breaking Scrum rules. It turned into a lot of “scrum/not scrum” back and forth. They said the team would never succeed if I wasn’t going to be flexible. “I’m the PO, sometimes the team just has to do what I say they need to do.”
Coach – “Not a fan of that, especially. I’d like to put critique of the PO aside for now. Let’s focus on ways this might have turned out differently. Is that good with you?”
Act 1, Scene 2
NSM – “Sure, I’d love to know what I did wrong.”
Coach – “I’d prefer not to frame things as ‘wrong’ here. You had a purpose in trying to push back, and what you tried didn’t give the result you wanted. Tell me about that purpose, why did you feel like you wanted to speak out?”
NSM – “What the PO was doing was wrong.”
Coach – “Wrong how?”
NSM – “It’s not how the Scrum Guide says it’s supposed to work.”
Coach – “Consider that by invalidating the PO’s actions and calling them wrong. Then you asserted that the Scrum Guide is “the right way.” Why do you think you got an argument about rules?”
NSM – “Yeah, but what else should I do? Don’t you think that’s wrong?”
Coach – “I do see those actions as not in line with the Scrum Guide. I see those actions as undercutting much of the value that choosing to follow Scrum provides. That brings up two paths I feel are more powerful to discuss – agreements, and value.”
NSM – “You mentioned agreed process before, what did you mean by that?”
Coach – “The team, including the Product Owner, agreed to use and follow Scrum. The PO is breaking that agreement in multiple ways – adding scope to the sprint, allocating work to team members, changing schedules and adding disruptive requests like the hack. They’re also “scheduling” and “managing” the team members, not letting them work as they see best.
“When people break agreements, they often know it. And do it anyway in pursuit of something they think they cannot have by keeping the agreement. So they’re defensive when called on it. They’re primed to avoid owning the break by diverting into an inconclusive back and forth. Which sounds like what happened for you.
“Rather than get caught up in a loop over defining Scrum, move the discussion to the broken agreements. Be curious about why they felt breaking agreements was necessary or beneficial.
“This brings up the other part you can approach – value. If you provide genuine curiosity about the value they were seeking in breaking agreements, it’s more likely that they’ll hear to you when you share the value that you feel was removed by breaking the agreements. What value or benefit, and who realizes that benefit. Can you tell me what value following Scrum provides in these cases, and who benefits or receives that value?”
NSM – “One of the biggest values of the sprint commitment is focus. The team knows what’s important and how much time they have to spend on that important work. When you add or change that commitment, the focus changes and it becomes likely that nothing gets completed.
“Being supported in self-organization allows the team to work together to complete the committed work to their best collective ability. Adding work because a specific team member “seems” idle disrupts that team flow. Also, it trains the team to go back towards “hub-and-spoke” work styles where they wait to be assigned to tasks, rather than contributing to the success of the team in the best ways they can identify.
“These things make the team more likely to succeed, and thus not only does the team benefit, but so does the PO, the organization, and the customer.”
Coach – “So what do you think would happen if you talked about those benefits and values, as compared to debating the rules of Scrum?”
NSM – “I think it would still likely get defensive, but in a way that we can work through together. Especially if I’m genuinely curious about their reasons for wanting to do what they want to do. And if I’m open to finding ways to help address their needs and wants in ways that don’t remove the values the team is counting on.”
Coach – “Is that something you think you can do? We can do some role-play if you think it would help. Or discuss it more after you’ve had some time to process. And is there anything else you might have thought of as we explored this?”
NSW – “I’d like to try roleplaying it a bit to practice. I think I tend to jump in to right and wrong when I feel rushed.”
Coach – “That sounds good to me. Let’s find a time and we can practice.”
end scene – it’s a one act play
I imagine many ScrumMasters and Agile Coaches (and even Product Owners) have had variations of the moments that were discussed in this coaching situation. Maybe it went better, maybe worse, maybe just different.
What I find important in opportunities like this is to keep the focus on curiosity rather than relying on judgement and evaluation. Judgement and evaluation bring rigidity and compliance. Curiosity holds space for understanding, flexibility, and agreement.
In this situation, the Product Owner did break agreements with the team. By being curious about why they chose to do that, we can gain understanding of what needs the PO feels are not going to be met by keeping the agreement.
With that knowledge, we can then attempt to see what needs we agree as a team we can meet, and how to meet them. We can either find ways to do things that do not break agreements. Or, we can agree that in order to meet the need, we need to temporarily or permanently alter our agreements.
We also create space for the PO to acknowledge the broken agreements, and the opportunity to repair the break and commit to upholding them going forward. If we succumb to judgement, argument, and blame, we create grudging compliance and likely resentment that will undermine agreement in the future.
We also avoid the trap of blind rigidity in our process and our agreements. If we are not curious about circumstances that might merit temporary or permanent change to our agreement, then we miss chances to improve. We also risk creating a space where we begin using the rigidity of the agreements to avoid attempting to innovate or experiment, and to avoid taking risks.
I’ve seen people who practice this sort of strong curiosity in real time, despite being in situations of high tension and stress. It takes awareness, commitment, and practice.
It’s not a magical trait that you’re either born with or not.
You can learn this through reading, then applying to your circumstances, and reflecting on the results you get.
And you can accelerate that learning with a coach.
You can do this. I can help.