Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The agile swarm: How to design shareable work for software project teams

Stephen Frein Senior Director, Software Engineering, Comcast

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

Read more articles about: App Dev & TestingAgile