POWERFUL QUESTION
Like many trainers, I probably learn more from my students than my students learn from me. When students come hungry to learn, they ask the most thought-provoking questions that take me on treasure hunts that reveal powerful insights. One such treasure hunt began when I was teaching the Scrum.org Professional Scrum Master workshop.
As usual, we began the workshop with an invitation for students to visualize their desired learning outcomes. One of the most thought provoking questions came from Sarah…
“How can the Development Team serve the Scrum Master”
I thought I misheard what she said so I double-checked…
“Did you mean Scrum Master service to the Development Team?”
“No,” Sarah replied, “How can the Development Team serve the Scrum Master?”
No one had ever asked me that question before.
ROLE OF SCRUM MASTER
The Scrum Guide introduces the Scrum Master role as follows:
“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
ROLE OF DEVELOPMENT TEAM
We focus so much on the Scrum Master’s role that we sometimes neglect the role and accountability of the Dev Team. Let’s review how the Scrum Guide introduces the role of the Development Team. I have highlighted two key bullets that I would like us to explore in more depth…
“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”
LIMINAL PHASE
Transitions – William Bridges
In almost every organization that I have helped transition from Waterfall to Scrum, there is a “liminal phase” – a period of ambiguity and disorientation, where the old waterfall culture hasn’t completely died and the new Scrum culture hasn’t yet taken firm roots. The late William Bridges described this phase beautifully in his book – Transitions: Making Sense of Life’s Changes. Until you read the book, you can review a summary of his Transitions model.
POWER VACUUM
One of the most common signs that we have entered this phase is the sign of the power vacuum that is created when we discourage previously assertive roles from using command and control management to direct the team whenever problems occur. Instead, we encourage Development Team members to solve these problems through self-organization.
Sometimes, the Development Team breathes a sigh of relief, glad that they have finally been unshackled and demonstrates their natural ability to self-organize. Sometimes, there is this awkward silence. Not because the Development Team is incapable of self-organization, but because they haven’t practices it for so long, that they have forgotten how to. The muscles have atrophied and must be rehabilitated.
At such times, it is common for the Development Team to go running to the Scrum Master every time there is a problem. If the Scrum Master is not careful, (s)he could now enable a new dysfunctional inter-dependence and become the new command and control “Agile Project Manager”.
“ASK THE TEAM!”
At Scrum.org, Ken Schwaber – the co-creator of Scrum has tried to help us guard against this risk by drilling a quote into the minds of every single trainer and assessment taker – “First, ask the Team.” Each time a Scrum Master jumps into problem solving mode without asking the question – “Am I convinced that the Development Team is incapable of self-organizing to solve this problem?”, (s)he is hammering another nail in the coffin of Development Team self-organization.
CO-ACTIVE MODEL
This belief-system and mental model is aligned with the Co-Active Model created by Karen Kimsey-House and Henry Kimsey-House…
Co-Active Coaching Model
What I find the most inspiring about this model is the belief that “People are Naturally Creative, Resourceful and Whole”. Those who do not share this belief may struggle to enable effective adoption of Scrum.
I had heard about this approach and was only able to learn about it when Scrum.org provided scholarships to Scrum.org Professional Scrum Trainers to attend Lyssa Adkin’s workshop on Coaching Agile Teams. Lyssa taught us to approach Agile Coaching in a way that brings me back to answer my PSM student – Sarah’s question …
“How can the Development Team serve the Scrum Master”
LESSONS FROM LYSSA
Based on what I learned from Lyssa, here is my suggestion to Sarah and all Development Team members on Scrum Teams…
If you would like to find ways to serve your Scrum Master, try this experiment…
Disclaimer: Any valuable wisdom in this approach belongs to Lyssa. All flaws are mine.
Before going to your Scrum Master with a request to solve a problem, please jot down your answers to these 10 questions…
- What am I seeing happening…?
- How is impacting our organization’s desired business outcomes…?
- What would I like to see happen instead?
- What have I tried so far…?
- How did it work out…?
- What is getting in the way…?
- What else might be possible…?
- What help do I need from my Scrum Master…?
- What am I promising to try…?
- How can my Scrum Master help me keep my promise to myself…?
10 QUESTIONS, 1 BELIEF AND 1 GOAL
I am hoping these 10 questions will remind us of our shared belief…
“People are Naturally Creative, Resourceful and Whole”
and help us accomplish our shared goal…
“They (the Development Team in Scrum) are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”
Will you try an experiment and tell me what you learned?
Thank you Sarah!
Comments