8/15/2023 0 Comments Spideroak syndication processSprint planning meetings are attended by the entire squad – not just the development team, but the cross-disciplinary group of representatives impacted in some way by the progress of the team. Note that at no point was this impression cultivated on purpose, but it isn't a huge leap to think something along the lines of, "OK, only technical staff run the meeting so this must be a technical meeting and I should spin up another one if I have questions related to Design." On realizing this, we stepped up our efforts to actively solicit Scrum Masters from all departments and we made it more clear in our script what the intended scope of Sprint Planning meetings was: It unfortunately had a side effect of perpetuating a perception that sprint planning was for the developers' sake, and that the squad calls should be focused mainly on technical conversation. It also helped us to hone our script so that it was accurate, useful, and easily understandable by a variety of learners (pro-tip: clarifying screenshots are more than a nice-to-have). 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".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |