Seek value, not quantity

For my Quality Management course at the university, the professor used a restaurant’s business model to explain the concept of value stream mapping. According to him, value for the customer would come from reduction in the overall cycle time – From the time the order is placed to the time the customer gets the food on the table to the time the customer pays the bill and leaves. He argued that it was a win-win situation since the customer’s hunger is satisfied and the restaurant is able to maximise the potential of a limited resource i.e. seating area.

Now although it sounded logical, I did not completely agree with it simply because I have been in the customer’s shoes. The logic above would be true if hunger was my sole motivation. However, I have been to restaurants to have an evening out & spend some quality time with girlfriend/family/friends. I would have actually been annoyed at a rapid fire quick service because it would have given me lesser time to soak in the ambience, speak to people, sip my drinks and have a relaxing time. On an evening out, I would rather have the restaurant focus on catering to my needs rather than focus on getting me out of the door.

So how does the restaurant make money off me given that my longer stay at the table has reduced the total footfall ? There is another metric in the restaurant business called the ARPU – Average revenue per user. To balance the reduced footfall, restaurants maximise the average revenue earned per customer. This is achieved through consultative selling of higher margin products such as wines and desserts.

Now lets tie this back to the software development process. Stories, in the context of lean, often get treated as inventory and cycle time is defined as getting a story from definition to development. There is a focus on reduction of this cycle time because it maximises the number of stories that can be delivered. However, it would be foolish to believe that more stories delivered is the same as more value delivered.

Customers seeking to build custom software applications are often unclear about what they really need. They often go along paths which yield them wrong results. They often break their own model and come back to square one. Ultimately, they learn enough to know what they really need . It is these really valuable stories that finally get delivered. It may take them longer to get there and wasted effort may occur along the way, but the end result is far more satisfying and valuable. The more time and chance the customer has to discover what they need, the more valuable the end product is for them.

Its more important to focus on maximising business value delivered, not more stories.


Crossing the Chasm

I often hear people complain that Agile is not yet mainstream and hence, not been adopted widely.Ignore the obvious circular reference for the moment. Lets compare Agile practices adoption with a similar revolutionary principles applied to the manufacturing discipline – Toyota Production Systems.

The Agile Manifesto came out in 2001. Assuming that the practitioners were using it at least 5 years before in varied shapes and forms, it implies it has only been around for the last 10 years or so.

TPS was first instituted in Toyota in the late 1940s. However, no one really noticed it until the oil crisis hit the world in 1973.Toyota was able to sustain the earnings in the subsequent years . From this point onwards, Japanese manufactures began adopting it and subsequently, the world. It was from this point onwards that lean manufacturing principles became mainstream.

The oil crisis was the inflexion point which made the world sit up and notice the success of lean manufacturing.A similar inflexion point will do for Agile what oil crisis did for the lean manufacturing. Catastrophes like NHS and Sainsbury’s IT projects have already highlighted the deepening crisis with formal methodologies. For all you know… its just around the corner..