Sent	User	Okay to delete
N	Account Rep	Y

Sent	User	Okay to delete
N	CSR	Y
N	Manager	Y
N	Admin	Y

Sent	User	Okay to delete
Y	Account Rep	N
Y	CSR	N
Y	Manager	Audited
Y	Admin	Audited

Sent	User	Okay to delete
Printed	Account Rep	N
Exported	Account Rep	N
Posted to web	Account Rep	N
Emailed	Account Rep	N

Sent	User	Okay to delete
Emailed	Account Rep	N

James Shore

Let's Play TDD #3: Cleaning Up My Mess

Thu, 02 Sep 2010 00:00:00 PST

02 Sep 2010

James Shore/Blog/Lets-Play

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more.

Comments

Let's Play TDD #2: Peering Dimly Into the Future

Wed, 01 Sep 2010 00:00:00 PST

01 Sep 2010

James Shore/Blog/Lets-Play

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more.

Comments

Let's Play: Test-Driven Development

Tue, 31 Aug 2010 00:01:00 PST

31 Aug 2010

James Shore/Blog/Lets-Play

I'm trying a little experiment: a screencast of me working on a real project, from scratch, using test-driven development. I've called it "Let's Play: Test-Driven Development" in honor of all the Let's Play videos I love watching.

Like a "Let's Play" video, this is a live, stream-of-consciousness recording of my successes and slip-ups as I work. (So far, mostly slip-ups.) I'm hoping this will be an interesting view into how test-driven development works when you take it out of the classroom. As the series continues, I'm sure you'll see quite a bit of incremental design and architecture, too.

As I said, this is an experiment. I'm going to do several episodes and see what the response is like. So if you like it, let me know by leaving a comment on my blog, subscribing to my new Youtube channel, or helping spread the word. Feedback from people like you is how I'm going to judge whether I should keep going.

I hope you enjoy it.

Episode #1: "How Does This Thing Work, Again?"

Be sure to choose the 720p HD resolution for the most readable text.

Visit the Let's Play archive for more. For the first few comments on this entry, see the original announcement.

Comments

Let's Play: Test-Driven Development (Placeholder)

Tue, 31 Aug 2010 00:00:00 PST

31 Aug 2010

James Shore/Blog

I've moved this entry. I'm keeping this placeholder to preserve the comments.

Comments

Agile Friday: "Is XP Right For Us?" Now Online

Fri, 27 Aug 2010 00:00:00 PST

27 Aug 2010

James Shore/Blog

One of the things about The Art of Agile Development that I'm most proud of is our continuous acknowledgement that one size doesn't fit all. We were writing a cookbook, after all, with specific instructions and guidance. We could have easily pretended that our advice was The One Right Way to practice Agile.

I'm glad we didn't fall to that temptation. It's not true, of course; there are many good ways to practice Agile. (Sadly, there are an infinite number of bad ways to practice Agile, and they're easier to find than good ways.) So we had to do what authors have always had to do: choose between being narrow and deep, or broad and shallow.

Obviously, we chose "narrow and deep." This week's excerpt, Is XP Right For Us?, was our attempt to have our cake and eat it too. We couldn't go broad, but we could at least be clear about what we were covering and what we weren't. Doing so gave us the opportunity to discuss the tradeoffs involved, too. I'm very happy with the result.

Next Week

The Thinking chapter is completely online, as I've mentioned, so next week's excerpt will be from the Collaborating chapter. We have four practices left to put online from that chapter. Which one would you like next week?

I'll look for your vote in the comments.

Comments

The Art of Agile Development: Chapter 4: Adopting XP

Fri, 27 Aug 2010 00:00:00 PST

27 Aug 2010

James Shore/Agile-Book

Full Text

Adopting XP

"I can see how XP would work for IT projects, but product development is different." —a product development team

"I can see how XP would work for product development, but IT projects are different." —an in-house IT development team

Before adopting XP, you need to decide whether it's appropriate for your situation. Often, people's default reaction to hearing about XP is to say, "Well, of course that works for other teams, but it couldn't possibly work for us."

XP's applicability is based on organizations and people, not types of projects.

Question that assumption. I've helped a wide variety of teams adopt XP: 20-person teams and one-person teams; huge corporations and small startups; shrinkwrap, in-house, and outsourced software vendors; proprietary and open source developers. Through these experiences, I've learned that software teams are more similar than they are different. XP's applicability has far more to do with your organization and the people involved than the type of project you're working on.

Comments

The Art of Agile Development: Is XP Right For Us?

Fri, 27 Aug 2010 00:00:00 PST

27 Aug 2010

James Shore/Agile-Book

in 99 words

You'll need support, from managers and colleagues. Work together, in the same room, and include business experts. Keep the team small--five to twenty people. Don't ignore practices: they're more important than they seem.

A brand-new codebase and a language that's easy to refactor are best for learning. Try to include an experienced coach, and an experienced designer. It's best if everyone gets along.

You don't have to do any of these if you don't want to. (We provide alternatives.) But you'll have more success, and more fun, if you fix your environment rather than compromising your work.

as haiku

slippery, muddy--
where grass died, pepperbushes
provide fragrant blooms

Behind the Scenes

Truth or Clarity?

Poster

Download this poster!

Full Text

Is XP Right For Us?

You can adopt XP in a wide variety of conditions, although the practices you use will vary depending on your situation. The practices in this book were chosen to give you the greatest chance of success. That leads to some prerequisites and recommendations about your team's environment. You don't have to meet these criteria exactly, but it's worth trying to change your environment so that you do. That will give you the best chance of succeeding.

As Martin Fowler said:¹

¹http://martinfowler.com/bliki/EnterpriseRails.html.

In this sense I see a startling parallel between DHH [David Heinemeier Hansson, creator of Ruby on Rails] and Kent Beck. For either of them, if you present them with a constrained world, they'll look at constraints we take for granted, consider them to be unessential, and create a world without them. I don't have that quality, I tend to try to work within the constraints gradually pushing at them, while they just stick some intellectual dynamite under them and move on. That's why they can create things like Extreme Programming and Rails which really give the industry a jolt.

In other words, if your organization puts a barrier between your work and success, don't just put up with it... find a way to remove it. It's your best path to success.

Similarly, if you want to practice XP, do everything you can to meet the following prerequisites and recommendations. It's a lot more effective than working around limitations.

Prerequisite #1: Management Support

It's very difficult to use XP in the face of opposition from management. Active support is best. To practice XP as described in this book, you will need the following:

A common workspace with pairing stations (see Sit Together in Chapter 6)
Team members solely allocated to the XP project (see The XP Team in Chapter 3)
A product manager, on-site customers, and integrated testers (also discussed in The XP Team in Chapter 3)

You will often need management's help to get the previous three items. In addition, the more management provides the following things, the better:

Team authority over the entire development process, including builds, database schema, and version control
Compensation and review practices that are compatible with team-based effort
Acceptance of new ways of demonstrating progress and showing results (see Reporting in Chapter 6)
Patience with lowered productivity while the team learns

If Management Isn't Supportive...

In order for management to support your adoption of XP, they need to believe in its benefits. Think about what the decision-makers care about. What does an organizational success mean to your management? What does a personal success mean? How will adopting XP help them achieve those successes? What are the risks of trying XP, how will you mitigate those risks, and what makes XP worth the risks? Talk in terms of your managers' idea of success, not your own success.

If you have a trusted manager you can turn to, ask for her help and advice. If not, talk to your mentor (see "Find a Mentor" in Chapter 2). Fearless Change: Patterns for Introducing New Ideas [Manns & Rising] is another good resource.

If management refuses your overtures, then XP probably isn't appropriate for your team. You may be able to demonstrate XP's value incrementally by adopting some standalone practices (see "Extremeties: Applying Bits and Pieces of XP," later in this chapter).

Prerequisite #2: Team Agreement

Just as important as management support is the team's agreement to use XP. If team members don't want to use XP, it's not likely to work. XP assumes good faith on the part of team members—there's no way to force the process on somebody who's resisting it.

If People Resist...

It's never a good idea to force someone to practice XP against his will. In the best case, he'll find some way to leave the team, quitting if necessary. In the worst case, he'll remain on the team and silently sabotage your efforts.

Reluctant skeptics are okay. If somebody says, "I don't want to practice XP, but I see that the rest of you do, so I'll give it a fair chance for a few months," that's fine. She may end up liking it. If not, after a few months have gone by, you'll have a better idea of what you can do to meet the whole team's needs.

One way to help people agree to try XP is to promise to revisit the decision on a specific date. (Allow two or three months if you can.) At that point, if the team doesn't want to continue using XP, stop.

If only one or two people refuse to use XP and they're interested in working on another project, let them transfer so the rest of the team can use XP. If no such project is available, or if a significant portion of the team is against using XP, don't use it.

Prerequisite #3: A Colocated Team

XP relies on fast, high-bandwidth communication for many of its practices. In order to achieve that communication, your team needs to sit together in the same room.

If Your Team Isn't Colocated...

Colocation makes a big difference in team effectiveness. Don't assume that your team can't sit together; be sure to include the possibility of bringing the team together is your first option.

With that said, it's okay if one or two noncentral team members are off-site some of the time. You'll be surprised, though, at how much more difficult it is to interact with them. (Actually, they're no more difficult to interact with than before; it's the rest of the team that's improved.) Talk with your mentor about how to best deal with the problem.

If a lot of people are off-site, if a central figure is often absent, or if your team is split across multiple locations, you need help beyond this book. You can use XP or another agile method with a distributed team, but it's a complicated problem that's outside of the scope of our discussion. Ask your mentor for help and see Sit Together in Chapter 6 for more ideas.

Prerequisite #4: On-Site Customers

The on-site customers' decisions determine the value of the software.

On-site customers are critical to the success of an XP team. They, led by the product manager, determine which features the team will develop. In other words, their decisions determine the value of the software.

Of the on-site customers, the product manager is likely the most important. She makes the final determination of value. A good product manager will choose features that provide value to your organization. A poor product manager will dither time away on inconsequential features.

Domain experts, and possibly interaction designers, are also important. They take the place of an upfront requirements phase, sitting with the team to plan upcoming features and answering questions about what the software needs to do.

If Your Product Manager is Too Busy to Be On-Site...

If you have an experienced product manager who makes high-level decisions about features and priorities, but who isn't available to sit with the team full-time, you may be able to ask a business analyst or one of the other on-site customers to act as a proxy. The proxy's job is to act in the product manager's stead to make decisions about details while following the actual product manager's high-level decisions.

This can work well if your proxy has the authority to act in place of the product manager. If the proxy is unable to answer questions on his own and needs to confirm every decision with the real product manager, he will introduce too many delays for this book's approach to XP to work well.

If Your Product Manager is Inexperienced...

This may be okay as long as she has a more experienced colleague she turns to for advice.

If You Can't Get a Product Manager At All...

Although good product managers are in high demand, the absence of a product manager is a big danger sign. The right person for the job may not have the title of "product manager" (see Real Customer Involvement in Chapter 6), but XP requires that somebody with business expertise take responsibility for determining and prioritizing features.

Remind your organization of the cost of development (presumably, hundreds of thousands of dollars) and the value the software will bring to them (hopefully, millions of dollars). That value hinges on the participation of a good product manager. Is that really something they want to scrimp on?

If you can't find a product manager, someone from the development team can play the part. However, this may be a dangerous approach, because this person is unlikely to have the business expertise to deliver an organizational success. If you can't get a product manager, talk with your mentor about how to compensate.

If You Can't Get Other On-Site Customers...

Because XP doesn't have an up-front requirements phase, the work of figuring out requirements happens concurrently with software development. This compresses the overall schedule, but it means that at least one person—and usually several—needs to work on requirements full-time.

Unless you have a small team, this work is probably more than a product manager can handle alone. Typically, the product manager delegates the details to a set of domain experts. In applications that involve a sophisticated user interface, a interaction designer may be involved as well. This allows the product manager to focus on coordinating with stakeholders and resolving questions of value and priorities.

Some business analysts may be domain experts. Be careful of using business analysts that aren't already experts in the domain; although they can relay information from true experts, this process invariably introduces misunderstandings and delays.

As long as somebody is playing the on-site customer role, you can use XP. However, the less expertise your on-site customers have, the more risk there is to the value of your software.

Prerequisite #5: The Right Team Size

I wrote this book for teams as large as 20 people and as small as one person. For teams new to XP, however, I recommend four to six programmers and no more than 12 people on the team (see The XP Team in Chapter 3). I also recommend having an even number of programmers so that everyone can pair program (see Pair Programming in Chapter 5). If you have ongoing support needs, add one more programmer for a total of five or seven so the team can have a batman (see Iteration Planning in Chapter 8).

Teams with fewer than four programmers are less likely to have the intellectual diversity they need. They'll also have trouble using pair programming, an important support mechanism in XP. Large teams introduce coordination challenges. Although experienced teams will handle those challenges smoothly, a new XP team will struggle.

If You Don't Have Even Pairs...

The easiest solution is to add or drop one programmer so you have even pairs. If you can't do that, the XP practices are still appropriate for you, but try to find useful nonproduction code work for the programmer who isn't pairing. This will help the team consistently apply XP's technical practices and will improve code quality.

If Your Team is Larger than Seven Programmers...

The coordination challenges of a large team can make learning XP more difficult. Consider hiring an experienced XP coach to lead the team through the transition. You may also benefit from hiring another experienced XP programmer to assist the coach in mentoring the team.

If your team is larger than ten programmers, you need guidance that's outside of the scope of this book. Hire a coach with experience in scaling XP to large teams.

If Your Team is Smaller Than Four Programmers...

Most of the XP practices are still appropriate for you, but you probably won't be able to pair program much. In this situation, it's best if your team members are conscientious programmers who are passionate about producing high-quality code. That passion will help them apply the technical practices with discipline.

You may have trouble getting on-site customers to sit with you full-time. Instead, sit close to them so that you can get their attention when you need it.

If You Have Many Developers Working Solo...

Some organizations—particularly IT organizations—have a lot of small projects rather than one big project. They structure their work to assign one programmer to each project.

Although this approach has the advantage of connecting programmers directly with projects, it has several disadvantages. It's high risk: every project is the responsibility of one programmer, so that any programmer who leaves orphans a project. Her replacement may have to learn it from first principles.

Code quality can also be a challenge. Projects don't benefit from peer review, so the code is often idiosyncratic. Stovepipe systems, in which each programmer solves the same problem in different ways, appear. Junior programmers, lacking the guidance of their more senior peers, create convoluted, kludgey systems and have few opportunities to learn better approaches. Senior programmers, not realizing the inexperience of their more junior peers, create overly sophisticated code that others have trouble understanding.

You may be able to combine four to seven of these programmers into a single XP team that works on one project at a time, which allows it to complete projects more quickly (see Release Planning in Chapter 8). By working together, senior developers have the opportunity to mentor junior developers, and the team can eliminate stovepipe systems.

Combining your programmers into a single team has some drawbacks. The biggest is likely to be a perceived lack of responsiveness. Although projects will be finished more quickly, customers will no longer have a dedicated programmer to talk to about the status of their projects. The team will only work on one project at a time, so other customers may feel they are being ignored.

To resolve these problems, consider dedicating one programmer to deal with customer requests and minor changes (see Iteration Planning in Chapter 8). You'll also need an influential, unbiased business person to play the product manager role, addressing conflicts between customers and making prioritization decisions.

Prerequisite #6: Use All the Practices

You may be tempted to ignore or remove some practices, particularly the ones that make team members uncomfortable. Be careful of this. XP is designed to have very little waste. Nearly every practice directly contributes to the production of valuable software.

For example, pair programming supports collective code ownership, which is necessary for refactoring. Refactoring allows incremental design and architecture. Incremental design and architecture enables customer-driven planning and frequent releases, which are the key to XP's ability to increase value and deliver successful software.

XP doesn't require perfection—it's okay if you accidentally misapply a practice from time to time—but it rarely works well if you arbitrarily remove pieces.

If Practices Don't Fit...

You may feel that some XP practices aren't appropriate for your organization. That may be true, but it's possible you just feel uncomfortable or unfamiliar with a practice. Are you sure that practice won't work, or do you just not want to do it? XP will work much better for you if you give all of the practices a fair chance rather than picking and choosing the ones you like.

If you're sure a practice won't work, you need to replace it. For example, in order to achieve the benefits of collective code ownership without pair programming, you must provide another way for people to share knowledge about the codebase. (You'll also have to find ways to replace the other benefits of pairing.)

Replacing practices requires continuous refinement and an in-depth understanding of XP. Ask your mentor for help and consider hiring an experienced XP coach.

Recommendation #1: A Brand-New Codebase

Easily-changed code is vital to XP. If your code is cumbersome to change, you'll have difficulty with XP's technical practices, and that difficulty will spill over into XP's planning practices.

XP teams put a lot of effort into keeping their code clean and easy to change. If you have a brand-new codebase, this is easy to do. If you have to work with existing code, you can still practice XP, but it will be more difficult. Even well-maintained code is unlikely to have the simple design and suite of automated unit tests that XP requires (and produces). New XP teams often experience an epiphany between the second and fourth months. "This is the best code I've ever worked with!" they say, and start to see the power of XP.

To understand and appreciate XP's technical practices fully, you need to experience the practices meshing together to give you complete confidence in your code, tests, and build. You need to feel the delight of making big improvements with small changes. You're unlikely to have that experience when working with existing code. If you can, save preexisting code for experienced XP teams.

If You Have Preexisting Code...

You can dig your way out of this hole. See "Applying XP to an Existing Project," later in this chapter.

Recommendation #2: Strong Design Skills

Simple, easily-changed design is XP's core enabler. This means at least one person on the team—preferably a natural leader—needs to have strong design skills.

It's hard to tell if somebody has strong design skills unless you have strong design skills yourself. One clue to look for is an understanding and appreciation of domain-driven design. It requires a crucial shift in thinking—from imperative procedural design to declarative object-oriented design—that programmers with poor design skills can have difficulty grasping.

If No One Has Strong Design Skills...

You'll probably do as well with XP as you would be with any method—perhaps more, because XP includes specific technology practices and advice. However, that doesn't mean you'll be successful. Take it slow and steady, and seek out as much experienced help as you can get.

Meanwhile, start learning! [Evans]' Domain-Driven Design is a good place to start, as is [Fowler 2002a]'s Patterns of Enterprise Application Architecture. Consider taking a course or hiring somebody to join the team as a mentor. Be careful, though—strong design skills, while essential, are surprisingly rare. Ask someone with good design skills to help you vet your choice.

Recommendation #3: A Language That's Easy to Refactor

XP relies on refactoring to continuously improve existing designs, so any language that makes refactoring difficult will make XP difficult. Of the currently popular languages, object-oriented and dynamic languages with garbage collection are the easiest to refactor. C and C++, for example, are more difficult to refactor.

If Your Language Is Hard To Refactor...

You can still use XP, but be sure to include someone on your team who has experience with refactoring in your language, if you can.

Recommendation #4: An Experienced Programmer-Coach

Some people are natural leaders. They're decisive, but appreciate others' views; competent, but respectful of others' abilities. Team members respect and trust them. You can recognize a leader by her influence—regardless of her title, people turn to a leader for advice.

Leadership is independent of title or position. You can identify leaders by their followers, not by their desire to give orders. To identify the real leaders on your team, look for the people that team members want to follow.

XP relies on self-organizing teams. Such a team doesn't have a predefined hierarchy; instead, the team decides for itself who is in charge of what. These roles are usually informal. In fact, in a mature XP team, there is no one leader. Team members seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved.

When your team first forms, though, it won't work together so easily. Somebody will need to help the team remember to follow the XP practices consistently and rigorously. This is particularly important for programmers, who have the most difficult practices to learn.

In other words, your team needs a coach. The best coaches are natural leaders—people who remind others to do the right thing by virtue of who they are rather than the orders they give. Your coach also needs to be an experienced programmer so she can help the team with XP's technical practices.

If You Have No Obvious Coach...

Explain the situation to the team and ask them to choose a coach by consensus. In other words, ask them to pick one person that they can all agree would be a good coach.

In consensus decisions, everyone has a veto. A quick way to perform a consensus vote is to ask everyone to hold their thumbs out. Thumbs up means "I agree". Thumbs sideways means "I'll go with the team's decision." Thumbs down means "I disagree and want to explain why."

If you can't pick a coach by consensus, your team may be too fractured to use XP. If there's someone you can hire that the team would trust, that may help. Be sure to tell whoever you hire that you weren't able to reach consensus on this issue—an experienced XP coach will see it as a danger sign and should speak to team members before accepting.

If Your Leaders are Inexperienced...

Good leaders aren't always experienced developers, but a good coach should look for subtle cues that indicate upcoming problems, which does require experience. An experienced developer is your best coach.

If your leaders are inexperienced, you may want to try pair coaching. Pick one person who's a good leader and one person who has a lot of experience. Make sure they get along well. Ask the two coaches to work together to help the team remember to practice XP consistently and rigorously.

If You're Assigned a Poor Coach...

Your organization may assign somebody to be coach who isn't a good leader. In this case, if the assigned coach recognizes the problem, pair coaching may work for you.

If the assigned coach doesn't recognize the problem and he's damaging the team's ability to function, discuss the situation with your mentor or a manager you trust. This is a delicate situation that requires context-specific advice.

Recommendation #5: A Friendly and Cohesive Team

XP requires that everybody work together to meet team goals. There's no provision for someone to work in isolation, so it's best if team members enjoy working together.

If Your Team Doesn't Get Along...

XP requires people to work together. Combined with the pressure of weekly deliveries, this can help team members learn to trust and respect each other. However, it's possible for a team to implode from the pressure. Try including a team member who is level-headed and has a calming influence.

If team members won't even attempt to work together, don't use XP. If there's just one person whose behavior encourages other people's bad behavior, you might be able to solve the problem by moving him to a different team.

Comments

The Art of Agile Development: Customer Tests

Fri, 20 Aug 2010 00:00:00 PST

20 Aug 2010

James Shore/Agile-Book

New Information

Although I still fully embrace using the Describe, Demonstrate, Develop process described for this practice, I've found that using tools such as Fit to automate those examples results in unacceptable maintenance burdens. The value is in the collaborative Describe, Demonstrate, Develop process, not the automated tests. I recommend ignoring the final section of this practice, "Automating the Examples." Everything else is still correct.

I describe the reasons for this change of heart in The Problems With Acceptance Testing. In Alternatives to Acceptance Testing, I explain what to do instead.

Full Text

Customer Tests

Audience: Whole Team

We implement tricky domain concepts correctly.

Ally: Ubiquitous Language

Customers have specialized expertise, or domain knowledge, that programmers don't have. Some areas of the application—what programmers call domain rules—require this expertise. You need to make sure that the programmers understand the domain rules well enough to code them properly in the application. Customer tests help customers communicate their expertise.

Ally: Ten-Minute Build

Don't worry; this isn't as complicated as it sounds. Customer tests are really just examples. Your programmers turn them into automated tests, which they then use to check that they've implemented the domain rules correctly. Once the tests are passing, the programmers will include them in their ten-minute build, which will inform the programmers if they ever do anything to break the tests.

To create customer tests, follow the Describe, Demonstrate, Develop process outlined in the next section. Use this process during the iteration in which you develop the corresponding stories.

Describe

Customer tests are for communication.

At the beginning of the iteration, look at your stories and decide whether there are any aspects that programmers might misunderstand. You don't need to provide examples for everything. Customer tests are for communication, not for proving that the software works. (See No Bugs in Chapter 7).

For example, if one of your stories is "Allow invoice deleting", you don't need to explain how invoices are deleted. Programmers understand what it means to delete something. However, you might need examples that show when it's okay to delete an invoice, especially if there are complicated rules to ensure that invoices aren't deleted inappropriately.

If you're not sure what the programmers might misunderstand, ask. Be careful, though; when business experts and programmers first sit down to create customer unit tests, both groups are often surprised by the extent of existing misunderstandings.

Once you've identified potential misunderstandings, gather the team at a whiteboard and summarize the story in question. Briefly describe how the story should work and the rules you're going to provide examples for. It's okay to take questions, but don't get stuck on this step.

For example, if you decided to discuss invoice deletion, you might say:

Customer: One of the stories in this iteration is to add support for deleting invoices. In addition to the screen mockups we've given you, we felt some customer tests would be appropriate. Deleting invoices isn't as simple as it appears because we have to maintain an audit trail.

There are a bunch of rules around this issue. I'll get into the details in a moment, but the basic rule is that it's okay to delete invoices that haven't been sent to customers because presumably that kind of invoice was a mistake. Once an invoice has been sent to a customer, it can only be deleted by a manager. Even then, we have to save a copy for auditing purposes.

Programmer: When an invoice hasn't been sent and gets deleted, is it audited?

Customer: No—in that case, it's just deleted. I'll provide some examples in a moment.

Demonstrate

After a brief discussion of the rules, provide concrete examples that illustrate the scenario. Tables are often the most natural way to describe this information, but you don't need to worry about formatting. Just get the examples on the whiteboard.

Customer (continued): As an example, this invoice hasn't been sent to customers, so an Account Rep can delete it.

Sent User Okay to delete
N Account Rep Y

In fact, anybody can delete it—CSR's, managers, and admins.

Sent User Okay to delete
N CSR Y
N Manager Y
N Admin Y

But once it's sent, only managers and admins can delete it, and even then it's audited.

Sent User Okay to delete
Y Account Rep N
Y CSR N
Y Manager Audited
Y Admin Audited

Also, it's not a simple case of whether something has been "sent" or not. "Sent" actually means one of several conditions. If you've done anything that could have resulted in a customer seeing the invoice, we consider it "sent". Now only a manager or admin can delete it.

Sent User Okay to delete
Printed Account Rep N
Exported Account Rep N
Posted to web Account Rep N
Emailed Account Rep N

As you provide examples, be completely specific. It's tempting to create generic examples, such as "this invoice hasn't been sent to customers, so anybody can delete it", but those get confusing quickly and programmers can't automate them. Provide specifics. "This invoice hasn't been sent to customers, so an account rep can delete it." This will require you to create more examples—that's a good thing.

Your discussion probably won't be as smooth and clean as this example. As you discuss business rules, you'll jump back and forth between describing the rules and demonstrating them with examples. You'll probably discover special cases that you hadn't considered. In some cases, you might even discover whole new categories of rules that you need customer tests for.

One particularly effective way to work is to elaborate on a theme. Start by discussing the most basic case and providing a few examples. Next, describe a special case or additional detail and provide a few more examples. Continue in this way, working from simplest to most complicated, until you have described all aspects of the rule.

You don't need to show all possible examples. Remember, the purpose here is to communicate, not to exhaustively test the application. You only need enough examples to show the differences in the rules. A handful of examples per case is usually enough, and sometimes just one or two is sufficient.

Develop

When you've covered enough ground, document your discussion so the programmers can start working on implementing your rules. This is also a good time to evaluate whether the examples are in a format that works well for automated testing. If not, discuss alternatives with the programmers.

Programmer: Okay, I think we understand what's going on here. We'd like to change your third set of examples, though—the ones where you say "Y" for Sent. Our invoices don't have a "Sent" property. We'll calculate that from the other properties you mentioned. Is it okay if we use "Emailed" instead?

Customer: Yeah, that's fine. Anything that sends it works for that example.

Don't formalize your examples too soon. While you're brainstorming, it's often easiest to work on the whiteboard. Wait until you've worked out all the examples around a particular business rule (or part of a business rule) before formalizing it. This will help you focus on the business rule rather than formatting details.

In some cases, you may discover that you have more examples and rules to discuss than you realized. The act of creating specific examples often reveals scenarios you hadn't considered. Testers are particularly good at finding these. If you have a lot of issues to discuss, consider letting some or all of the programmers get started on the examples you have while you figure out the rest of the details.

Don't use customer tests as a substitute for test-driven development.

Ally: Test-Driven Development

Programmers, once you have some examples, you can start implementing the code using normal test-driven development. Don't use the customers' tests as a substitute for writing your own tests. Although it's possible to drive your development with customer tests—in fact, this can feel quite natural and productive—the tests don't provide the fine-grained support that TDD does. Over time, you'll discover holes in your implementation and regression suite. Instead, pick a business rule, implement it with TDD, then confirm that the associated customer tests pass.

Focus on Business Rules

One of the most common mistakes in creating customer tests is describing what happens in the user interface rather than providing examples of business rules. For example, to show that an account rep must not delete a mailed invoice, you might make the mistake of writing this:

Log in as an account rep
Create new invoice
Enter data
Save invoice
Email invoice to customer
Check if invoice can be deleted (should be "no")

What happened to the core idea? It's too hard to see. Compare that to the previous approach:

When an invoice has been emailed, an account rep may not delete it... or, as you might draw it on the whiteboard:

Sent User Okay to delete
Emailed Account Rep N

Good examples focus on the essence of your rules. Rather than imagining how those rules might work in the application, just think about what the rules are. If you weren't creating an application at all, how would you describe those rules to a colleague? Talk about things rather than actions. Sometimes it helps to think in terms of a template: "When (scenario X), then (scenario Y)."

It takes a bit of practice to think this way, but the results are worth it. The tests become more compact, easier to maintain, and (when implemented correctly) faster to run.

Ask Customers to Lead

Remember the "Customer" in "Customer Tests".

Team members, watch out for a common pitfall in customer testing: no customers! Some teams have programmers and testers do all the work of customer testing, and some teams don't involve their customer at all. In others, a customer is present only as a mute observer. Don't forget the "customer" in "customer tests." The purpose of these activities to bring the customers' knowledge and perspective to the team's work. If programmers or testers take the reins, you've lost that benefit and missed the point.

In some cases, customers may not be willing to take the lead. Programmers and testers may be able to solve this problem by asking the customers for their help. When programmers need domain expertise, they can ask customers to join the team as they discuss examples. One particularly effective technique is to ask for an explanation of a business rule, pretend to be confused, then hand a customer the whiteboard marker and ask him to draw an example on the board.

If customers won't participate in customer testing at all, this may indicate a problem with your relationship with the customers. Ask your mentor (see "Find a Mentor" in Chapter 2) to help you troubleshoot the situation.

Testers' Role

Testers play an important support role in customer testing. Although the customers should lead the effort, they benefit from testers' technical expertise and ability to imagine diverse scenarios. While customers should generate the initial examples, testers should suggest scenarios that customers don't think of.

On the other hand, testers should be careful not to try to cover every possible scenario. The goal of the exercise is to help the team understand the customers' perspective, not to exhaustively test the application.

Automating the Examples

Programmers may use any tool they like to turn the customers' examples into automated tests. Ward Cunningham's Fit (Framework for Integrated Test)¹, is specifically designed for this purpose. It allows you to use HTML to mix descriptions and tables, just as in my invoice auditing example, then runs the tables through programmer-created fixtures to execute the tests.

¹Available free at http://fit.c2.com/.

See http://fit.c2.com/ or [Mugridge & Cunningham] for details about using Fit. It's available in several languages, including Java, .NET, Python, Perl, and C++.

You may be interested in FitNesse at http://fitnesse.org/, a variant of Fit. FitNesse is a complete IDE for Fit that uses a Wiki for editing and running tests. (Fit is a command-line tool and works with anything that produces tables in HTML.)

Ally: Exploratory Testing

Fit is a great tool for customer tests because it allows customers to review, run, and even expand on their own tests. Although programmers have to write the fixtures, customers can easily add to or modify existing tables to check an idea. Testers can also modify the tests as an aid to exploratory testing. Because the tests are written in HTML, they can use any HTML editor to modify the tests, including Microsoft Word.

Programmers, don't make Fit too complicated. It's a deceptively simple tool. Your fixtures should work like unit tests, focusing on just a few domain objects. For example, the invoice auditing example would use a custom ColumnFixture. Each column in the table corresponds to a variable or method in the fixture. The code is almost trivial (see Example 9-1).

Example 9-1. Example fixture (C#)

  public class InvoiceAuditingFixture : ColumnFixture
  {
      public InvoiceStatus Sent;
      public UserRole User;

      public Permission OkayToDelete() {
          InvoiceAuditer auditer = new InvoiceAuditer(User, InvoiceStatus)
          return auditer.DeletePermission;
      }
  }

Ally: Ubiquitous Language

Using Fit in this way requires a ubiquitous language and good design. A dedicated domain layer with Whole Value objects² works best. Without it, you may have to write end-to-end tests, with all the challenges that entails. If you have trouble using Fit, talk to your mentor about whether your design needs work.

²See Domain-Driven Design [Evans] for a discussion of domain layers and http://c2.com/ppr/checks.html#1 [Cunningham] for information about Whole Value.

I often see programmers try to make a complete library of generic fixtures so that no one need write another fixture. That misses the point of Fit, which is to segregate customer tests from programmer implementation. If you make generic fixtures, the implementation details will have to go into the tests, which will make them too complicated and obscure the underlying examples.

Most tests can be expressed with a simple ColumnFixture or RowFixture.

Questions

When do programmers run the customer tests?

Ally: Ten-Minute Build

Once the tests are passing, make them a standard part of your ten-minute build. Like programmers' tests, you should fix them immediately if they ever break.

Should we expand the customer tests when we think of a new scenario?

Ally: Slack

Absolutely! Often, the tests will continue to pass. That's good news; leave the new scenario in place to act as documentation for future readers. If the new test doesn't pass, talk with the programmers about whether they can fix it with iteration slack or whether you need a new story.

What about acceptance testing (also called functional testing)?

Ally: No Bugs

Automated acceptance tests tend to be brittle and slow. I've replaced acceptance tests with customer reviews (see "Customer Reviews" later in this chapter) and a variety of other techniques (see "A Little Lie" in Chapter 3).

Results

Ally: Ubiquitous Language

When you use customer tests well, you reduce the number of mistakes in your domain logic. You discuss domain rules in concrete, unambiguous terms and often discover special cases that you hadn't considered. The examples influence the design of the code and help promote a ubiquitous language. When written well, the customer tests run quickly and require no more maintenance than unit tests do.

Contraindications

Ally: Test-Driven Development

Don't use customer tests as a substitute for test-driven development. Customer tests are a tool to help communicate challenging business rules, not a comprehensive automated testing tool. In particular, Fit doesn't work well as a test scripting tool—it doesn't have variables, loops, or subroutines. (Some people have attempted to add these things to Fit, but it's not pretty.) Real programming tools, such as xUnit or Watir, are better for test scripting.

Allies: Whole Team; Sit Together

In addition, customer tests require domain experts. The real value of the process is the conversation that explores and exposes the customers' business requirements and domain knowledge. If your customers are unavailable, those conversations won't happen.

Finally, because Fit tests are written in HTML, Fit carries more of a maintenance burden than xUnit frameworks do. Automated refactorings won't extend to your Fit tests. To keep your maintenance costs down, avoiding creating customer tests for every business rule. Focus on the tests that will help improve programmer understanding, and avoid further maintenance costs by refactoring your customer tests regularly. Similar stories will have similar tests: consolidate your tests whenever you have the opportunity.

Alternatives

Some teams have testers, not customers, write customer tests. Although this introduces another barrier between the customers' knowledge and the programmers' code, I have seen it succeed. It may be your best choice when customers aren't readily available.

Customer tests don't have to use Fit or FitNesse. Theoretically, you can write them in any testing tool, including xUnit, although I haven't seen anybody do this.

Agile Friday: "Customer Tests" Now Online

Fri, 20 Aug 2010 00:00:00 PST

20 Aug 2010

James Shore/Blog

Controversy! After writing the Customer Tests section of The Art of Agile Development, I had a change of heart. I used to be a major advocate for customer testing--what people are now calling "Acceptance Test-Driven Development," or ATDD. In fact, I was the project coordinator for Ward Cunningham's Fit, the first major customer testing tool. But I no longer use or recommend it.

Why not? I explain the details in my Problems With Acceptance Testing blog entry, but the short-short version is that automated customer tests just don't work well over the long term. In the short term they're great. In the long-term, the tests become a major maintenance burden, and the tools tend to get in the way of customer collaboration rather than enhance it.

Luckily, I'm not a complete idiot. (Or Shane isn't. Hmm.) What we wrote in the book is still accurate, even though we wrote it before my change of heart. Shane and I actually highlight the problems in the "Contraindications" subsection. If I could do it over again, though, I'd call this practice "Customer Examples" rather than "Customer Tests." I'd focus on communication even more. I'd come up with some better examples. And I'd leave out the "Automating the Examples" subsection. But what we have in the book, other than the automation subsection, is still good advice.

Next week, I'm planning to post Is XP Right For Us? from Chapter 3. All of the practices we recommend so confidently in the rest of the book rely on an important set of assumptions that are described in that section. I figured it would be useful to put those assumptions online now that so much of the rest of the book is up. If you'd prefer something else, make your case in the comments, as usual.

See you next week!

Comments

Agile Friday: "Stories" Now Online

Fri, 06 Aug 2010 00:00:00 PST

06 Aug 2010

James Shore/Blog

I've uploaded Stories, which is this week's excerpt from The Art of Agile Development. Due to time constraints, I haven't incorporated the copyedits yet. If it seems a bit rough, that's why. Thanks once again to Sarah Schneider at O'Reilly for copyediting our book and making a million tiny improvements. You don't notice them until they're gone, which tells you what a good job Sarah did.

I'm going to be at Agile 2010 next week, presenting an awesome session with Arlo Belshee titled "Bloody Stupid Johnson Teaches Agile." It's a parody of all things Agile, and we're having tons of fun with it. If you're going to be at the conference, I hope you'll attend and help heckle. (We'll need hecklers.)

The poll for next week's excerpt will be cut short thanks to my trip, so get your votes in early. Here are your choices, from the Developing chapter:

Comments

James Shore

Let's Play TDD #3: Cleaning Up My Mess

Let's Play TDD #2: Peering Dimly Into the Future

Let's Play: Test-Driven Development

Episode #1: "How Does This Thing Work, Again?"

Let's Play: Test-Driven Development (Placeholder)

Agile Friday: "Is XP Right For Us?" Now Online

Next Week

The Art of Agile Development: Chapter 4: Adopting XP

Full Text

Adopting XP

The Art of Agile Development: Is XP Right For Us?

in 99 words

as haiku

Behind the Scenes

Poster

Full Text

Is XP Right For Us?

Prerequisite #1: Management Support

If Management Isn't Supportive...

Prerequisite #2: Team Agreement

If People Resist...

Prerequisite #3: A Colocated Team

If Your Team Isn't Colocated...

Prerequisite #4: On-Site Customers

If Your Product Manager is Too Busy to Be On-Site...

If Your Product Manager is Inexperienced...

If You Can't Get a Product Manager At All...

If You Can't Get Other On-Site Customers...

Prerequisite #5: The Right Team Size

If You Don't Have Even Pairs...

If Your Team is Larger than Seven Programmers...

If Your Team is Smaller Than Four Programmers...

If You Have Many Developers Working Solo...

Prerequisite #6: Use All the Practices

If Practices Don't Fit...

Recommendation #1: A Brand-New Codebase

If You Have Preexisting Code...

Recommendation #2: Strong Design Skills

If No One Has Strong Design Skills...

Recommendation #3: A Language That's Easy to Refactor

If Your Language Is Hard To Refactor...

Recommendation #4: An Experienced Programmer-Coach

If You Have No Obvious Coach...

If Your Leaders are Inexperienced...

If You're Assigned a Poor Coach...

Recommendation #5: A Friendly and Cohesive Team

If Your Team Doesn't Get Along...

The Art of Agile Development: Customer Tests

New Information

Full Text

Customer Tests

Describe

Demonstrate

Develop

Focus on Business Rules

Ask Customers to Lead

Testers' Role

Automating the Examples

Questions

When do programmers run the customer tests?

Should we expand the customer tests when we think of a new scenario?

What about acceptance testing (also called functional testing)?

Results

Contraindications

Alternatives

Further Reading

Agile Friday: "Customer Tests" Now Online

Agile Friday: "Stories" Now Online