What if you could best meet your customer’s need without writing any software? Would you do it? Could you do it?
Someday that may happen to you. It may not be as dramatic as telling a recurring customer that he’ll get better results if you don’t write software, but you may have to choose between delivering code and delivering business results.
Value isn’t really about software, after all. Your goal is to deliver something useful for the customer. The software is merely how you do that. The single most essential criterion for your success is the fitness of the project for its business purposes. Everything else is secondary—not useless by any means, but of lesser importance.
For example, agile teams value working software over comprehensive documentation. Documentation is valuable—communicating what the software must do and how it works is important—but your first priority is to meet your customer’s needs. Sometimes that means producing good documentation. Usually it means delivering good software, but not always. The primary goal is always to provide the most valuable business results possible.
XP encourages close involvement with actual customers by bringing them into the team, so they can measure progress and make decisions based on business value every day. Real customer involvement allows the on-site customer to review these values with end-users and keep the plan on track. Their vision provides answers to the questions most important to the project.
XP approaches its schedule in terms of customer value. The team works on stories phrased from the customer’s point of view and verifiable by customer testing. After each iteration, the iteration demo shows the team’s current progress to stakeholders, allowing them to verify that the results are valuable and to decide whether to continue development.
A friend—“Aaron”—recently spent a man-month writing 1,500 lines of prototype code that generated $7.8 million in revenue during its first demo.
As a graduate student, he interned with a technology company doing research on handwriting recognition with digital pens containing sensors and recording equipment. A customer made an off-hand remark about how useful it might be to use those special pens with printed maps. Suddenly, Aaron had a research assignment.
The largest potential customer used an existing software package to send map data to field agents to plan routes and identify waypoints. Aaron modified the pen software to send coordinate information on printed pages. Then he found a way to encode the pen’s necessary calibration data on color laser printouts. The final step was to use the API of the customer’s software to enter special pen events—mark waypoint, identify route, etc. In effect, all of his code merely replaced the clunky mouse-based UI with the act of drawing on a custom-printed map, then docking the pen.
A few minutes into the first demo, the customer led the sales rep to the control room for a field exercise. After installing the software and connecting the pen’s dock, the rep handed the pen and a printed map to one of the techs. The tech had never seen the product before and had no training, but he immediately circled an objective on the map and docked the pen. In seconds, the objective appeared on the vehicle displays as well as on the PDAs of the field agents.
The customer placed an order for a license and hardware for everyone at the location. That’s business results.