The Mozaic Works coaches have many conversations with people who have burning questions about Scrum, either in community or during trainings. We’ve decided to start answering the most common ones in a series of “Burning Questions” blog posts. This blog post is the first.
1. How do I convince my team to buy into Scrum?
This is a question I often hear from ScrumMasters appointed by management “to implement the Scrum process”. Developers are usually weary of management initiatives so the poor ScrumMaster finds herself between a rock and a hard place.
Before I tell you what you could do, let me start by saying what not to do. Don’t try to intimidate the team into submission. “We must hold the Daily Scrum, it’s the process.” Good luck convincing the senior developer with a line like that. Engineers are some of the most pragmatic people I know, so you need to find a different approach.
Instead, make sure you understand the intent of every practice. For instance, what’s the purpose of the Daily Scrum? To align the development team, surface impediments etc. Now take a look at your stand-up. Is it achieving those goals? Why not? What can you do to improve it? Perhaps you need to facilitate it better, by parking the technical discussions. Or maybe you need to ask better questions. What about the Sprint Planning? The Backlog Refinement? How can you facilitate them differently so that they benefit the team, instead of wasting their time?
2. How do I estimate stories with a lot of research?
Some stories are familiar. You’ve done something similar before, so it’s easy to estimate them. But others mean wrestling with new technologies or business domains. How many days should you estimate for implementing them? 4 hours, 4 weeks or 4 months?
What if you didn’t estimate them at all? Take that story and split it into two: research and development. Add a research story for this sprint. This is often called a spike. Once you’ve finished the spike and understood the implications, create a new development story and add it to the backlog. The Product Owner will usually plan it for the next sprint.
3. How can I make sure we execute the retrospective action items?
The simplest thing I can think of is adding the action items to the Sprint Backlog. But some Product Owners tends to push these stories out of the Sprint Backlog. At this point, as a ScrumMaster you put on your performance guardian hat. The retrospective actions are supposed to improve the team’s output, so deferring them is unwise in the long run.
Negotiate with the Product Owner. Agree on a certain percentage of the team’s capacity that will be dedicated to tasks like reducing the build time, learning more about unit testing or refactoring that module which causes most of the bugs. For a team of seven, aim for 1-2 man days per week which can be invested in continuous improvement.
Do you have questions about Scrum? Let us know in the comments, and we will answer them in future materials.
Photo sources: https://gadflyonthewallblog.files.wordpress.com/2014/09/burning-question-mark.jpg, http://www.vumc.com/27576/7086114/7086164/Homepagecarroussel-research1.jpg, http://www.akashb.com/blog/wp-content/uploads/2012/08/Slide1.jpg,