Agile swarming techniques are some of the smartest and yet underrated ways of boosting the speed of teams that follow the Scrum and Agile methodologies. Such techniques enhance productivity and are a marker of consistency in the delivery of products/ services. A swarming technique in Agile is very easy to implement and use, and even the teams recently introduced to the Agile way of work can use it as part of their daily plans. The post below explores the functions of swarming while also positing examples from the real world to prove the tangibility of the pattern in healthcare systems.
Like in a swarm of birds or bees, swarming involves a host of members of the same Team working on the same project. Such a project often concerns an item of utmost priority, and the swarming occurs right until work on that item is completed. Sprint Backlogs are composed of disparate items, the importance of which vastly differs from one another. As such, such projects must be completed before the Sprint has ended, as only one among those items can serve as the Team’s top priority. A team swarms or focuses all the energy of its members on that item, which might be more complicated than it seems to be.
Dr Jeff Sutherland, the founding head of Scrum, attests to this very fact. Despite pointing out how organizations nowadays have individual members, and even teams comprising the entire organization who work on top priority projects, he also testifies to the massive amount of dysfunction that slows down the organization and teams. What can be done to reduce frustration? How can happiness be boosted, and how might a leader look forward to increasing the Team’s effectiveness?
The answer is, at least on paper, pretty simple. They must discern the story of maximum relevance and focus on it. Therefore, the Team must be aware of the item of top priority in the backlog.
This is followed by mobilizing the workforce. All team members who are available to work must be motivated to focus their attention and energy on that single priority item. It might not be possible to finish the project in record time by having the entire team work on it, but the more, the better.
To truly use the Agile methodology, team members need to work simultaneously and share the burden of work with each other. The nature of what this involves is dependent on the work in question, but again, point two comes into focus. Even if all the members cannot be made to work together, the more a leader can get in a shared space, the better the chances of success.
After this is complete, the Team is asked to swarm on the next item, and so on. Trying such methods for a Sprint might prove to be pleasantly surprised. Scrum and Agile Teams have been statistically reported to portray significantly boosted speed in short periods… to rates as high as 200 per cent.
While talking about the same, we realize how such processes might seem counter-intuitive. Several teams even divide their backlogs, discern the individual items which need to be worked on, and assign members to each of them. The common misconception is that such a process will lead to more work since it happens altogether, but such fails to hold. Jeff confirms this by saying that a team is often late because everyone works on their own thing instead of adopting a collective, swarming tactic. Instead of being boosted, the speed is drastically reduced when there is not enough time to test everything altogether at the end of the process.
Swarming – A Blessing in Disguise
Swarming works because its essence is rooted in our psychology. Often, human beings are distracted and constantly lose focus. They cannot concentrate, having their tasks interrupted by a barrage of texts, emails, phone calls and the like. Switching focus from one thing to another causes us to lose a significant portion of productivity and concentration. This involves setting a reset button mentally and ramping up, possibly using a different system at a different location. The allure of multitasking is sure to destroy productivity in Scrum teams.
When a person works on a certain thing, they usually focus a hundred per cent of their time and attention, but such percentage drops to about eighty when they have to shift context even a single time. Even the amount of time that one had initially made available for work drops, and shifting attention and time thrice a day causes the effective time to drop to about sixty per cent. The benefits of swarming lie in how such a technique saves a team and its members from constantly switching attention and context. There is no need to reset or reboot, and optimum productivity can be used for deadlines.
Swarming also improves the process efficiency of a Scrum or an Agile team. The term refers to an important metric, the result of which may be obtained as the amount of the work which can be finished in a particular time, where time refers to the number of days considering that the hours put in per day are more or less the same. A typical Scrum or Agile Team has productivity higher than teams that do not use the Agile methodologies.
When efficiency is ten per cent, one day or work had taken ten calendar days in real-time. As such, the data points to this ideal workday meeting its potential in ten days. However, Via swarming, three people might be put to work on that same item. As such, their collaborative efforts may have got the job finished in a single day. This process ascertains 100% efficiency, leading to a natural boost in speed. In fact, according to pie charts and bar graphs, the velocity of a Scrum team might be doubled when efficiency is improved by 20 to reach fifty per cent.
Furthermore, swarming reduces waste. By waste, we mean a specific kind of waste – this also boosts the Team’s velocity. In the guise of work left unfinished, this waste is accurately deemed so because of the amount of time, effort, energy, money, resources, and hopes which went into the same. All these parameters are wasted, and the organization has nothing to prove the necessity of wasting the same. Having several team members to work on a process finishes it and rarely leaves work incomplete.
A Case Study
If you are still not convinced, we have a case study to back up our words. The Scrum founder, Sutherland, cites an instance of Scrum consultants who had partnered and collaborated with a hospital chain. This was done to solve a problem that had plagued them for several years and involved reducing the time to sanitize and reset each operating room. This would be possible without decreasing the quality of treatment offered or risking people’s health.
Generally, the cleaning crew needed an hour to do the job from the time it took to take the wheels out to when the patient was wheeled in. Such terminologies have been used with regards to the patient-carrying carts. Sutherland writes that the process is not just about sterilizing a room but also coordinating with medical teams, the surgeon, the anesthesiologist and the nurses. It involves having the right surgical instruments set up at the correct places. This was no uncomplicated job.
However, the cleaning crew came up with a solution – they swarmed and drastically improved the process. The realization that partnering and collaborating on the same task would exponentially decrease the time to clean was a huge help. Such an experiment worked consistently for a couple of days in a row. Sutherland testifies to this, saying that the time taken for the gurneys to come in and leave the room had been decreased. As a consequence of such, the average time of an hour had been shortened to half of its original time or even a quarter. The best part about all this? There was no negative change in quality.
These processes helped the staff to treat a greater number of people by effecting a simple change in daily policy. There was no fancy technological change or additional staff required for this to happen. Swarming performs these functions above and allows the sharing of skills among different members, leading to a learning improvement or a boosted skill set. Jeff Sutherland notes that despite having worked with several organizations and a plethora of teams, they had never seen a Scrum or Agile Team which had not made consistent use of swarming patterns to meet their goals.