Having the developers fill a rotating Scrum Master role was extremely beneficial in reducing the possibility of a single point of failure. This highlighted something that should have already been clear to us: everyone should really understand the metrics we're using to define success and how those metrics are generated.
Talking through the process with more people - who asked detailed and on point questions - clarified how we read our sprint reports and what we can learn from those metrics. After all, the majority of work being planned in traditional sprint fashion was theirs. The first people we got in on the Scrum Master script were our developers. It was no longer only about making sure we didn't have a single point of failure it was a way to foster open dialogue. This changed the goal and urgency of getting the rest of the company up to speed with how we plan sprints. What we actually found is that when everyone understands not only how planning works but also how we interpret sprint metrics, what it’s like to lead a meeting, and, yes, how awkward it can feel if a question is met with silence, we gain increased understanding and engagement across our squads. As the only Project Manager, we were worried that vacations or sick days might delay our ability to plan appropriately if I was the only person with permissions and comfort leading sprint planning meetings. In our first experiment with rotating Scrum Masters (lite), we were focused on reducing dependence on me. The following discussion touches back on that document as an illustration of how we build process change into our process itself by highlighting a few tweaks we've made since the original posting. If you've been following the blog, you'll remember the Sprint Manager Script discussion in an earlier article based on an internal document Tomás Touceda and I worked on together. However, making sure your processes actually serve your needs on an ongoing basis is one of your best weapons against creeping bureaucracy in your organization. Sure, it can be uncomfortable not to rely on processes and structures to stay solid underneath you. The downside is that this puts us in a state of constant evolution. The upside is that as our company grows and changes, we alter our processes to best suit our current needs. SpiderOak doesn't quite follow the "What Works" philosophy we instead focus on "What Works NOW". I find a lot of articles, blog posts, and books explaining the process and structure of a given company, and presenting it as "What Works".