Swarming is a whole new way of getting work done on a team. Instead of taking a “step-by-step” approach to something (which frequently leads to hand offs and inherent loss of continuity and information), teams that “swarm” on backlog items approach items from a “multi-vectored” standpoint — whatever needs to be done is done by whomever needs to do it and at pretty much the same time.
Why Does Swarming Work?
Swarming works because it exposes all of the complexity of the backlog item at the same time. Problems that, in more traditional approaches would surface near the end of the work, now tend to appear in the first few hours of work. Also, teams that swarm form “collaborative information networks,” or CINs. CINs tend to cause the rapid learning and sharing of information across the team, and leads to quick improvements in team performance.
What is Necessary For Swarming to Work?
For swarming to work, the team needs to do the following:
- Backlog Refinement — backlog items committed into the Sprint cannot be larger than what the team can complete in three days of work. Larger than this introduces unnecessary and disruptive complexity.
- Be Willing to Work Outside Your Comfort Zone — sometimes the task that you need to work on isn’t your speciality (e.g., writing or testing or editing).
- Be Willing to Work Together — swarming works best when developers work together on one or more tasks.
- Don’t Pre-Assign Tasks — predicting ahead of time who should work on what task is like predicting the weather. You might be right, but the further out you predict the more wrong you’re going to be. Let developers self-assign tasks when they’re ready.
- Limit Your Work in Process (WIP) — working on more than one or two items at the same time eliminates any benefit swarming can provide. Don’t spread the wealth — reduce overall risk, waste, and complexity by only allowing one or two backlog items to be in progress at the same time.
More About #Productivity
Sprint Goals – How a Small Thing Makes a BIG Difference
Are you looking for ways to motivate your team and keep them on track? In this webinar recording, learn how setting sprint goals can help your team stay organized and focused on a project. Sprint goals are short-term objectives that teams set so they can achieve longer-term project goals. In this webinar recording we cover topics like strategies for choosing the right sprint goals and how to measure progress and stay on track. This recording will offer practical advice that you can apply directly to your own workplace.
Avoiding the To-Do List Trap #AskArtisan
Ready for a chance of pace? This #AskArtisan video doesn't talk about Scrum or Agile, but YOU and your state of mind, productivity, and time management!
How Should a Scrum Team Handle Defects in a Sprint? #AskArtisan
Even ScrumMasters who follow #AskArtisan videos will encounter Unplanned Defects, which are critical to address immediately and can be challenging to deal with!
How Do I Choose Sprint Length? #AskArtisan
How do ScrumMasters set the length of a Sprint? It’s a trick question - Sprint length is determined by the entire Scrum Team! Why and how? Glad you asked!
Should I Lengthen a Sprint to Get More Done? #AskArtisan
As a ScrumMaster, have you ever been close to the end of a Sprint and realized that there's more work left than time? Oh no! Should you increase Sprint length?
How Many Teams Should a Product Owner Have? #AskArtisan
How many Scrum Teams should a Product Owner (CSPO) work with at once? The Scrum Guide is very clear, so in this #AskArtisan video, let's sort it out!
How Many Teams Should a ScrumMaster Have? #AskArtisan
ScrumMasters with more than one Scrum Team have a few things to look out for to ensure their multi-tasking isn't affecting the team's effectiveness.
How Long Should Sprint Planning Take? #AskArtisan
How long should it take to plan a Sprint? In this #AskArtisan video, I’ll explain what is and isn't important for your Sprint Goal.
Sprint Goals: Why the Plan Matters Less Than You Might Think
This information will help you take a BIG step toward having product dev, service, and support teams be self-managing. (Yes, really!)
Leave A Comment