I realized that the team was not taking ownership of the work. I was. I had to let go.
Letting Go of Control and Embracing Open Questions
Mark Kilby, Rally
Since 1999, I had been experimenting with Extreme Programming practices in various organizations. I wanted to provide a better professional life for myself and the teams I led as I typically had roles of project lead, architect or project manager. The promises of agile about sustainable pace and synergistic disciplines that maintained high quality and morale resonated with what I valued.
A few years later, the company I was working for decided to implement Scrum. I quickly recognized the similarities to XP project management practices and jumped at the opportunity to become one of their first ScrumMasters. It was also an easy transition (so I thought) as I had been working with my current team to implement a guerilla version of XP with great success over the past year. I was ready to bring quality to our products. I was ready to help build better relationships between business, customers, and delivery teams. I was ready to join the revolution! I was ready to become… a sheepdog?
In the Certified ScrumMaster training with Ken Schwaber in March 2005, Ken emphasized the role of ScrumMaster as a sheepdog that is there to protect the team from the wolves of distraction and guide it only when necessary. I had always taken on a mentoring role with teams, so I quickly identified with the sheepdog metaphor. I could protect the team! I could herd them too when they got into the woods. Little did I realize I would get into the woods myself.
I also had a few challenges in my new role. The majority of the team was one thousand miles away and I was co-located with only one team member. This introduced many interrupts to the remote part of the team through frequent drive-by requests from other managers and teams. They were rarely quick and I could easily lose a remote team member for hours or days on these drive-bys. A second issue was that the Product Owner was frequently on the road meeting with clients. So he was rarely accessible to the team for questions on stories in progress or planning meetings. Prioritizing the backlog of work was also challenging.
We continued to struggle to make agile work and I was deep in the struggle. When the going got tough and pressure was on to complete sprint commitments, I found myself driving the tasking of the sprint backlog and “strongly suggesting” next steps to the team. I felt it was necessary for me to guide the team out of the woods. Still, the team was not able to complete all their commitments for a sprint. They were looking to me to guide them to success.
Was agile just not working for us or were we just not getting it? Was I not getting it? I was trying to protect the team, but at the same time I wanted to herd them along the right path. I knew what the path was… or so I thought. I wanted to be the facilitator and the leader. I wanted to be the sheepdog and the manager. At best, I was a dislocated, schizophrenic sheepdog for my distributed team.
It was at this point in my struggles that I remembered two very important phases from my ScrumMaster training: “Scrum does not solve your problems, it only makes them highly visible” and “If an issue is causing you a headache, it may not be your problem to solve”. This set off many light bulbs for me. I realized that the team was not taking ownership of the work. I was. I had to let go. I had to have them stop looking to me for answers. They needed to rely on each other. This also meant I should stop trying to run the sprint backlog.
So I closed my eyes and let go. Team members would come up to me to ask what to do next. The open question of “What do you think?” was my new response. This resulted in some puzzled looks and a couple of responses like “Aren’t you the manager?” My other response would be “No, I’m the ScrumMaster. I’m here to get obstacles out of your way. The team is here to plan and do the work.” It took a few weeks, but light bulbs started going off for the team as well, but not all of them. Some were becoming annoyed, but I used this as teachable moments about self-managed teams. By letting go control of the backlog, it also freed me up to deal with some of the drive-by requests and get the team more focused. This helped a few other light bulbs go off for the team on the advantages of being self-managed and having a ScrumMaster to protect them.
The moment of truth came with one critical sprint review. Attending were senior managers and many other stakeholders anxious to find out (1) status of the upcoming critical delivery and (2) how was this “Scrum thing” working? The team was also anxious … and demoralized. The impediments of the past sprint had become insurmountable for the team and very few stories were completed. They were unable to get the information needed to integrate with other systems the customer required. The review became tense as the audience asked “Why were the stories not done?”
What was in our favor is that Ken Schwaber was there as he had been consulting for the company. Ken had been quiet the entire review until the “done” questions were asked. Then he started asking some open questions such as “What were the impediments?” A series of light bulbs went off for me as I remembered the power of asking open questions and I began asking a few of my own such as “Did the team have all the information needed for the story?” and “Was the business or customer available daily to answer questions?”
The answers to these questions allowed our stakeholders to realize that the entire team had a headache and it was an issue that only the stakeholders could resolve. The review shifted from highly tense to highly focused and the stakeholders resolved to reprioritize the backlog immediately and provide new communications opportunities for the team to get the feedback they needed from the customers as often as possible. That day, the light bulbs went off for team members and stakeholders alike that learning can sometimes be painful, but it is always valuable.