Tanusha - Fotolia
If you work alone and like it, the idea of pairing probably doesn't hold much appeal. But what if pairing and its sister practice known as Agile swarming could produce a better product? Johanna Rothman, management consultant at Rothman Consulting Group, Inc., says that they can. "You get constant review, constant ideas from collaboration."
I recently talked to Rothman about why these practices work and how she handles software professionals who say they prefer to work alone. In this edition of Quality Time, I highlight some key points of that conversation.
Why work in pairs?
The most familiar pair way of working to software professionals is pair programming, where two developers team up at one workstation. One writes code while the other reviews each line on the spot. But pairing applies to other activities as well: writing tests, testing software and even writing a book. If things are going along swimmingly, pairing up with a team member may not be necessary. But more often than not, the software development process can benefit from new ways of getting work done, Rothman said.
Johanna Rothmanmanagement consultant
Pairing remedies a situation she sees all the time when she works with Agile teams: Members specialize around a particular feature and disregard other features. As a result, the team is not able to achieve continuous flow, a key goal of Agile development. "That leaves a lot of features open at any one time," Rothman told me. "There is a lot of work that is not getting done. Pairing is a way to achieve continuous flow."
What if you hate pairing?
Pairing often flies in face of how people like to work. But pairing is not about you, it's about improving the productivity of the whole team. That is the truth, but Rothman takes a softer approach in dealing with people who don't want to pair. She reminds them that the practice is a familiar, natural process. "Everyone in software has paired at one time or another," she said. When we're stuck on something -- or just want to talk it out -- we run the idea by a respected colleague. "People do this all the time. It's nothing new," Rothman added. Talking it out and verbalizing our thought process is where the magic happens, she said. "We're engaging different muscles of the brain."
What is Agile swarming?
Sometimes pairing isn't enough to jumpstart a stalled team. What you really need, Rothman said, is swarming. Agile swarming is when the entire team swarms around a single feature or a story, much the same way bees swarm around a flowering plant producing nectar. In other words, everyone works on the same story at the same time.
Rothman recently recommended Agile swarming to a conference attendee who approached her after a presentation she gave at Agile2014 Orlando. What could the attendee do to boost the productivity of her Agile team? "We have separate sprints for developers and testers, as a well as a sprint for business analysts," she told Rothman. Rothman's first thought was, "That's not really Agile." Her second thought? "Get the three [groups] together and swarm over a story."
Here are her recommendations on how to experiment with Agile swarming:
- Use timeboxing techniques, so the exercise doesn't turn into an open-ended discussion. Set aside a day -- perhaps Wednesday -- to swarm.
- Take 20 minutes to discuss the story and decide who will do what.
- Every 45 minutes, check in to see where you are. Did you check the code? Do you have automated tests? Is anyone stuck?
The goal is to experiment with this approach, and then do a retrospective on it, Rothman said. Figure out whether you want to try it and adjust some of the variables. "Maybe you want a smaller timebox, maybe half a day. The more you do these little experiments, the more value you get."
Whether you are pairing or swarming, it's important to remain open-minded and curious about this new way of working. It helps to check your ego at the door and let go of any preconceived notions about the people you work with. "Everyone is more equal than they [think]. More people will contribute than you think," Rothman said.
That doesn't mean every pairing or swarming experience is a good one. Rothman's first was a disaster. As a young programmer, she paired with her boss to write code. "The dynamic was master/slave and I was kicking and screaming the whole way through it," she said.
But today Rothman relies on pairing techniques to write some of her books, as well as to develop fresh content for her consulting practice. "We talk a little bit, and then one [of us] takes the keyboard, and we change roles when it's time to change," Rothman said of her writing partner. The process involves a lot of back and forth. "I write something she doesn't like and [my partner] says, 'I wouldn't say that.'" Of course the opposite is also true. "But we talk it out. We are better together than separately."
FAQ: Agile management and leadership
Agile development races ahead
The limits of Agile