Customer satisfaction depends on the XP “circle of life”:
- the customer decides which features have value,
- programmers estimate the cost of providing the features,
- the customer chooses the best combination of features based on value and cost,
- programmers build the features, learning how to estimate costs in the process,
- the customer learns how to define value and how to make effective choices.
When this is done in a rapid development cycle, both sides learn, and prosper, in the process.
When a development organization serves a wide range of customers, or when customers cannot readily decide what to do and what to defer until later, teams sometimes add business analysts or product managers to the mix. Commonly, these individuals’ role is to “translate” the customers’ wishes to the programmers. The intent is to bring a measure of consistency to the overall product, and to make decisions about what to do in the face of the differing priorities of the customers. This translation is always a problem, and sometimes a very significant one.
The problem is this: the translation interferes with learning, in both directions.
- When programmers hear directly from real users what is wanted, they are inspired to learn and understand what the program needs to be.
- When customers are directly involved in using their own assessed value for features, and the estimated cost of the features, to select what to do and what to defer, they learn how to define valuable features which will have low cost.
- When programmers hear from customers how their work is being received, they learn how to understand what the customers want more readily.
- When customers see what they have asked for, they learn what they really wanted.
- When customers drive the process, they are invariably more satisfied with the results.
Placing analysts in the loop will inevitably transfer these benefits to the analyst-programmer interface, and this can be, in part, a good thing. The analysts will get the product they want, and will be more satisfied with the results. The programmers will learn how to please the analysts, and will learn how to become better estimators. This is good.
Inevitably, however, when the customers see the resulting product, they will be surprised. With lessened contact with programmers, it is harder for them to respect the programmers’ work, or to respect the estimates. Sometimes they respond by demanding more than the programmers can do, especially since the analysts are using different priorities from the individual customers.
If releases are made less frequently to the customers, there is less opportunity to learn what was really wanted, and there is a greater deviation between customer expectation and what is received. This can generate dissatisfaction which closer communication would have avoided.
Most important, when analysts translate between customers and programmers, the customers lose control. This loss is real, and they feel it. They feel less able to control their own destiny because they are less able to control their own destiny. The translation process isn’t helping them; it is getting in the way.
Teams using this model wisely add elements to dissipate these problems. They have regular meetings between analysts and customers. They communicate status frequently, explaining what is being done, and why. All these things take time, and they are being done to patch a fundamental mistake. The control loop between customer and programmer has been broken, reducing essential feedback, which must then be replaced by adding process elements.
The problem of ensuring that the product is consistent is a real problem, and it deserves a solution. However, we need to solve that problem without reducing real customer satisfaction, without reducing customer learning, without reducing programmer learning, because these things are essential elements in rapid, successful development.
The solution is simple and elegant: business analysts should work as aides to the customer, not as an interface between customer and programmer.
This begins with a simple change of focus, from “We’ll go out and find out what the customers want and bring it back”, to “We’ll go help the customers figure out what they want, so they can tell us”. This change of focus leaves control in the hands of the customers, and makes all the difference.
Rather than listening to the customer stories and “translating” them, the analysts help the customers express the stories clearly but still in their own words, just as the programmers would do when dealing with the customers directly. Where possible, the analysts will even involve some of the programmers in getting the stories. In either case, everyone makes sure that the stories belong to the customers, not to the analysts.
Rather than taking the varied priorities of multiple customers and deciding on overall priorities, the analysts get the customers together and help them sort things out. There are always some stories where the customers can agree that now is a good time to do them, or that they are OK to defer for now. This may leave some stories where the real customer priorities do not agree, and decisions need to be made. Perhaps each customer will be given a fraction of the available remaining programming days, to insert as many stories as will fit. Sometimes, customers may even trade these days back and forth: “I’ll give you my four days this iteration, if you’ll give me your four next iteration”.
In rare cases, the analysts may need to break a tie, deciding what is to be done and what is not. I’m not an arbitrator by trade or talent, but I would look to the literature on the principles of arbitration for ways to do this with the least friction.
In the end, the idea is to have all the customers understanding what makes up the next iteration, and the next release, and why. Allow the customers to feel as much control over the project as possible - they feel, and have, complete control if the analysts are really good at their job.
Analysts can make a particularly important contribution during the pre-planning process: they can help define the acceptance tests. Customers often have difficulty with this, and the acceptance tests are a key aspect of understanding what the system has to do, and a key aspect of giving the customer confidence in the product. By asking the right questions, and giving suggestions as needed, analysts can help the customers understand their own needs, so that they can define the tests themselves. Again, the customers feel - and have - more control.
Where possible, let a delegation from the customers present the stories at attend the iteration planning meeting. With the analysts’ help before the meeting, the customers can speak clearly about the stories. During the meeting, the analysts can chip in with questions and reminders, without taking control away from the customer.
During the iteration, if customers are not preset full-time, the analysts can field programmer questions, keeping the development moving smoothly. They will probably want to be very proactive in reflecting each question and answer back to the customers: “I was asked how to handle the general ledger entries for refunds. I told the programmers that refunds should go to the same account, with a negative value rather than positive. On the reports, we’ll display all the regular entries, then all the refunds. If that’s not OK, let me know and I’ll sort it out.”
In every respect, the idea is the same: the analysts are there as aides to the customers, not as translators between customers and programmers. This approach keeps the customers engaged and in control, while ensuring consistent, clear stories, and rapid access to detailed answer when they’re needed.
It is usually possible - perhaps always possible - to add organizational elements such as analysts without interfering with essential feedback and learning. Honor and strengthen the circle of life: it is the essence of customer satisfaction.