The Art of Agile Development

by James Shore

Expect to feel tired at the end of the day. Pairs typically feel that they have worked harder and accomplished more together than when working alone. Practice energized work to maintain your ability to pair every day.

Somebody’s who’s unfamiliar with the IDE or codebase may need specific guidance. But resist the urge to micromanage.

When I’m navigating, I like to keep an index card in front of me. Rather than interrupting the driver when I think of something, I write my ideas on the index card and wait for a break in the action to bring them up.

If you need more than a few minutes, pause coding to research the solution together. Sometimes the best way to do this is to split up, pursue parallel lines of inquiry, and come back together to share what you’ve learned. Spike solutions are a particularly powerful approach.

Encourage your driver to share their thoughts, and when they have a design idea for later, offer to make a note. Also, if you get to a tricky design question, it’s okay to stop coding, grab a whiteboard, and spend some time working through ideas together.

Teaching your pair partner how the code works slows you down, but the goal isn’t to maximize your performance…it’s to maximize the team’s performance.

Instead, provide big-picture direction—maybe even start with a whiteboard diagram—and give them space to figure out the details.

don’t say, “We need to change SuperMailClient. Click source…now click infrastructure…now click rest…” Instead, provide context and direction: “Our task is to replace our transactional mail vendor, SuperMail, with BetterMail. They both provide REST APIs, so all we need to do is change our SuperMail wrapper to use BetterMail instead. (Sketches the project structure on the whiteboard.) All our REST clients are in the infrastructure/rest folder and each service has its own wrapper.” Then let your partner navigate through the project files and find the file to work on themselves.

Once the person you’re teaching can find their way around, you can switch roles. Ask them to navigate and tell you what needs to be done next. Be careful, though: when you’re driving, it’s tempting to rush ahead and just do what you know needs to be done. For it to work as a teaching te...

It’s a very productive, very cerebral collaboration, and that can be a lot of fun. Most introverts I’ve met who have tried pairing have liked it, once they got past the initial learning curve.

If you think pairing might be difficult for you or someone on your team, talk about ways to make pairing more comfortable, or if there are other ways your team can achieve collective code ownership. The alignment session is a good time for this conversation.

New drivers sometimes have difficulty involving their partners; they take over the keyboard and shut down communication. To practice communicating and switching roles while pairing, consider ping-pong pairing. In this exercise, one person writes a test. The other person makes it pass and writes a new test. Then the first person makes it pass and repeats the process by writing another test.

Frank criticism of code and design is valuable, but it may be difficult to appreciate at first. Different people have different thresholds, so pay attention to how your partner receives your comments.

Try transforming declarations (such as “This method is too long”) into questions or suggestions (“Could we make this method shorter?” or “Should we extract this code block into a new method?”). Adopt an attitude of collaborative problem solving. See “Learn how to give and receive feedback” for more ideas.

Isn’t it wasteful to have two people do the work of one? In pair programming, two people aren’t really doing the work of one. Although only one keyboard is in use at a time, there’s more to programming than typing. One person is programming and the other is thinking ahead, anticipating problems, and strategizing.

At other times, you may just need a few moments of silence to think through the problem. It’s okay to say so.

Use test-driven development and take very small steps. Rely on your navigator to keep track of what you still need to do (tell them if you have an idea; they’ll write it down)

If you’re working with a technology you don’t completely understand, consider taking a few minutes to work on a spike solution.

there are many ways for a programmer flying solo to be productive without touching production code. They can research new technologies or learn more about a technology the team is using. They can pair with a customer or tester to review recent changes, polish the application, or do exploratory testing.

They can research solutions to friction the team is experiencing, such as slow builds, flaky tests, or unreliable deployment pipelines. They can review the overall design—either to improve their own understanding or to come up with ideas for improving problem areas. If a large refactoring is partially complete, the team may wish to authorize a conscientious programmer to finish those refactorings.

Mob programming tends to be less intimidating than pairing. If people don’t want to try pairing, see if they’d like to try mobbing instead.

Code quality. Because pairing brings so many perspectives to the code, and results in so much conversation about the code, it reduces defects and improves design quality.

In a sense, pairing is just continuous code review. Code reviews don’t share knowledge as thoroughly as pairing, though,

Flow. Pairing’s benefits to flow are more subtle. Because it focuses two people on the same problem, pairing is sort of like having a backup brain.

If you’re pairing, there’s very little cost to answering a question because your pairing partner keeps working. It makes sense to ask for help anytime you need help.

But the background conversation still enhances your situational awareness. It’s the cocktail-party effect: when somebody says something important to you, your subconscious picks it out of the background and brings it to your conscious attention.

Although it’s definitely weird, and can be a lot to ask, it’s worth putting in the effort to give it a real try. Don’t just dismiss it out of hand. If pairing isn’t a good fit, try mobbing instead.

Birgitta Böckeler and Nina Siessegger’s “On Pair Programming” [Bockeler2020] is a nice online article that goes into more depth about pairing.

Agile way is to experiment, learn, and improve. Rather than assume something won’t work, we try an experiment. Some experiments work; some don’t. Either way, we share what we learn.

In some parts of the world, the term “mob programming” has unpleasant connotations, so people call it ensemble programming instead.

Finally, add a timer. Seven minutes is a good starting point. When the timer goes off, the driver stops. Another person takes over and work continues right where the previous driver left off. Rotate through everybody who’s interested in programming.

When I first heard about mobbing, I poo-poo’d it. “I get the same benefits from having a cross-functional team, a team room, pairing, frequent pair switching, and good collaboration,” I said. And I was right. Mobbing doesn’t get you anything you don’t already get on a good team. But it’s so easy. Getting people to pair and collaborate well is hard. Mobbing? It’s practically automatic.

You might find that you need to set a longer timer—perhaps 10 minutes instead of 7—to reduce the amount of switching needed.

Establish working agreements, make it safe for people to express disagreement and concerns, and pay attention to team dynamics.

When you first start mobbing, it’s worth spending a few minutes at the end of each day for a very short retrospective. Focus on what worked well and how to do more of it. Woody Zuill calls this “turn up the good.”

One of the advantages of mobbing is that it’s not dependent on any one person. People can drop in and out as needed. If you need a coffee break, or just want to clear your head, step away. Similarly, if you need to check your email or make a phone call, you can do that. The mob will continue on without you. You don’t have to align your work hours, either.

Everybody in the mob can be a driver, even people who don’t know how to program.

mobbing really more effective than working alone or in pairs? For new teams, almost certainly. Teams’ effectiveness depends on how well they know the code and one another, and mobbing excels at this sort of learning. This is why I recommend that teams start with mobbing. (See “Your First Week”.)

Can you avoid programming jargon, such as the names of design patterns, frameworks, or coding styles? Is your domain expert able to identify potential problems in your business logic?

Overcoming this challenge is, fundamentally, an issue of communication. Domain experts communicate their expertise to programmers, who in turn encode that knowledge in software. The challenge is communicating that information clearly and accurately.

Programmers should speak the language of their domain experts, not the other way around. In turn, domain experts should tell programmers when the language they’re using is incorrect or confusing.

The advantage of using code for documentation is that code can’t help but reflect what your software really does. With care, you can design your code to be self-documenting.

Done well, TDD ensures that the code does exactly what you mean, not just what you say.

Next, think of a test—also just a few lines of code—that will fail until exactly that behavior is present. Think of something that checks the code’s behavior, not its implementation. As long as the interface doesn’t change, you should be able to change the implementation at any time, without having to change the test.

This is the hardest part of TDD, because it requires thinking two steps ahead: first, what you want to do; second, which test will require you to do it. Pairing and mobbing help. While the driver works on making the current test pass, the navigator thinks ahead, figuring out which increment and test should come next.