Agile teams have all kinds of ways to deliver value faster, both to verify that the team understands what the customer wants, and to verify that the product works the way everyone expects. The team can slice the stories smaller. Or, it can spike the work to create experiments and learn from them.
But every team has one powerful superpower at its disposal for faster value creation and delivery. That tool is collaboration. Not cooperation, although that helps. And not solo work, because that requires handoffs.
Collaboration occurs when the team members work together on one item at a time. When teams collaborate, they keep their WIP (work in progress) low and increase their throughput. (See What’s Taking So Long? Little’s Law Holds the Answer for more information.)
Teams have several collaboration options: working in pairs, triads, or subsets of the larger team; swarming over the work; and mobbing/ensemble product development.
Let’s start with pairs and triads.
How Pairs and Triads Can Work
Many teams still work in resource-efficiency thinking, where one person does “their” work, hands off that work to the next person, and so on. If you’re thinking this resembles the telephone game—you’re right.
When two people work together, they “pair.” Those two people—not a single person—take responsibility for a specific item. They decide how to work as they watch the same screen, passing the keyboard and mouse to each other at regular intervals, such as every eight minutes.
Pairing offers several benefits, including continual code review.
Now, imagine a team where a tester works with the two developers. They have several options, including passing the keyboard between each of them, alternating code-based work with test-based work. Again, everyone sees the code and the tests as the triad develops and uses them.
Pairs and triads work well. But what if you have nine people on a team? Or five? In that case, there are people “left over,” who aren’t specifically collaborating. That’s when extending the idea of pairs and triads to subsets can work quite well.
How Subsets of the Team Can Work
Instead of working separately, imagine a team where a tester works with all the necessary developers on one feature. Here’s how one team did this.
Frank, the front-end developer, showed his user interface sketch to his colleagues: Mary, the middleware developer; Pat, the platform developer; and Tom, the tester. Mary and Pat asked several questions, while Tom sketched in his notebook.
Frank asked, “Are we all agreed then?”
Tom shook his head and said, “No. I have questions about response time and what happens in these three scenarios.”
The four of them continued to discuss, challenging their original assumptions. After just 10 minutes, they agreed on a different implementation and test strategy. And, they decided to continue to collaborate as pairs.
First, Frank and Tom worked together. Frank implemented the user interface and the API (application program interface) so Tom could write as many automated tests as he wanted.
At the same time, Mary and Pat paired to make sure their assumptions still held, and to build code review into their work. When Frank and Tom finished their work, they joined Mary and Pat. That’s when Tom—with Frank’s assistance—added more tests to his test suite.
Because they collaborated, they built code review, test development and testing into their work. They mostly worked in their specialty, but they didn’t have any delays due to code review or test development.
Sometimes, the four of them swarm, often with the rest of the team.
Swarming as a Team
When teams swarm, the team takes one item off the backlog. Then, each person works according to their specialty, but just on that one item. The team keeps its WIP low and finishes that one item fast. If anyone finishes before the other people, they do not start something new. Instead, they offer support to others.
In this case, the team has another middleware developer, Mindy, and another platform developer, Penny.
The team met with the product leader, Ben, who explained the goal of this item. Then, the team discussed how it planned to attack the work. The team members agreed they would meet to discuss their progress in an hour. If anyone got stuck, they would ask for help as soon as they got stuck—they wouldn’t wait an hour.
Half an hour into the work, Frank messaged Pat and Penny. Frank discovered he needed to change the user interface from what they had originally planned. He was sure that would change the platform.
As soon as Pat and Penny heard Frank’s proposed changes, they realized the middleware needed to change, too. As well as the test strategy.
They called the team back together, discussed their new ideas, and decided to meet again in 30 minutes.
After everyone spent another 30 minutes, they realized they had a plan that would work. Now, as soon as someone finished “their” work, they could ask for review, or offer their services to any other member of the team.
Swarming has one rule: No one gets to start on another item until everyone finishes this item.
I recommend the team meet every hour, but sometimes teams prefer to change their meeting intervals. I like pairing for code review or test review as the team proceeds, but some teams prefer to review all at the end. Or, to stop everyone’s progress and review as soon as someone has something to review.
But the key is to limit WIP to just one item.
There’s another way to limit the team’s WIP to just one item, and that’s mobbing on the work.
Mob/Ensemble Product Development
Imagine this: The entire team sits in front of a large monitor (or all members share a virtual screen). The driver sits at the single keyboard and types either the specifics or the intent of the navigator. The mob—the rest of the team—discusses what they want the driver to do next, and the navigator structures those ideas for the driver.
This extends the idea of the pair or triad to the entire team.
I happen to like the word “mob” because it reminds me of a mob flash dance. However, some people prefer the word “ensemble.” Whatever you call it, the entire team collaborates at the same time on one single item.
As with pairing or triads, the entire team sees the code or tests as the driver types. No one else can type—only the driver. And while the mob or ensemble can call out suggestions, the navigator is responsible to the driver for structuring those comments.
In this case, I recommend everyone rotate positions every five minutes. That way, everyone stays engaged in the work.
Collaboration is an Agile Superpower
The more the team collaborates, the faster it can learn. Team members learn to finish the work—or know that there is something preventing them from finishing the work.
This article was originally published by ProjectManagement.com at https://www.projectmanagement.com/articles/917365/agile-superpower–1–focus-on-collaborative-teamwork-. Reproduced with permission of ProjectManagement.com. Copyright © 2023 ProjectManagement.com. Unauthorized distribution of this content is strictly prohibited.