Software releases should be like feeding a baby

As I feed Ruben – my one year old son his fruit purée from a jar, it occurs to me that the principles of good software are all right there.

Let me explain.

Babies are very unique customers. They are frantic for whatever they want, but mostly don’t know what they want until something suitable is offered and tested. Once it is established what they like, the next challenge is to keep it coming at a steady pace and in manageable sizes.

Of course the consequences of screwing up the pace is tears and tantrums – pandemonium.

At any given point they may require something else, even something quite transitory , often a necessary distraction. Whilst you might foresee what they might request next (usually from what they see in the table), knowing when to offer it and in what quantity is a fine art.

Babies generally give ready and rich feedback, though as providers , we often cannot correctly interpret their messages because we , unfortunately, are not as fluent in baby speak as we are in parent speak. They do have their own language that may be limited in vocabulary and sound to the untrained ear as all the same – gurgles for contentment and cries for dissatisfaction.

Business customers also have their own language, one that many techies struggle to understand (with our techie hats on anyway). Some argue that techies need to learn and develop a fluency in this business speak , but like baby speak it will change over time and , often would take far too long to be mastered. What is required, in my opinion , is a process of interaction that combines higher bandwidth communication (visual face to face is preferred) with short release iterations. Just like I don’t wait more than 4 spoonfuls to seek feedback from Ruben, at which point I listen intently and provide him feedback also, software teams should release in short iterations and make time to increase the level of their interactions with the customer shortly before and shortly after the release.

A key tactic in successful mealtimes with babies (food delivery) is creating and managing expectations. My son understands that if the last spoonful was pasta, he can reasonably expect that the next spoonful will be pasta – unless I announce that we are having yogurt. Setting realistic expectations with customers helps them prepare their feedback – if my son has had enough of pasta, he generally starts to protest after the last spoonful – which is my cue to either announce the next feature – yogurt, or consider tactics to encourage him to eat more pasta (this does not necessarily map to software delivery – if you think it does please help me see it)

Another interesting thing around the timing of delivering spoonfuls to be chomped (or software to be used) is that there is absolutely no point getting the next spoonful ready to be chomped whilst the baby is still eating. At best you get a cold spoonful – which might condemn the remainder of the mealtime to the bin (as the baby might now think all future food will be cold pasta!) – or at worst you get projectile vomiting. Both are less than positive reactions. There are many ‘less than positive’ reactions to wasteful stockpiling of software when the customer is not ready to consume. Pretty much all of them lead to wasted revenue and opportunity costs.

Another interesting observation is that sometimes I come to mealtimes with my own agenda or a busy mind. I might be rushed or perhaps , resolve to feed Ruben more pasta when he has clearly indicated he doesn’t currently want anymore (because I don’t think be has had enough!) I tend to try and impose my will on his mealtime agenda. My success rate is poor in this regard and the ensuing frustration for both of us is hardly worth the drama.

Finally when you have experienced a painless mealtime – even better still, one where there has been pure customer delight (in Ruben’s case, lots of hugely enjoyable giggles) you tend to try and replicate it. It is a little addictive. So ,too,  should be successful software deliveries. Customer delight must be the goal – no dramas. If I approach every mealtime with Ruben’s delight as my prime objective (with ensuring that he gets a balanced meal also a consideration) – then I become more attuned to his feedback (because that is how I know he is being delighted and how much).

Ruben’s primary job is exploring and soaking up the knowledge of his environment (and being totally adorable). Food is important and necessary for his growth and health, but should not be at the expensse of his primary mission.

This same principle – of zero or minimal disruption of the customer’s core business – is critical for software suppliers to internalize and project in their releases. It demonstrates a respect for your customers business and recognizes that you are there to help them get better and getting them embroiled in your own drama is not part of that agenda.

In summary , if I distilled my learning from participating and observing baby feeding and mealtimes, these would be my recommendations:

  1. Pace your release with your customer’s ability to consume the delivery. If this is too slow, that can be improved over time. But it is critical to reduce the waste by stockpiling inventory.
  2. The less your customer knows about what they want, the more often you need to show them something that they can use to improve their level of knowledge. So , iterate, help them inspect and collectively adapt.
  3. Customers can change what they want – they are closer to their business than you are – put yourself into a position that supports change with minimum cost and drama.
  4. Customers often speak a different language – it is very rich feedback , but we ,as techies, don’t often know enough to interpret it. Get better at business speak. Try and make communication with the customer more visual and interactive than textual.
  5. Deliver what they can consume – over delivery is worse than under delivery (because you have wasted money, time and effort on what is effectively not used). This bit is tricky – but over time (if you pay attention and engage with your customer correctly) you will establish both a rhythm and a delivery batch size that works for you and your customer.
  6. Manage your customer’s expectations by showing them what they will be getting. Do this as early as you can, so there is enough time to do something about their unhappiness with your next release.
  7. If you can’t deliver what they need or they don’t want the next thing you planned to deliver, keep a handy supply of delighters (yoghurt!) that helps to keep them happy and keeps the rhythm intact.
  8. Respect your customer. They might not be tech savvy, but at the very least, they know their business better you. Don’t make your release (which might be a small part of their business) a major disruption to either their operations or worse, their bottom line.
  9. Work with them to understand what they need to achieve their aims and support them. Try not to impose your will on their agenda to suit your purposes. This will often result in less positive outcomes.
  10. (There is no 10.)

So that is it, my learnings from feeding Ruben. Just wait for what I learn from changing his nappies.

Gong Xi Fat Choi. It is the Year of the Tiger. Happy Chinese New Year.

  • http://lisacrispin.com Lisa Crispin

    This is such an excellent metaphor! Though babies scare me. Customers, not so much, though I suppose some could be scary, maybe that is #10 – if you aren’t used to dealing with customers at all, you will need some courage to do so!

  • http://paircoaching.wordpress.com YvesHanoulle

    The book Babywhisperer might help you to understand the babytalk.
    http://www.amazon.co.uk/Secrets-Baby-Whisperer-Connect-Communicate/dp/0091857023/ref=sr_1_1?ie=UTF8&s=books&qid=1266839315&sr=8-1
    At least the different cries.

  • http://www.knowledgemill.com/blog ElizaF

    I read this going “oh so true”, “I remember that”

    From changing napies, I learned: how to deal with the obvious, to look for signs of trouble, how to firefight (sudocream), always to do the change with a buffer in place, to have all the tools for change in place before I started and there are only certain places where tales of changes are welcome :)