Skip to main content
 
us

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page


INSIGHTS / Articles

Agile Swarming: What’s the Buzz?

 20 Sep 2021 
Meet Mike: A consultant in the fast lane Meet Mike: A consultant in the fast lane
Meet Mike: A consultant in the fast lane
INSIGHTS / Articles

Agile Swarming: What’s the Buzz?

 20 Sep 2021 

A queen bee lays a lot of eggs in the leadup to the summer. When the bees are born all at once, the colony overpopulates. When this happens, they need more space, and they need it now!

This is a time when bees typically “swarm” - when they work together to create a new, fit for purpose hive in a very short amount of time. To the outsider, a swarm may seem scary and intense – so many individual bees working on top of each other for a single purpose.

But what is happening is well-planned and efficient, since each bee is doing its part toward achieving the one specific goal. So bee swarming becomes a critical and captivating task that keeps the colony alive and enables continual species growth.

What does a bee swarm have to do with Agile?

To me, the bee swarm sounds like an Agile team I’d like to be on because:

  • A bee colony works as a larger, coordinated team
  • They work toward a specific, short-term goal
  • There is no individual glory in the swarm, and it is all about the outcome
  • All bees are committed to the cause

But does it work like this in an Agile team? Not all the time.

We have all experienced the same steps: we pat ourselves on the back for the Sprint’s velocity until we look at the board. Despite all the progress, we realise so little has been done.

We also realise that we could have shipped one, two, or more features. So we promise to “not do that again”, only to do that again, and again, and again.

Despite all the effort and energy that went into the Sprint, we did not end up with what was needed to meet the actual Sprint goal. In some cases, the teams did not even set a Sprint goal, which means they have no common outcome to focus on.

Instead, we can swarm, working together to deliver the most we can by the Sprint’s end. By tackling the stories with the highest business value first, we can provide the customer with the greatest benefit early.

When a Sprint team can benefit from swarming

  • There are team members who regularly sit idle, waiting for a hand-off from others
  • Retrospectives often see multiple in-progress stories carrying over to the next Sprint (especially across multiple features), so there are no limits to the work in progress
  • Team members that are increasingly working alone and collaborate less

How to adopt swarming in our teams

We ourselves can become strong advocates for swarming. As testing specialists, we dislike being left until the end of the Sprint.

This is especially true when we raise a defect, calling people back to the task that was, for all intents, completed. Add in the possibility that this will leave the story incomplete at Sprint’s end, and it is not a nice place to be.

An all-in swarming Sprint culture can alleviate this uncomfortable situation. It also builds in quality and collaboration across a team.

Here are some practices can we adopt for our Agile teams:

Fewer in-progress stories than team members

To really go all-in on a story, we need to be goal and not task focused. At any one time, there should be significantly fewer stories in progress than there are team members.

Sprint planning is the foundation. Here the stories are prioritised and, as many team members as practical, commit to tasks and start immediately.

Work is focused on this priority story until it is done. Then we move on to the next one.

Testing starts straight away

Testers that sit idle are not effective. By getting involved in the story straight away, testing is continuous throughout the Sprint.

Testers and developers can sit together to pair during development. There is much to gain from being there when the code or product is created, plus the tester can share what and how they will test the story, which could shift some of the testing “left” and build in testability.

Blocked story? Don't replace it - unblock it instead!

A blocked story is still a priority, so re-swarm to do what it takes to get it unblocked. The priority is unblocking it so it can be done by Sprint’s end.

If it is a defect that blocks it, do not put the defect into the backlog. Instead, the swarm stays with the story and works on the defect.

Defects from started stories get fixed before new stories get brought in. The team could also bring in the business to look at the defects and possibly decide that some defects do not need to be fixed if they are of low severity.

Depending on the nature of the blockage, a slight rearrangement of team members might be needed. However, task switching can undermine the benefits of swarming, so do not jump ship too quickly.

Instead, talk to your Scrum Master about the cost/benefit of unblocking and rearrangement options.

If the defect is big, be prepared to drop the Sprint’s lower priority stories to get this one over the line.

Don't skip daily stand-ups

Even if you worked together all day yesterday on the same story, remember to keep the daily stand-up. Stand-ups are there for a higher purpose, an anchor point each day. They also promote collaboration, so another team member may have a good idea that could help you.

Track new metrics

Agile teams should be 100% effective but not 100% busy. Therefore, we prefer to end Sprints with the least number of things not done.

Track and prioritise these metrics:

  • Story points done compared to story points not done (a higher ratio is better)
  • Days each story takes from coming out of Backlog to moving into Done (a lower number is better)

Metrics only matter when they are managed. Use them in the retro to discuss how to tighten up the next Sprint. Also remember to be kind and productive when using metrics to make improvements, and not as way to be critical of individuals.

Keep developing your skills

Team members should know their own T-shape and we can hone those skills to the left or right of our key competencies. This will mean more opportunities to provide value to the priority stories. This enables the team to be more effective at getting the features over the line, namely this Sprint!

Agile Manifesto alignment

The ideas in this article focus on working together to get the planned features over the line in the current sprint.

This behaviour aligns to the Agile Manifesto by valuing working software over comprehensive documentation. By collaborating, the team does not need as much documentation as they all have a common understanding of the Sprint goal and the individual user stories.

This is underpinned by ensuring we understand our highest priority is to satisfy the customer through early and continuous delivery of valuable software. By swarming together, the team can get more done and have less work in progress which does not provide the customer with any value.

Swarming to ensure we get the most features delivered this Sprint keeps our product delivery on track, as we know that working software is the primary measure of progress.

Let’s bee productive!

Just like a bee swarm, a well-planned and efficient effort can produce the results you need in the current Sprint. The natural world has lots to offer us in terms of our Agile practice!

Nathan Coombs

Engineer

Embed Quality in your Agile Delivery

No matter where you are on your Agile transformation journey, we offer a broad range of consultation, assessment, training, and coaching services that enable your teams to deliver better outcomes faster, embed quality in every iteration, and adopt 'shift left' practices.
 
Find out how our Agile Quality experts can help you understand your Agile maturity and fast-track your journey to Agile success with quality embedded throughout. .

 

Find out more

Get updates

Get the latest articles, reports, and job alerts.