Chapter 2. Lean and Agile

“You’re a lean, mean, fighting machine!”

Bill Murray as John Winger in Stripes

The triad of Cathy the customer, Debbie the developer, and Tom the tester has its first meeting. Debbie describes the differences between traditional development and acceptance test-driven development (ATDD). It’s explained how ATDD fits into lean and agile.

The Triad and Its Units

Many books on agility refer to the developer team and the business team. Names often have a connotation. On a football field, two teams compete to see who can score more points and win the game. On a single football team, there is an offensive unit, a defensive unit, and a special teams unit. The offensive’s unit job is to score points. The defensive’s unit responsibility is to keep the other team from scoring. The special team unit has the goal of scoring points when it receives a kicked ball and preventing the other team from scoring when it kicks the ball. All three units must do their job to win the game.

Although each unit has a primary job, it doesn’t stop there. If the offensive unit fumbles the football and the other team recovers, it does not simply stop playing and call for the defensive unit to come on the field. Instead, it plays defense until the end of the play.

The three basic units in a software project are the customer unit, the developer unit, and the testing unit.¹ The customer unit (which may include product owner, business analysts, and subject matter experts) determines the requirements, creates acceptance tests, and sets priorities. The developer unit implements the requirements and ensures the implementation meets the acceptance tests. The testing unit checks that an implementation does what it is supposed to do and does not do what it is not supposed to do. The testers help the customer unit develop acceptance tests, and the developer unit passes those tests. The triad works together to produce quality software.²

We start the story with Debbie, representing the developer unit, explaining to Cathy, the customer unit, two ways that teams approach software development. Tom, the testing unit, is sitting in the meeting of the triad (see Figure 2.1).

Figure 2.1. The Triad

Post-Implementation Tests

Debbie and Tom meet with Cathy to explain how the development process works. Debbie begins with how the flow often works and compares it to how Debbie and Tom prefer to work.

Debbie introduces the chart shown in Figure 2.2.

Figure 2.2. Typical Development Flow

“Cathy, this is how many development teams work to implement a requirement.³ As a developer, I elicit a requirement from the customer. Then I gather detail on the requirement, followed by designing and coding an implementation. I turn over the program to a tester like Tom. He develops functional tests to check that the requirement passes. He works with the customer or his representative to create and run some acceptance tests.”

“If the functional tests pass, as well as other tests, such as performance and usability, the system is ready to be deployed. Now if everything is perfect, the program passes through these stages in a straight line. But perfection only occurs in fairy tales. In reality, there are often misunderstandings. We don’t always use the same words with the same meaning. You may say always when you really mean usually. Or I may hear usually and think it means always.”

“Now when a misunderstanding is found, it needs to be corrected. If Tom finds that misunderstanding during testing, we have to figure out how to correct it. It could be that I simply made a mistake in coding. So you see a loopback shown by the line from test back to code in Figure 2.2. Tom tells me about the issue he discovered, and I correct it.”

“It could be a misunderstanding that occurred while gathering details of a requirement. In that case, Tom and I would revisit the requirement. He might have interpreted one way and I might have interpreted another. We would check back with you to see which one of our interpretations was correct or whether you meant something else entirely different.”

“This cycling back causes a delay in deploying the product, as well as extra cost in creating the product. So Tom and I like to operate in a different mode that uses quick feedback.”

Quick Feedback Better Than Slow Feedback

Before describing Debbie and Tom’s alternative process, let’s look at the idea of feedback. Feedback involves using current output to influence future output. Feedback in software development is not quite the same as feedback in control systems. In control systems, values from the output are fed back into the input to regulate the output. In audio systems, the output sound from the speakers can accidentally get back into the input to the microphone. That positive feedback can cause an explosive sound to emit from the speakers. Instead, think of software feedback as a listener commenting that the sound from your stereo speakers is not the desired level. You adjust the amplifier volume to make the sound closer to what the listener likes.

Imagine you want to show off your new stereo to someone. You turn it on, but the listener says he cannot hear the music very well. You constantly increase the volume. If the listener gives you frequent feedback, you’ll stop the increase just after you’ve increased past where he wanted it to be. So the volume will be pretty close to what he wants. You may home in even further by reducing the volume more slowly. If the listener does not give you frequent feedback, you will increase the volume well above what he wants and then decrease it well below. You will continually cycle between too loud and too quiet.

Quick feedback means less delay. Quick feedback is good. The output will be closer to the desired outcome.

Preimplementation Tests

“So how are things going to be different working with you?,” Cathy asks.

Debbie starts to describe another process. She shows Cathy the chart in Figure 2.3.

Figure 2.3. ATDD Flow

“Here’s the process that Tom and I use. After we elicit a requirement from you, Cathy, we work together to create some acceptance tests for the requirement. These are specific examples of the requirement in action. When I’m coding, I’ll use these tests to ensure that my implementation meets the tests. When it does, I’ll turn it over to Tom for the other types of tests that are discussed later [in the next chapter].”

Tom chimes in. “This is a small application relative to some we’ve worked on in the past. Debbie’s machine will be almost an exact duplicate of your computer where the application will be deployed. So when she turns the application over to me and I run it on the test system that exactly matches your computer, I don’t expect any acceptance tests that we’ve created to fail.”

“What this means,” Debbie continues, “is that the three of us will be creating these tests together to make sure that we all have a clear understanding of what a requirement means. When a requirement is delivered, it will work as understood.”

“I really don’t know anything about testing,” Cathy states. “So how will I help?”

Debbie replies, “The test creation starts with getting examples from you on how a requirement should work. Tom and I can take these examples and turn them into the actual tests.”

“We will not be doing this up front for all the requirements. As you decide what the next requirement to work on is, we’ll get together and work on the details. I know you have to work at the store and there is no room for us to set up our computers there. But because we’re only a couple of miles away and there is a great bike path between our places, we’ll ride over for these meetings. We’ve found that meeting face to face is much more effective than having a long conference call on the phone” [Cockburn01].

Cathy interjects, “I’m not always available. I have a lot of other work that Sam needs me to do.”

Debbie answers, “I understand. We’ll schedule the face-to-face meetings at your convenience. For things that are pretty standard in software, such as adding an item, Tom and I will make up the examples for the tests and then review them with you before I start implementing. If it’s a quick question, we’ll give you a call. The only thing we ask is that you get back to us relatively soon. We can often work on other pieces of the problem, but if the question regards something that is fundamental to the design, we’ll need a quick answer. And we’ll identify the difference between that which we need as soon as possible and that which can wait a little while. Of course, if the little while turns into a day or a week, your project will be delayed and there will be more costs.”

Lean and Agile Principles

ATDD is based on some lean principles and some agile principles. The lean principles come from Mary and Tom Poppendieck [Poppendieck02], [Poppendieck03], [Poppendieck04].⁴ The agile principles are listed in “The Agile Manifesto,” which is a widely recognized statement on how to better develop software [Agile01].

The Poppendiecks developed principles of lean software development derived from lean manufacturing. One principle is to reduce waste in a process. Creating acceptance tests up front reduces waste by decreasing the loopbacks from testing back to coding.

Another principle is to build in integrity. Acceptance tests for each portion of the system help to ensure that the modules are high quality. The tests are run as each module is developed, not when the developers have completed the entire system.

The collaboration between the members of the triad helps amplify learning, which is another lean principle. The members learn from each other about the business domain and the development and testing issues.

The triad is one manifestation of the Agile Manifesto principle that “business people and developers must work together daily throughout the project.” Although they may not be physically together, they will be working together continuously.

Another agile principle is that “working software is the primary measure of progress.” With the acceptance tests, Debbie and Tom can deliver not only working software, but software that delivers more precisely what Cathy is asking for.

Summary

• The triad consists of the three units—customer, developer, and tester—that collaborate to create high-quality software.

• Quick feedback is better than slow feedback. ATDD reduces unnecessary loopbacks.

• ATDD is lean and agile.