When a Scrum Master joins a team, there’s so much to do. It’s daunting and sometimes a bit overwhelming. We have so many questions! Where’s the team need our help? Are they entrenched in how they operate or open to change? How do they interact with each other? How receptive are they to me, their new Scrum Master? Today, I’d like to explain one approach that I’ve find successful, and it all begins with a conversation.
In my previous blog post, I talked about how I believe a Scrum Master should be trying to put him or herself out of a job. Put another way, we should master the art of actively doing nothing. Some agreed; some didn’t. Some thought the language was too strong. Others thought it was just right. However, let’s put the debate aside for the moment and discuss what it means. How can a Scrum Master hand his or her responsibilities to the team? What responsibilities? When should this begin? First, let’s start with why. Why should a Scrum Master want to hand responsibility for the team to the team:
- To allow additional time to address organizational impediments.
- To cultivate an environment where team members are responsible and accountable to one another.
- To minimize the bus factor and create T-shaped people within the team.
As far as when, I think LeSS illustrates it best in this graph. At first, a Scrum Master spends a great deal of time with the team and Product Owner. However, as the team matures, he or she peels away to assist the organization in other ways. To read more about how LeSS views the Scrum Master role, click here and here.
Much of the role of the Scrum Master is intangible. We don’t write elegant code, we don’t craft beautiful designs, and we better not be creating Gantt charts. Instead, we’re masters at soft skills, but how can such a thing be quantified? And if not quantified, how can I know if I’m a good Scrum Master? How can I honestly assess myself in the spirit of continuous improvement? With respect to a Scrum Master’s service to a team, it begins by asking six questions.
I was happy to hear that many of you enjoyed the Product Owner tips I offered in my previous blog post so I thought I’d jot down a couple more today. If you’d like to read my previous Product Owner tips, you can find it here. So let’s get to it.
I spent several years working in the gaming industry, and it was from a Product Owner there that I learned an odd but effective prioritization technique. At the end of sprint planning, he’d point to the sprint backlog and say, “See that story on top? That’s the only thing I’m concerned that gets done this sprint. Nothing else.” After a day or two, that story would be done, and at the next stand up, he’s point to the sprint backlog and say, “Great work! Now see that top story? That’s the only thing I’m concerned that gets done this sprint. Nothing else.”