AgileProcessImprovementScrum
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.
To me, the bee swarm sounds like an Agile team I’d like to be on because:
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.
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 membersTo 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 awayTesters 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-upsEven 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 metricsAgile 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:
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 skillsTeam 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!
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.
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!
Engineer
We use cookies to optimise our site and deliver the best experience. By continuing to use this site, you agree to our use of cookies. Please read our Cookie Policy for more information or to update your cookie settings.
