What a Coding Dojo taught me about agile

In their article, What is agile?, Jen Krieger, Daniel Oh, and Matt Takane discuss what we at Red Hat consider the most important sentence of the Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it.”

I like this sentence because it helps to understand why we could apply “agile” outside of software development. We could replace “developing software” in that sentence with something like “cooking,” and it would still give us a good idea of the mindset of people who engage in “agile cooking.”

Of course, we often associate “agile” with specific practices. Let’s take the example of two agile practices that were used together during a Coding Dojo event. A Coding Dojo is a great way of uncovering better ways of developing… I’ll stop there; you know the rest of the sentence by now. A Coding Dojo is a great way to get better at something by practicing with others in a safe and controlled environment. The practices I uncovered that day were test-driven development and pair programming:

• Test-driven development, or TDD, is a process in which a developer starts by writing an automated test for a function, then writes the code that will make the test pass.

• Pair programming is when two coders work together using one computer.

The Coding Dojo experience

Imagine yourself in a room with 20 coders, one laptop, and one big screen. Two seats are near the computer for the first pair of programmers, and there are enough seats for the other programmer pairs who will observe before taking their turn at the keyboard.

The kata we used that day was the Bowling Game. The goal of the Bowling Game, as explained on the Coding Dojo website, is to “create a program, which, given a valid sequence of rolls for one line of American Ten-Pin Bowling, produces the total score for the game.”

Each pair of programmers has a five-minute timebox to advance in the resolution of the challenge, using TDD and taking steps that are as small as possible. At the end of the timebox, another pair will follow.

The first coder starts by writing the first test. The test fails to red as there is no code yet (test tools associate green with a passing test and red with a failing test). The second coder writes the smallest possible amount of code to make the test pass green, and he or she then improve the tests. The test goes back to red, and we switch back to the first programmer, who then writes the smallest possible amount of code to make the test pass. And so on. Refactoring is done along the way.

The interaction between the two coders is the kind of magic we all love to see. That's because contributors are not submitting a patch hoping for a fast review; they have the review in real time. And because they are progressing in small steps, explaining what they are doing, it is easy for everyone to stay connected, whether you are in the audience or the second coder in the pair.

Writing the test first forces an early understanding of what is required. Focusing on the smallest amount of code possible to make the test pass also helps to keep the design as simple as possible. Refactoring along the way ensures that we keep only the code we need.

Here are the key differences between the Coding Dojo experience and the typical development process:

• Developers work in pairs instead of alone to code features and fix bugs

• Testing is done before development instead of after code is developed

• Code review is done in real time, with the pair, instead of waiting for another developer to review and merge

Looking at a larger amount of code makes it more difficult to understand. The process is not only slower but leads to less beneficial interactions between the coder and the reviewer.

Why do we consider pair programming and TDD agile practices? Because they are designed to foster strong interactions between the individual members of the team. These interactions help them express their best in the code they produce.

This brings us to the second sentence of the Agile Manifesto:

“Through this work, we have come to value: Individuals and interactions over processes and tools.”

You can, of course, have processes and tools. But those processes and tools should foster the expression of individuals and their interactions. The latter has more value than the former.

So the next time you are engaged in a conversation about tools or processes, ask yourself (and others): Are we bringing a tool or a process that will grow individuals and interactions?

Answering yes to that question shows you the agile way.