Lots of carryover? Try swarming

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

This entry was posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology. Bookmark the permalink.

4 Responses to Lots of carryover? Try swarming

  1. Exactly what I teach my students to do in EECS 394 at Northwestern for just the reasons you give, plus the learning benefits that result. But I get the feeling that this is a practice even less done commercially than TDD. Have you seen this done much?

    • Susan Evans says:

      Actually Chris, I do see swarming in practice but not consistently, which unlike TDD is ok. I’ve encountered teams who tried it and uncovered root causes that contributed toward a failed sprint. They then put all of their energy into correcting that behavior and less on swarming. On the other hand, some teams find that swarming solves their carry over problem so they stick with it.

  2. Steven Wadley says:

    I’ve found swarming to be invaluable, with the main challenge often being trying to split stories in a way that permit shared development. This has led us to a balanced approach to swarming – which is basically to apply swarming on the top story until more hands would be counter productive. Those additional hands will swarm the second top back log item, again not to the point where it is detrimental, and any available devs will look at the third one, and so on. Once you start applying this, you will notice dynamics coming to the fore where particularly versatile or senior developers might not ever “Own” their own story, but swarm those “Owned” by others, with “Ownership” moving to a sprint backlog focus. I have found it not uncommon for developers to prefer not to swarm, simply for the pure selfish joy of delivery. That can be accounted for also most of the time with a balanced approach to swarming.

    • Susan Evans says:

      Thank you for your comment Steven and great explanation of a balanced approach to swarming. I agree that it could be wasteful to strictly swarm one story at a time. It takes a mindful Scrum Master and team committed to the approach to find the right balance to swarming while limiting work in progress. It’s fun watching the dynamics of a team change when they start working together instead of in their silos. Just one step in the evolution to become a high performing team.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>