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". SpiderOak doesn't quite follow the "What Works" philosophy; we instead focus on "What Works NOW".
The upside is that as our company grows and changes, we alter our processes to best suit our current needs. The downside is that this puts us in a state of constant evolution. Sure, it can be uncomfortable not to rely on processes and structures to stay solid underneath you. 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.
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. 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.
Creating the Scrum Master (lite) role
In our first experiment with rotating Scrum Masters (lite), we were focused on reducing dependence on me. 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.
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. This changed the goal and urgency of getting the rest of the company up to speed with how we plan sprints. 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.
Who can be a Scrum Master?
The first people we got in on the Scrum Master script were our developers. After all, the majority of work being planned in traditional sprint fashion was theirs. It worked beautifully. 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. 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.
Having the developers fill a rotating Scrum Master role was extremely beneficial in reducing the possibility of a single point of failure. 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). 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. 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:
Sprint 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. They need to leave the meeting with a clear understanding of what the team is progressing towards, and the development team needs to leave the meeting with a clear understanding of what these stakeholders need as well. As an example, if design anticipates their work will need review during the sprint, development would be well served conserving some of their capacity to make sure they have the time to provide that review.
Pointing
We've discussed before how Retrospectives are the most critical part of a Sprint Planning meeting. This is because they are our most consistent tool for finding ways to change processes that are no longer working for us. One of the things we found was that while we understood a need to adjust points for vacations, new hires, and other interruptive scheduling concerns, we did not have a clear system for how to do so. We eventually decided that because we want fluidity between our squads, we want estimation to happen in a consistent way. This consistency, for us, extends to the ability for all employees within a discipline to understand level of effort in the same way. We adjusted our script again to address how pointing should work when skill levels are uneven, as in the case of a new hire or an employee taking on new responsibilities.
Please note that our preferred method of dealing with this at SpiderOak is not to adjust a ticket's level-of-effort estimation, but instead to adjust the individual contributor's total capacity estimation.
By way of example, if we expect that a person can put out, on average, 5 points of effort per week, or 1 point per day, a new hire on a team might take 2 or 3 points per week while they are getting up to speed to account for how much time is spent onboarding and learning.
Order of Operations
Another place we found room for improvement was in how we addressed pointing. In our earliest sprint planning iteration, we looked exclusively at points across the team. We figured, we're planning as a team and it's the team's responsibility to achieve sprint goals, so the numbers should guide us.
In reality, many teams have members who specialize in certain tasks. (I'll leave the pitfalls there to another post and just accept this as sometimes unavoidable - at least temporarily - for now.) Many teams also have work that blocks their team members or even other squads. We adjusted our policy to include the following:
Once the team wide number makes sense, each individual's points need to be quickly recapped to make sure the overall workload is even. This is especially important if there are any specialized tasks that MUST be taken by a certain team member for any reason. If the team math is correct, but when you break it down you realize one person is responsible for 80% of the work, that should be explicitly addressed. You are working as a group to achieve the sprint goals.
We're also taking steps to account for how a ticket's priority increases within a sprint when it is part of a dependency.
What's next?
We're firm believers that processes and expectations should be re-evaluated as needed, and a year from now this document may no longer serve us. When a process or document no longer serves its purpose, we archive it so that it can be referenced, learned from, or resuscitated as the need arises without distracting us in our day-to-day. As long as we can keep focusing on what works now and re-evaluting whether all processes are still working, we hope to avoid stagnancy and to be able to course-correct as needed.
Related Reading
If you'd like to read more about sprint planning, there are a number of great articles at your disposal. Atlassian and Scrum.org are friendly places to start.
https://www.scrum.org/pathway/scrum-master
https://www.atlassian.com/agile/scrum/sprint-planning
