AoAD2 Part III: Delivering Reliably (Introduction)

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for release dates, additional excerpts, and more.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Delivering Reliably

It’s October again. Over the past year (see Part II), your team has been working hard at developing its Delivering fluency, and now you’re a well-oiled machine. You’ve never enjoyed your work more: the little annoyances and friction you associate with professional software development—broken builds, frustrating bug hunts, painstaking change analysis—have all melted away. Now you can start a task and have it in production a few hours later.

Your only regret is that your team didn’t pursue Delivering fluency from the beginning. In retrospect, it would have been faster and easier, but people wanted to take it slow. Oh, well. Now you know.

As you enter the team room, you see Valeri and Bo working together at a pairing station. They both like to come in early to beat rush-hour traffic. Valeri sees you putting away your backpack and catches your attention.

“Are you available to pair this morning?” she asks. She’s never been one for chit-chat. “Bo and I have been working on the real-time updates and he said you might have some ideas about how to test the networking code.”

You nod. “Duncan and I spiked it yesterday and came up with something promising. Do you want to pair, or should the three of us mini-mob?”

“You can pair with Valeri,” Bo calls over, getting up and stretching. “I need a break from networking code.” He mock-shudders. “Even CSS is better than this.” Valeri rolls her eyes and shakes her head. “I’ll let you get settled in,” she says to you. “I need more coffee.”

Half an hour later, you and Valeri are making good progress on the networking code. A steady series of soft chimes comes from the workstation. Every time you save your changes, a watch script runs your tests, then chimes a second later to indicate if the tests passed or failed.

You’ve gotten into a steady rhythm. At the moment, you’re driving and Valeri is navigating. “Okay, now let’s make sure it throws an error when the message is empty,” she says. You add a test. Dong. The test fails. Without a pause, you switch to the production code, add an `if` statement, and save. Ding! The test passes. “Now when the message is corrupted,” Valeri says. You add a line to the test. Dong. Another `if` statement. Ding! “Okay, I’ve got some notes about more edge cases,” Valeri says, “but I think we need to clean up these `if` statements first. If you factor out a `validateMessage()` method, that should help.” You nod, select the code, and hit the Extract Method keystroke. Ding! No problems.

The sounds were the result of an experiment a few months ago. Despite the jokes about “Pavlov’s programmers,” they were a hit. Your team works in such small steps that, most of the time, the code does exactly what you expect it to. Your incremental test runs take less than a second, so the sounds act as instant feedback. You only need to look at the test runner when something goes wrong. The rest of the time, you stay in the zone, switching back and forth between tests, code, and refactoring, with the steady chimes assuring you that you’re on track and in control.

Another half hour later, the networking changes are done. You stretch as Valeri pulls the latest code from the integration branch and runs the full test suite. A minute later, it’s passed, and she runs the deployment script. “Done!” she says. “Time for more coffee. Keep an eye on the deploy for me?”

You settle back in your chair and watch the deployment script run through its paces. It tests your code on a separate machine, then merges it into the shared integration branch. Everybody on the team merges their code from and to this branch every few hours. It keeps the team in sync and ensures merge conflicts are resolved early, before they become a problem. Then the script deploys the code to a canary production server. A few minutes later, the deploy is confirmed and the script tags your repository with the success.

You saunter back to the task board and mark the networking task green. “All done, Bo!” you call. “Ready for some CSS?”

...to continue reading, buy the book!

In this Section

  1. Delivering Reliably
    1. Welcome to the Delivering Zone
    2. Achieving Delivering Fluency

Discuss the book on the AoAD2 mailing list or Discord server! Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.