In November, I attended a workshop on improving the understanding between customers and software development teams. The attendees were split into seven or eight groups, and there was an exercise at the end asking the members of each group to come up with a practice that could significantly improve the shared understanding with their customers. Five groups independently came to the same conclusion: “Spend some time working at the customer’s location.”

Being in touch with customers is nothing new, in fact that is one of the core agile practices. XP Explained states that a “real customer must sit with the team, available to answer questions…”. That person helps to resolve disputes and helps developers get a better understanding of business rules. But when our software goes into production, the other side needs more help. Like we need a real customer readily available to answer questions, they need a developer readily available for the same purpose.

Are we still playing Chinese whispers?

A single on-site customer helps several developers by providing quick feedback. We ask for such help in order to get relevant information, knowing that it will not get distorted by going through several levels of bureaucracy. But what about real users of our software? Very often in enterprise environments, developers and actual users never meet. The users will get training from a person that was trained by someone that attended a training session… The end result often reminds me of the Chinese whispers game.

Although those cumulative differences may have been amusing when we were children, they are not so funny when it comes to solving real problems that obstruct people in doing their jobs. There is simply no real replacement for cheek-to-cheek communication. A customer representative on site helps us much much more than someone who is available over phone or instant messaging. The same logic can be applied in the other direction – a developer available on site is worth to the customers much more then the one available over phone.

A friend of mine works on a large-scale retail trading system. One of his customers often complained about poor performance of the point-of-sale trading application. Screenshots were sent, with steps to reproduce the problem, but to no avail. The application was profiled, several bottlenecks were identified and removed, but the complaints were still coming in. After a few rounds of finger-pointing and blaming, middle-managers meeting with middle-managers and drawing up action plans, it turned out that all those problems were actually happening at a single location. So this friend of mine went to that shop and spent a busy trading day there. To his disbelief, the application started to freeze during peak hours. It took him about five minutes to diagnose the problem – there was a batch job running on a local cache server. Because of some stale table statistics, the batch job was eating up all the processor power. The application simply could not get to the data. Fixing the problem took ten more minutes, and the shop manager now regards my friend as a hero.

This issue simply could not be resolved remotely – there was too much noise because of the Chinese whispers effect. Developers did try to help and spent hours improving the application, but the information they got on the end was simply misleading. On the other hand, it was unrealistic to expect a shop assistant to report that there was a problem with statistics on the local cache server.

Improving the feedback loop

It’s not just the customers that can benefit from us actually spending some time with them. First of all, that is a great chance to see what kind of problems our customers are facing, not just with the software but with their business in general. Keeping an open eye for things that can be automated is a great way to find new ideas for improving our software.

People working in a shop or a call centre might have a completely different set of problems than their managers. The customer representative that participates in development is probably a business domain expert, so he or she will know quite a lot about the business rules, but that person is often too high in the customer organisation to know about mundane operational problems. Finding out how our applications are actually being used might provide some interesting insights on how to improve them.

If you have not done that before, spend some time just looking at how people actually use your application – you might be surprised. Sometimes they find a loop-hole that is a bit dangerous, use some workarounds that they found out themselves, or just use the system in a strange way that makes no sense. A few years ago, I noticed that a trader was exporting data to Excel, sorting it there and importing back into our application. Imagine the look on his face when I showed him an option to sort it in place.

Spending time with the actual application users is also a great chance to learn more about the problem domain from the trenches. Direct information, undistorted by Chinese whispers, is invaluable.

New year's resolution for software development teams

I propose a New Year’s resolution for software development teams – spend a week or two this year working at your customer’s location. You might not get a lot done in terms of coding, but it will make a significant difference to your users.

Answer questions about about the software, learn about their problems and see first-hand how your software is used. Share the knowledge and improve mutual understanding. You might even fix some problems on the spot and earn yourself a few beers.