An "on-site" customer is an Extreme Programming term for a member of a client company that temporarily becomes a member of a development team. This person provides domain-specific knowledge to help guide the programmers while they are creating a product.
To begin an exploration of this subject, let’s draw a parallel between the role of the on-site customer, and the role played by many members of the Delphi team when Delphi was first being created. .
Delphi was Built in Delphi
Delphi was great even in its very first release, and stayed great year after year. Most members of the Delphi team would agree that this was true in part because "Delphi was built in Delphi.". The developers of the team had to use Delphi, and more particularly the VCL, in order to create Delphi. This meant several things:
- The team found many of their own bugs, rather than relying on others to report them.
- The team knew which bugs to fix, because they knew which ones really caused them trouble
- The team was motivated to fix the bugs, because they needed working code so they could finish the VCL and the Delphi IDE.
- The team knew what features were missing from the VCL, because they knew which ones were holding up development.
- The team knew which features were missing from the IDE, and which one’s weren’t really necessary.
Put this all together, and what you have is the idea that Delphi was great in part because "Delphi was built in Delphi."
The On-site Customer
According to Scott Beck in his book "Extreme Programming Explained," the on-site customer has two roles:
- She can produce functional tests
- She can make small-scale priority and scope decisions for the programmers
It is interesting to note how these two ideas parallel the benefits the Delphi team derived from building Delphi in Delphi. For instance, knowing how to make priority and scope decisions requires the same kind of skills the Delphi team employed when discovering which VCL bugs to fix and which IDE features were necessary. An on-site customer will know intuitively which features are missing and which bugs are important, much as a Delphi team member knew intuitively what features were missing from the VCL and which bugs really needed to be fixed. The point is that the on-site customer uses the product every day, just as the Delphi team used Delphi every day.
It is a little harder, perhaps, to see how writing functional tests can be similar to the Delphi experience. However, a customer who works with an XP team is going to have access to daily builds. In XP programming, remember, the goal is to release a new version of the product at least once a month, preferably once every few weeks. Therefore, the on-site customer can be constantly using, and hence testing, the product, much as the Delphi team was constantly using, and hence testing, the Delphi language, the VCL, and the Delphi IDE. This knowledge can make an onsite customer an excellent candidate for designing tests, and for giving the team direction, at least in terms of the many small matters that can make a product excellent.
If you make one customer employee a member of your development team, then they have the inside knowledge necessary to help a team develop a high quality product.
Egos, Expertise and the Lines of Communication
Many developers are unlikely to approve of the idea of having a customer as a member of their development team. This enmity to the on-site customer has two sources:
There is an age old war between IT developers who create resources and the customers who consume those resources. Customers are used to being disappointed by IT products that don’t quite meet their needs, and so they distrust IT. Conversely, IT is used to being treated badly by customers, and so they have come to disdain the constant stream of complaints with which their work is often greeted.
Developers will have a tendency to dislike customers because they view them as non-technical. Customers just don’t have the expertise, some developers would claim, to work on the same team as a group of developers. Conversely, customers disdain developers as nerds who often lack social skills and who frequently don’t really understand the business for which their application is being created.
I think the first issue is really a matter of communication. Traditionally, customers and developers distrust and dislike one another because the lines of communication between them are down. Having an on-site customer is one way to open up those lines of communication. The on-site customer should improve the quality of the applications that are developed, and developers can warm to the customer if they meet on friendly, non-hostile ground.
On an XP team, the lines of communication between developers are open. They work in pairs, and all the team members are located inside a single room. The pairs aren’t static, and so everyone gets a chance to work with everyone else. This can be hard on great programmers, but it can be very beneficial to average programmers. Knowledge inside a team is easily shared, everyone knows who has strengths or weaknesses in particular areas, and code gets reviewed by more than one set of eyes.
If programmers can learn to work with one another, they can learn to work with a customer. After a time, they may learn to value an on-site customer’s domain expertise. Knowledge comes in many forms. A non-technical person who has a deep and intuitive knowledge of the way a department operates can teach developers a lot about the kind of application that department needs.
Success is a question of keeping the lines of communication open. Having an on-site customer does not guarantee that the lines of communication will be open, but it at least makes it possible. Without the on-site customer, the gap between developers and customers is too large, and it is unlikely that true communication will ever occur.
The Delphi team succeeded in part because the lines of communication between the consumer of a product and the developer of a product were very good. In fact, frequently the same person who needed to use a feature of Delphi was the person who created the feature. In the worst case scenario, they were at least on the same team.
An on-site customer in an XP team provides the same level of communication for a corporate project that the Delphi team had when creating Delphi. The on-site customer is a member of the team, and a regular user of the product.
Of course, an on-site customer does not guarantee success for a project. Communication can collapse if egos get in the way, if programmers become insulated and withdrawn, or if the customer refuses to accept the expense of sharing a good employee during the development cycle.
Despite these potential problems, XP at least offers a potential solution to a problem that plagues many development projects. The problem of communication is age old. XP offers one potential solution.