The Art of Agile Development: Real Customer Involvement

The second edition is now available! The Art of Agile Development has been completely revised and updated with all new material. Visit the Second Edition page for more information, or buy it on Amazon.

in 99 words

To widen your perspective, involve real customers. The best approach depends on your market.

Personal development: you are the real customer. Congratulations. Go forth and write algorithms.

In-house custom development: turn your real customers into on-site customers.

Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently.

Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing.

as haiku

roses, cucumbers--
I chose beauty, but Sensei
desires to eat


The Importance of Personal Success


'Project Community' poster

Download this poster!

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Real Customer Involvement


We understand the goals and frustrations of our customers and end-users.

An XP team I worked with included a chemist whose previous job involved the software that the team was replacing. She was an invaluable resource, full of insight about what did and didn't work with the old product. We were lucky to have her as one of our on-site customers—thanks to her, we created a more valuable product.

In an XP team, on-site customers are responsible for choosing and prioritizing features. The value of the product is in their hands. This is a big responsibility—as an on-site customer, how do you know which features to choose?

Some of that knowledge comes from your expertise in the problem domain and with previous versions of the software. You can't think of everything, though. Your daily involvement with the project, although crucial, includes the risk of tunnel vision—you could get so caught up in the daily details of the project that you lose track of your real customers' interests.

To widen your perspective, you need to involve real customers. The best approach to doing so depends on who you're building your software for.

Personal Development

In personal development, the development team is its own customer. They're developing the software for their own use. As a result, there's no need to involve external customers—the team is the real customer.

I include this type of development primarily for completeness. Most personal development is for small, throwaway applications that don't involve a full-blown XP team.

In-House Custom Development

In-house custom development occurs when your organization asks your team to build something for the organization's own use. This is classic IT development. It may include writing software to streamline operations, automation for the company's factories, or producing reports for accounting.

In this environment, the team has multiple customers to serve: the executive sponsor who pays for the software and the end-users who use the software. Their goals may not be in alignment. In the worst case, you may have a committee of sponsors and multiple user groups to satisfy.

Despite this challenge, in-house custom development makes it easy to involve real customers because they're easily accessible. The best approach is to bring your customers onto the team—to turn your real customers into on-site customers.

To do so, recruit your executive sponsor or one of his trusted lieutenants to be your product manager. He will make decisions about priorities, reflecting the desire of the executive sponsor to create software that provides value to the organization.

Also recruit some of the end-users of the software to act as domain experts. As with the chemist in the introduction, they will provide valuable information about how real people use the software. They will reflect the end-users' desire to use software that makes their jobs better.

If your software has multiple sponsors or user groups, use the ideas in "Vertical Market Software," later in this chapter.

Iteration Demo

To avoid tunnel vision, the product manager and other on-site customers should solicit feedback from their colleagues by demonstrating some of the builds created for the iteration demo and discussing their plans for the future.

Outsourced Custom Development

Outsourced custom development is similar to in-house development, but you may not have the connections that an in-house team does. As a result, you may not be able to recruit real customers to act as the team's on-site customers.

Still, you should try. One way to recruit real customers is to move your team to your customer's offices rather than asking them to join you at yours.

Release Planning

If you can't bring real customers on to the team, make an extra effort to involve them. Meet in person with your real customers for the first week or two of the project so you can discuss the project vision and initial release plan. If you're located near each other, meet again for each iteration demo, retrospective, and planning session.

If you're far enough apart that regular visits aren't feasible, stay in touch with instant messaging and phone conferences. Try to meet face-to-face at least once per month to discuss plans. If you are so far apart that monthly meetings aren't feasible, meet at least once per release.

Vertical-Market Software

Unlike custom development, vertical-market software is developed for many organizations. Like custom development, however, it's built for a particular industry and it's often customized for each customer.

Be careful about giving real customers too much control over vertical-market software.

Because vertical market software has multiple customers, each with customized needs, you have to be careful about giving real customers too much control over the direction of the product. You could end up making a product that, while fitting your on-site customer's needs perfectly, alienates your remaining customers.


Instead, your organization should appoint a product manager who understands the needs of your real customers impeccably. His job—and it's a tough one—is to take into account all of your real customers' needs and combine them into a single, compelling vision.

Iteration Demo

Rather than involving real customers as members of the team, create opportunities to solicit their feedback. Some companies create a customer review board filled with their most important customers. They share their release plans with these customers and—on a rotating basis—provide installable iteration demo releases for customers to try.

Depending on your relationship with your customers, you may be able to ask your customers to donate real end-users to join the team as on-site domain experts. Alternatively, as with the chemist in the introduction, you may wish to hire previous end-users to be your domain experts.

In addition to the close relationship with your customer review board, you may also solicit feedback through trade shows and other traditional sources.

Horizontal-Market Software

Horizontal-market software is the visible tip of the software development iceberg: software that's intended to be used across a wide range of industries. The rows of shrinkwrapped software boxes at your local electronics store are a good example of horizontal-market software. So are many web sites.

As with vertical-market software, it's probably better to set limits on the control that real customers have over the direction of horizontal-market software. Horizontal-market software needs to appeal to a wide audience and real customers aren't likely to have that perspective. Again, an in-house product manager who creates a compelling vision based on all customers' needs is a better choice.

As a horizontal-market developer, your organization may not have the close ties with customers that vertical-market developers do. Thus a customer review board may not be a good option for you. Instead, find other ways to involve customers: focus groups, user experience testing, community previews, beta releases, and so forth.

Web-based software, with its invisible deployment, offers a powerful option for involving real customers. You can roll out minimalist features, mark them "beta", and watch customer reactions. Another option, reportedly used by Amazon, is to deploy changes to a small percentage of visitors and observe how their usage patterns change.


Who should we use as on-site customers be when we can't include real customers on the team?

You organization should supply a product manager and domain experts. See The XP Team in Chapter 3.

We're creating a web site for our marketing department. What kind of development is that?

At first glance, this may seem like custom development, but because the actual audience for the web site is the outside world, it's closer to vertical-market or horizontal-market development. The product manager should come from the marketing department, if possible, but you should also solicit the input of people who will be visiting the site.


When you include real customers, you improve your knowledge about how they use the software in practice. You have a better understanding of their goals and frustrations and you use that knowledge to revise what your produce. You increase your changes of delivering a truly useful and thus successful product.



One danger of involving real customers is that they won't necessarily reflect the needs of all your customers. Be careful that they don't steer you towards creating software that's only useful for them. Your project should remain based on a compelling vision. Customer desires inform the vision and may even change it, but ultimately the product manager holds final responsibility for product direction.

End-users often think in terms of making their existing work better, rather than in terms of finding completely new ways of working. For this reason, end-users should be involved but not in control. If innovation is important to your project, give innovative thinkers—such as a visionary product manager or interaction designer—a prominent role on your team.


Real customer involvement is helpful but not crucial. Sometimes the best software comes from people who have a strong vision and pursue it vigorously. This software tends to be either completely new or a strong rethinking of existing products.

In the absence of real customer involvement, be sure to have a visionary product manager. It's best if this person understands the domain well, but you can also hire domain experts to join the team.

Still, feedback from real customers is always informative, even if you choose to ignore it. It's especially useful when you've deployed software to them; their reaction to working software gives you valuable information about how likely you are to reach the greatest levels of success.

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