What many people don't realize is that the official Scrum Guide is actually very short (19 pages to be precise). A lot of what we do, when we implement Scrum, is supposed to be built on top of that original Guide. But there are so many “gray areas” that are left up to the team to decide. What can they do, within the framework, that gets them to that next level of high-performance and predictable delivery?
Jeff Sutherland, a founder of Scrum, has identified some key patterns he has seen across industries where Scrum is successful. He identified these patterns as "Scrum Enhancers".
Swarming
Yesterday's Weather
Stable Teams
Interrupt Pattern
Daily Clean Code
Scrumming the Scrum
Happiness-metric
I am going to write a series of posts that examines each of these enhancers. Since this is the first in this series, I will start with the one I get the most questions about from from teams: Swarming.
Swarming, in its simplest form, means that the team works collaboratively on items, usually stories, to move them towards completion. It emphasizes the idea that teams should stop focusing on starting work, and switch their sights to finishing work. If every developer picks up a story to work on independently, you suddenly find yourself with a lot of work in progress (WIP) as a team. This limits the ability to help each other out because you are all focused on your own project. Teams that develop this silo way of working, end up missing goals. There isn’t enough time to test everything at the end of the sprint or there is a queue to deploy and too many merge conflicts are discovered. Front-loading your sprint means there will be a hefty debt to pay at the end. Instead, try to work 1-2 stories at a time as a team.
But how do we do this? That is up to the team. The Scrum Guide says nothing about swarming, it is only a pattern recommended by leaders in Scrum.
Try discussing, as a team, how you can get the story to done. Then sub-task it in a way that multiple developers can work on it. If you feel like your process doesn’t allow for multiple developers to work on one story, change the process so you can! Don’t accept a blind “We Can’t”; ask “How can we?”.
Swarming also creates an environment of knowledge sharing. The ability for individuals to learn from each other and develop new skills reduces the risk for potential blockers and bottlenecks. If individuals commit to learning from each other, the team can be confident in picking up any work that is prioritized. It also eliminates the risk of lost knowledge if someone were to leave.
But how do we do this?
Like I said, that is up to the team. What works best for you.
Some recommendations for supporting knowledge sharing is to track blockers due to an individual person not being available. One team, when they encountered a blocker due to silo knowledge, would create a task for knowledge sharing to be brought into a future sprint.
The take-away?
Try Swarming. It has been identified as a healthy habit that enhances Scrum for a team. It causes teams to grow together. And it enables them to deliver higher-quality increments faster.
Comments