I had an interesting conversation with one of my daughters who made the mistake of asking me what I was doing. What I was doing was reviewing third party documentation and proposals on software delivery but the conversation we got into was around development methodologies. Now it might be that my commitment to Agile methodologies may have influenced the voter but having explained both methodologies she said she’d prefer the Agile way of working.

Here is how I described it. Let me know just how biased it was.

The cake baker.

Imagine you’ve been asked by your daughter to make her a cake. Her definition for the cake was that the sponge should be chocolate, the icing vanilla and it should have chocolate buttons on top (the ‘lightweight spec’).

The Waterfall approach.

  1. I gather all of the requirements together and then analyse them in detail. I break them out into the ingredients. Document these. I detail how we will add the ingredients to together and in what order. I document this as well. Once I’ve written up all of the documents detailing how to make the cake I ask her to read them (the ‘recipe’) and sign off that this is the cake she wants. This takes us half a day.
  2. I hand the detailed up-front design over to her sister who then takes an hour to read them and raises several questions around the document. Do I need to use butter as I’ve only got margarine? Do I need one round 12 inch circular cake tin or will a couple of 8 inch ones make do. Unfortunately I can’t spend much time answering these questions as I’ve moved on to writing up how to cook a roast dinner. Eventually we get all of the issues resolved and I update the document to reflect these. I get these signed off and by then it’s the end of day 1.
  3. The baking starts and due to the detailed plan runs rather smoothly, the cake is cooked and decorated. Unfortunately my middle daughter is a chocoholic and having slept on it would rather that the icing is now chocolate and that the chocolate buttons should be replaced with chocolate honeycomb. Cake 1 goes in the ‘bin’, also known as me. We now spend another half a day updating the specification. Having done some baking we’ve increased our efficiency and manage to get this done by the end of day 2.
  4. Cake tasting time, a time of joy and unity and chocolate. Unfortunately our cake is very dry. This cake goes in the ‘bin’, also known as a trifle. Due to our turnaround time we can’t afford to try out a few sponge recipes so we guess at a solution, we decide to add more egg.
  5. Disaster continues and I get fat.

The Agile approach

  1. Taking the lightweight spec we start baking a cake. We don’t need the detailed ingredients’ list and details of what to do when because we’ve made cakes before. We trust our baker to bake. We value their experience at baking cakes over forcing them to write out the ingredients and process.
  2. During our baking we collaborate with our customer and we agree that actually we can change the icing to chocolate and replace the topping with honeycomb, we hand it over to our customer. We value the fact that we have been able to incorporate a change at the right time and that the end product will be fit for purpose. She thinks the cake is too dry so we review how we made it and investigate solutions to dry cakes. We put that cake in the ‘bin’, also known as my family.
  3. We then bake a moist chocolate cake with chocolate honeycomb on top. Cake is delivered and I have a happy, if unhealthy, family.

So shockingly my middle daughter said she would prefer the Agile method. She also asked why anyone would follow the Waterfall method. The only question this left me with is this: if an eight year old can understand the advantages of collaborating on cake making, embracing change to ensure our cake is fit for purpose, gaining feedback as early as possible, trusting bakers to bake, gaining experience from making cakes rather than reading about cakes; then why isn’t the same true of software? Software takes a lot longer than cakes to make, the likelihood of the customer wanting the end product to be the same as the original specification is small. Let’s use techniques that allow us to work with the customer and deliver them valuable software want as quickly as possible.

Originally Published 5th December 2015 – LinkedIn

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.