Work as a Whole Team to Create the Product
I talked about the interpersonal skills agile teams need to work together in Chapter 3, Build Teamwork with Interpersonal Practices. The payoff for the team building its safety and trust comes when the team members collaborate to build the product.
You’ve seen that agile approaches are about team collaboration to deliver value. Your team might take the collaboration to another level with pairing, swarming, or mobbing.
- Pairing
-
Two people work together on one story, on one machine with one keyboard. Developers might pair-program. A developer and a tester might pair together to review performance. Two testers might pair-test. Any two people working together are a pair. See Pairing Creates an Environment of Continuous Review.
- Swarming
-
The team works together on one story, but each person contributes based on his or her expertise. The platform developer works on the platform, the middleware developer works on the middle ware, the UI developer creates the UI. In addition, the tester develops tests. When each person is done with “their” part, that person offers his or her assistance as a pair to whomever is still working. See Swarm on the Work.
- Mobbing
-
The entire team works together on one keyboard. Think of mobbing as team-pairing. See Mob on the Work.
Here’s the value of pairing, swarming, or mobbing:
-
The team limits its WIP, which helps it focus on getting work done.
-
The team can learn together in swarming and does learn together in mobbing.
-
The team collaborates, so it reinforces its teamwork. Team members learn how each other person works. They also learn who has expertise now, who might need which expertise, and how each of their colleagues learn.
-
The team has multiple eyes on small chunks of work, so it gets the benefit of continuous review.
Managers who are unsure of flow efficiency may wonder about the “cost” of pairing, swarming, or mobbing.
pairing
collaborationpairing
costspairing
I Used to Think Pairing Was Expensive
by John, VP, R&D
John
Early in our agile transformation, I thought pairing was expensive. I was paying two people to do the work of one person. What were these people doing?
Then we had a cascading problem. It started off in the Admin part of the code. The Admin guy fixed it. Then, a new problem popped up in the Engine. The Engine guy fixed that, and broke Payments and Search.
First, the Engine guy started to work with the Search guy. The Payments woman overheard what they were doing and said, “That won’t work!” I think they had a knockdown, drag-out fight. It was a little ugly.
The manager for the team asked this question: “What if you all worked together on this problem, so you can all explain what’s going on to each other?” The team agreed to do so.
I was not happy. Now I was paying five people to do one person’s job. We’d already spent two weeks on this problem.
They finished the fix the next day. One area in the code had made assumptions that another area hadn’t. They would have taken forever to find this working alone.
If they could be so fast and fix—really fix—the problem, what would they be able to do when they wrote new code?
In an agile approach, we want the team to take responsibility for its work. We want throughput as opposed to busyness. Pairing, swarming, and mobbing all use the ideas of flow efficiency to finish the team’s work.
The more the team feels as if it has collective code ownership, the less the team reinforces resource efficiency and the more it reinforces flow efficiency.
Here are some references for pairing, if you would like to read more: Pair Programming Illuminated [WK02], Beyond Legacy Code [Ber15], Remote Pairing [Kut13], and Agile in a Flash [LO11]
Pairing Creates an Environment of Continuous Review
You might think pairing is about working on something where one person doesn’t understand it. Pairing works then. Pairing is even better when people learn and deliver together as a pair. Pairing works and takes less time than any one person working alone. That’s because the pair focuses together. Each person acts as a check on the other person.
When team members pair in person, they work on one item—on one machine, with one keyboard. The pair trades off who types and who looks. The person typing is called the driver. The person looking is the navigator.
Often, the two people change places every 15 minutes. That gives both people a chance to see the small picture (what the driver sees) and the big picture (what the navigator sees).
With the real-time review that pairing provides, we can avoid the number and severity of defects that either person might produce alone.
Pairing saves the team time and therefore money.
I have found another benefit to pairing: Each person learns about this domain from the other person’s perspective. I often ask what I consider stupid questions when I am the navigator. Sometimes the questions aren’t stupid—they prompt us as a pair to understand the story better. I find that when I pair, I learn a ton about the domain.
Swarm on the Work
Swarming is another way to collaborate as a team. The entire team works on just one story at a time. The team’s WIP limit is 1.
In swarming, the team members work alone or maybe in pairs, according to their expertise and desire. They often start off the work with a short standup where people will say, “Here’s what I will do.”
The swarming team discusses the story. Then the team members work as they choose (solo, pairs, triads) in a short timebox of one hour to work on their own. After that timebox, the team returns to check in with each other and see how the work is going for everyone. They might need to resolve issues in the code or the tests, so they decide what to do next. They then repeat the work and check in until the team finishes the work. The team has a cadence: work for an hour, check in with each other, scatter to work for an hour, check in, repeat until the item is done.
If one person is done before the others, that person offers his or her services—possibly as a reviewer—to the rest of the team.
Swarming helps the entire team understand the feature under development. Because the entire team works together, the team has no interruptions. No one multitasks. The team can reduce its cycle time for a given feature.
If your team has a difficult time making the stories small, swarming is one way to deliver larger stories faster.
Here’s how this might work in practice:
Team 1 gets together as a team and discusses the item with the product owner to make sure everyone knows what they will do. They talk among themselves for a couple of minutes to decide on their “plan of attack” (their words) and then scatter. The testers develop the automated tests and take notes on the exploratory tests. The developers work on the code.
Team 1 has an agreement to return every 25 minutes to check in with each other. They do this with this kind of a report: “I’m done with this piece. I need help for this next piece. Who’s available?” Or “I’m as done as I can be for now. Anyone need another pair of eyes?” This team chose 25 minutes because it has smallish stories and wanted to make sure it maintained a reasonable pace/momentum.
As people finish their work, they help other people in whatever way they can. Early in Team 1’s agile days, it had a ton of automated test “technical debt.” (I would call it insufficient test automation, but whatever term you like is fine.) The developers often are able to finish their code first and then help the testers bootstrap their test automation.
You can swarm in any number of ways. On Team 2, the UI, platform, and middleware developers get together to discuss for a couple of minutes and then write code together, each on their own computer. They have a team room, so they can see each other.
On Team 3, the platform and middleware developers pair, on one keyboard for all the code-writing work. The UI person works alone, checking in when she is done. Everyone checks their work into the code base as they complete it.
There is no right or wrong way to swarm. The only problem with an agile team is if someone is stuck and no one knows and that person does not ask for help.
Mob on the Work
When a team mobs on the work, it combines swarming with some of the pairing ideas. The team has a WIP limit of 1. And the team mobs around one keyboard and large screen, so everyone can see what the driver is typing at all times.
The team changes drivers on a frequent basis, say, every 10 minutes. Many teams use a very large television as a monitor or hook up the computer to a projector. Whatever you do, make sure the team is comfortable: everyone has chairs that work for them. Many teams who mob also use hand sanitizer as a matter of course.
Team 2 mobs. The entire team sits around a table with one keyboard. The monitor output goes to a projector so everyone can see what the person typing is doing. This team has a guideline that it trades off “driving” (the person at the keyboard) every 10 minutes. Sometimes the tester leads, developing automated tests. Sometimes the developer leads. This team often uses test-driven development, so the tests guide their development.
Team 2 checks in at least as often as they change drivers. They use continuous integration. They find that the change of drivers with the check-ins helps them see if they break anything or if they need to refactor next.
The nice thing about mobbing is that everyone checks everyone’s work as the team proceeds. Everyone learns about the code and tests.
Years ago, I was part of a “tiger team” that had to find and fix a problem a Very Important Customer discovered. We mobbed on discovering the problem, all looking at the area(s) of the code that seemed to be the problem. Once we had a couple of hypotheses, we swarmed—each of us using our expertise to contribute to solving the problem. We met every couple of hours to check in with each other.
We worked on that one problem, reviewing our progress and reviewing our code and tests as we proceeded. For some of the challenging code, we pair-developed and pair develop-tested, so we had multiple eyes on the code and the tests. We wanted to make sure we found and fixed this problem. You may have had the same experience. At the time, we did not call it pairing or swarming or mobbing. We called it “finding and fixing the problem as a tiger team.”
