Successful agile teams tend to limit work-in-progress (WIP). Whether they prefer Scrum, Kanban, or some other agile method, these teams emphasize the rapid production of usable functionality over other considerations.
They worry more about idle work (stories lingering unfinished) than idle hands (whether people have every minute of their day attached to planned work). Accordingly, they identify the highest-priority stories and swarm around these, meaning that the entire team, or much of it, focuses on the same story until it is complete. Instead of divvying up the backlog into a number of single-serve portions that each team member can consume privately, high-performing agile teams prefer to dine family style—they pitch in however they can to complete the most important items collaboratively.
The virtues of limiting WIP are well recognized, including greater focus, faster execution, lower cycle times, and less waste. These benefits make the practice of swarming broadly appreciated. Yet, while many authors note the need to design work in a way that enables swarming, it is hard to find specific guidance on how to do this. The first step is understanding how to design work that is shareable across team members. Fortunately, there are a number of concrete approaches you can take to make work more shareable.
Decompose work into architectural layers
Work becomes more shareable when it is decomposed into architectural layers. Individual user stories should represent a thin vertical slice of functionality that cuts across all layers of the application, from the user interface or service interface through the business logic and down to the backing store (database). We need our user stories to go through all architectural layers because we want to give our product owners working software for acceptance, rather than isolated technical components that do not yet fill a business need and cannot be understood by nontechnical personnel.
However, we don’t need to have the same person implement all of these layers. For example, a user story to enable the creation of items in a product catalog could reasonably be divided among multiple developers by architectural layer, with one developer working on the UI, another working on the database, and a third creating the controllers and business logic needed to carry data back and forth between the two.
Build code using interfaces
Work becomes more shareable when it is built with interfaces. Within the code base, interfaces create seams needed for automated testing, dependency injection, and architectural flexibility. Within the team, interfaces create areas of responsibility that can be assigned to a single developer.
For example, if our product catalog is separated across two databases, with some products in a relational database and others in a document database, we could employ a data access object pattern by defining a single product data access interface and building a separate concrete implementation for each database. Each of these concrete implementations could be the responsibility of a single developer, but the work of all the developers would be coordinated and harmonized by the shared interface.
Build code portions in parallel
Work also becomes more shareable when it is parallelized. Although some tasks logically precede others (e.g., we must define an interface before its concrete implementations), we must be careful not to establish finish-to-start dependencies (one task finishes before the next one begins) when start-to-start dependencies (one task starts before the next task starts) will do.
In an iterative development approach, we welcome the evolution of the requirements, and so we should not be afraid to build dependent things partly in parallel. For example, we could start to build the concrete implementations of our product data access interface before the interface is completely finalized, with the understanding that we couldn’t fully finish the implementations until the interface had been nailed down.
"Parallelizing" things this way would allow more people to work on the effort at the same time and create a valuable feedback loop between the specification and the implementation.
Separate core development from supporting activities
Another way to increase shareability is to separate core development from supporting activities. For example, while one team member works on the code for a feature, another could work on getting needed test data, developing end-to-test cases with ancillary systems, or chasing down missing requirements information.
Even if the coding needed for a story is small enough that it is best handled by a single person, the swarm can still assist by handling all of the other elements of successful software production that lie outside of the code and that would lead to excessive task switching if pursued by just one person.
Use coordinated pairs of workers
No matter how our work is organized, we can make it shareable when we approach it by pairing. That is, rather than parcel the work into separate slices, we could have coordinated pairs of people attack any given task. By sharing ideas and reviewing each other’s work in real time, paired team members maximize learning and minimize mistakes.
Such pairing could be paired programming, as in XP, but it could also be the pairing of a tester and developer (or any other two roles) who work side-by-side to go beyond what each of them could accomplish individually.
Make the work large enough to share
Critically, work that is suitable for swarming should be large enough to share. Some body of work might be so small that it cannot be profitably shared across team members, even with pairing in play. If you encounter such a situation, ask whether the work in question really is a user story with independent business value, or if it is actually a technical implementation task disguised as a user story. If it is the latter, then you should either roll it into some existing user story or fill out the remainder of the user story that it implies.
Even if team members divide up the implementation tasks for a user story, they still shouldn’t be working in isolation. Whether they are formally pairing or not, all of the people swarming on the story should be in regular communication with one another and integrating their output continuously to avoid wasteful disconnects and associated rework.
Last word: Hives thrive through connection
The fundamental precondition for this movement is sharing. Swarming teamwork is interconnected. To make your swarms move in a common direction, learn how to make your work more shareable.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
