Writing Shippable Code (Part Two)


the red truck heading north. Your total estimated journey time is two hours."

Successful Customer Outcomes


For us to effectively test our assumptions as we go we need to understand how we determine what a successful outcome is and how we can begin to express this. All processes have a criterion for a successful outcome and the judge for this is neither us nor our customer, but the end customer, the individual who is going to use our software. As an end customer I have an expectation of what the system is going to provide for me. If it does not meet my expectations then we do not have a successful outcome. If it does, I'm happy and we do have a successful outcome. This simple view is often missed by most development teams and often lost in translation when applied to software development in general.

If we have been commissioned to develop a system for another company who themselves have customers or have a marketing / product planning division who speak on behalf of our customers, our viewpoint on "value to the customer" is somewhat different to the end customers. We end up neglecting the real customer and fail to consider how our system will perform in their eyes.

Comparing our criteria for success (as developers) against the end customer's we generally get two different viewpoints. We find it difficult to see through the eyes of the end customers leading to these differences. However, we spend most of our lives being end customers to other people's systems. So why is it so hard for us? Especially when we are quick to complain if a system we interact with doesn't do what we expected. We forget that each time we interact with a system one of two things can happen. Firstly, everything goes well and we are happy, we might not even notice that we have interacted with anything because things went so smoothly. Secondly, it could go wrong or not quite as we had expected. We have witnessed a failure point and this taints our perception of the overall system. As we continue interacting with the system our feelings snowball when we discover more and more of these. How many times have you dealt with a system which come the end of your encounter you vow never to return? This could be a shopping website, a mobile phone, software on your PC or even a utility / insurance provider.

As we define systems with more and more end customer interaction we increase our potential to displease. Minimising the quantity of these interactions is one approach in reducing this risk, another is to ensure that for each interaction we have viewed our system as if we were the end customer, considered what the criteria for successful outcomes are, and understood the impacts of not achieving these. Remembering that to do this we have to put on our end customers glasses and see through their eyes.

Touch points

All software attempts to encapsulate a process for our end customers. It could be the process of finding and booking a holiday, purchasing something online, printing off a document or even taking a photograph on our digital camera. These all are driven by software following a process to give us what we need. Each time we interact with this process we have a touch point . We have touched the process.

To illustrate this let's take a photo with a regular digital camera: -


1. Switch Camera on

2. Set Camera mode to automatic

3. Locate subject in view finder


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.