Writing Shippable Code (Part Two)


our process as value, waste or apparently necessary waste. Assessing whether a customer would willingly pay for a process step allows us to assign the appropriate category. We can apply the same thinking against the underlying software process encapsulated within our system. We use apparently necessary waste as a marker for those aspects of our process that the customer would not willingly pay for but is still a business requirement, or seemingly adds value to the business.

Whist I agree to these definitions, they do not go far enough for me. They allow us to have steps in our process that we think the customer would willingly pay for, but do not actually contribute towards a successful outcome for the end customer. In fact what this manages to do quite well is increase our risk of failure. What if it is this part of our system which is failing in the end customer's eyes? They are not going to be impressed despite how good the rest of our system is. This is the loophole with lean software and agile thinking which leads to us developing systems that have a significantly higher degree of risk of failing. This is where the majority of defects in our system arise. A classic example of this is a feature of our software which when delivered achieves the marketing intent of the feature, but in the hands of the end customer doesn't make intuitive sense. The end output is correct, but the steps taken to get there are so convoluted that the end user gets frustrated near to the point of giving up. Certain Ajax implementations on the web fall into this trap by trying to be too jazzy with Ajax without considering the end customer's expected outcome. If it had been considered carefully then only areas where it was necessary would use Ajax, all the rest is wasteful.

To overcome this loophole, I would clarify the lean definitions for value and waste as follows:



Something that not only the end customer is willing to pay for, but also contributes positively towards their successful outcome.


a) Something that the end customer is not willing to pay for.

b) Something that the customer is willing to pay for, but does not contribute positively towards the end customer's successful outcome.

For example, I would be willing to pay for a data entry screen on a holiday booking system to enable a search that matches my holiday criteria. However each time I change my holiday criteria I have to key in all the information again. My expected outcome is a confirmed holiday booking, having to re-enter all my information time and time again only leads to me getting frustrated with the system eventually to the point that I might give up and look for another supplier.

With these definitions in mind we can assess our understanding of our system (new or existing) to determine the impact of the touch points and moments of truths we have, and how we can mitigate them to ensure positive successful outcomes. Using positive successful outcomes as both our unit of distance through our journey and our criteria for completely done we can begin to show (like our GPS system) precisely how far we have travelled and precisely how far we have left to go.

The final part of this article will continue this theme and conclude with how through our code we can close this loophole so that we can deliver shippable code with confidence.


About the Author

Sean Sheehan is a lean software transformation manager for a

AgileConnection is a TechWell community.

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