Dear Scrum Helpline,
We’ve currently hit a problem with the idea of ‘swarming’ which the Agile Coach installed for us.
A developer finished their work and became idle, but because we were not allowed to introduce any more tickets into the sprint, there weren’t any tickets that suited their skillset.
Instead, she was essentially told to help other developers, even though no one needed help. Situations sometimes get emotionally charged, so the developer just ‘made themselves appear busy’ for a bit, at least until the next planning checkpoint.
I had tried explaining this would happen, but I wasn’t listened to and it wasn’t even me complaining.
Response by Jeremy Randall, Scrum Master:
Hello Friend,
So your Agile Coach is onto something good, but could use a little help in execution.
First off, swarming is a great practice. The intention here is to move items that have been started to done faster, instead of letting them languish with fewer people than needed to complete them.
There are many good ways to swarm. Think pair programming, mob programming, or even just slicing and dicing your PBIs to allow more people to work in parallel. If your team is trying to swarm, don’t discount any versions of it, because having different ways to swarm will be useful in different situations.
When we swarm work, we are able to produce useful value faster, and then get feedback from users and/or other stakeholders more quickly. Imagine you have 3 developers and 3 valuable user stories that need to get done. Each item is estimated to take about 9 days of total work, so if you give one item to each dev, you think you could get them all done within a 2-week sprint. But what if they all wind up just a little more complex than we thought? Let’s say they each actually need 12 days of work. We’ll make it to the end of the Sprint with nothing to deliver, and we won’t have capitalized on an opportunity to get feedback.
But if we instead find ways to split the work among the developers and have them all focus on the same item, then you can make more meaningful progress. If we were able to roughly have each developer work for 4 days on US 1, then 4 days on US 2, then 4 days on US 3, then the team would still have them all complete after 12 daysโฆ but the first one was done in 4 days, and the second one in 8. We’re delivering 2/3 of the user stories by the end of the Sprint.
This has the additional benefit of reducing the negative effect of an inaccurate estimate – and we all know estimating work is hard!
Next, a couple of notes for your Agile Coach.
Since you used the word “installing” it sounds like you feel swarming was forced on the team rather than accepted by it. I’d urge your coach to involve the team more in adopting new methods, and to think of them as experiments. A good explanation of the potential benefits of a new practice, and a conversation about different ways the team can think of that might help achieve these benefits, will go a long way to help with team adoption.
There’s also the issue of not being able to add more work to your Sprint Backlog. This isn’t actually a rule from Scrum, so if it’s one that your team has adopted, then it might be a good time to talk about whether that’s still working for you, and change it if it is not. Maybe in your next Retro?
And now a last bit for your specific situation. You have a developer who is specialized in one area, and the remaining work doesn’t align with their speciality, so they didn’t feel like there was a way for them to swarm.
I would suggest this is a good moment to visit the idea of the T-shaped developer. All developers are T-shaped to some degree, which means that they have one area of specialty (the trunk of the T) and some other skills that are less developed (the hat of the T).
While your developer may think of themselves as, for example, a purely frontend developer, and the work that needs to be done is backend work, that doesn’t mean they can’t help. If they have any amount of backend experience, they could still take some of the work and make progress even if it’s at a slower pace.
They could also join another developer who is doing the work to pair program with them. Their ideas and knowledge of data structures and design patterns could still be useful. At the very least, pair programming with someone usually fast-tracks or completely eliminates the need for an extensive PR review, since you’ve watched them code the whole time.
And even if the extra developer doesn’t find themselves contributing much to the development while pair programming, they should be learning a lot, which will help to make their T wider and/or taller. This way, the next time they’re in a similar situation and want to swarm to help out, they might have picked up some new skills that will be applicable.
Thanks for writing in!