4 Ways to Overcome Past Scrum Failures
When it comes time to begin their Scrum journey, many teams come with baggage. I often hear, “We tried that, and it didn’t work.” They may have “tried” Scrum before and “it didn’t work.” They may feel Scrum is yet another management fad.
Like unhappy families, team members may come from other teams that failed for different reasons. Here are some ideas a Scrum Master can use to help their new team overcome past Scrum failures. Through positive experience, help your team give Scrum another, successful try:
- Lead with empathy. Listen to your team. Learn what didn’t work before and what they most need now. Try to help them address the problem applying Scrum methods. You may have diagnosed different issues with a Scrum lens, but that can wait.
- Lean into exceptionalism. The things holding your team back aren’t unique, but who wants to be told that? Accept and work into their excuses. You can also build credibility by championing adjustments that use more common sense and are less rule focused.
- Celebrate transparency before results. High achieving individuals are accustomed to striving for the great report card. Your job as Scrum Master is to decouple that dopamine hit from story points and attach it to the act of finding the baseline and ownership.
- Stick with basic principles. Scrum done well has any number of tools, and a Scrum Master should be aware of all of them. With a new or resistant team, focus on the key few that suit your style. For me, that is keeping Daily Standup short and effective, holding a regular Retrospective, and striving for predictable delivery. Other things, even scrumly rituals like sizing, may fall away. The team will discover them anew as they build trust.
I started working with one of my favorite Scrum teams six months ago. They were reluctant to try Scrum because it had been presented as an all or nothing scheme that would add overhead to existing business processes. Some had been burned by personal experience.
At our Director’s urging, they agreed to try Scrum but admonished me to keep it lightweight. Two weeks later, a reorganization placed them under new management, reducing higher level support for Scrum. The team was at a project phase with high scrutiny where work was driven by urgent issues. The engineers were experts assigned to specific areas and rarely worked across those boundaries. It was an inauspicious time to demonstrate the value of Scrum. Luckily, the front-line manager decided to give it a try anyway.
I charged in with the religious zeal of a Certified Scrum Master confident of winning more converts. After three months, the team remained highly siloed. The Accept/Commit Ratio hovered around 50%. Overall velocity was stubbornly flat. I expected to see the experiment called off.
However, the team understood what they were up against. They helped me coach them. I learned about their challenges with deadlines and validation requirements, and about the mix of skills in the team (empathy). Their company-mandated ticket system was poorly adapted to Scrum. Rather than do data entry in another system, they found a way to make it work, and I built a manual dashboard (exceptionalism). We focused on seeing and improving the trend in our improvised Scrum board through anecdotes of improved focus and collaboration (transparency). I kept my promise to keep it lightweight and they readily bought into having regular Daily Standups and Retrospectives (basic principles).
Over time, they developed improvements in tracking on their homemade system and in Backlog Grooming. They found ways to share work fairly across projects. They engaged their validation team and internal customers as a part of the Scrum process.
After more than a dozen Sprints, the team has hit a groove. Their Accept/Commit Ratio approaches 90%, and they are developing a discipline to baseline and address their interrupt rate. What’s more, they have maintained their Scrum practice while rapidly adjusting to working virtually in a coronavirus world. They are now a team that says, “It works for us.”
Emily Hackett
Emily Hackett
http://www.linkedin.com/in/mlehackett/
Emily is a Technical Program Manager working with the Performance Architecture and Analysis team at Intel. She has been a Scrum Master since 2016 and has also worked as a Release Train Engineer (RTE) in a Scaled Agile Framework (SAFe) organization and as a functional manager for a highly effective Scrum team. Opinions presented are her own.