Failing agile: the cake example
rossella 120000Q98F Visits (1488)
Imagine you're a baker. Imagine a customer enters your shop and asks for a birthday cake. The birthday party is one week from now.
The cake is for 50 people.
The baker claims customer satisfaction is his first goal.
Got the order the baker talks to his decorator and explains the situation. The situation seems to be ideal for agile: they'll do two hours iterations with continuos customer interactions.
The baker in two hours is not able to bake the cake, just to mix up all the ingredients;
the decorator cannot actually decorate a cake since there is no cake, so he will prepare a mock up of the cake covering a piece of polystyrene with dark red fondant and a sugar baloon is prepared.
The customer comes but he cannot taste the cake, he can only see its consistency before it gets cooked. The customer thinks this is bizarre but since he is patient, he moves forward with the demo and have a look at the polystyrene shape covered with fondant and at the balloon.
The customer does not like the dark red color and asks to have more balloons, clowns and in general more colors. The party is for a four years old kid.
The baker takes note of the new requirements (it is for a 4 years old kid! more colors are needed!The red color used is too dark!) and starts sprint 2.
At the end of that iteration the cake is baked, custard is ready as well but not added to the cake and the decorator did the cake couverture with a lighter red and the body of the clown character.
The baker calls again the customer to let him taste the cake and see the new decorations. The customer arrives, with some polite disappointment notices that the cake is ready but it is not stuffed, the custard is offered in a bowl and then there is again the polystyrene shape with the same baloon of the last time and the unfinished clown body.
Anyway the customer tastes the cake and say it would have been far better with chocolate drops; the custard is good but he really complains about the status of decorations: why did they show him them?
So the baker takes a note of the feedback and starts sprint 3.
The cake needs to be done from scratch since there is no way to add chocolate drops to an already baked cake. He knows he will not make it in two hours, so he decides the end of spint demo will consist only on showing decorations this time.
The baker calls the customer to show him progresses. The customer comes and have a look at the clown at at the balloons but complains the cake is not ready to test.
The baker then decides that to make the customer happy he needs to give him always something to taste.
Sprint 4 has as goal having a stuffed cake covered with fondant plus at least one more, unspecified, circus related decoration.
To be sure everything is ready on time, the baker decides to bake a smaller cake so that less time will be needed for cooking, stuffing and decorating. Once the cake is ready, before adding the stuffing, the cake needs to get cold. So the baker is unemployed for a few minutes.
The decorator cannot cover the cake since it needs to be stuffed first, so he concentrates on the additional decoration. He decides to do a horse. After a while the cake is cold enough to be stuffed, but they cannot add the fondant on top since it needs to be glued with butter cream and once spread it needs to stay in the fridge for two hours.
The baker takes the risk and calls anyway the customer since he has something for him to taste. The customer comes, tastes the cakes and objects two things: the taste will be different once the fondant will be added (for now it just tastes as butter cream) and the cake is not big enough for 50 people.
The baker explains the cake was made smaller just for letting the customer taste it and that the final one will be bigger; he apologizes for the lack of fondant but the cake had to stay in the fridge for at least 2 hours. Then the decorator shows the horse he prepared. The customer explained the kid hates horses and would have been better an elephant.
Sprint 5 is problematic: the cake baked for sprint 4 cannot be "extended", a new dough needs to be done and ingredients needs to be balanced because of the changes in quantity. So the same story applies: the dough will not be baked in 2 hours, the cake will not be stuffed and covered with fondant in two hours, so the only thing that would be showable is the elephant. So at the end of the sprint the customer gets called again. He refuses this time to come since there is nothing to taste and he does not want to come just to see the elphant.
The baker is depressed because of the lack of feedback, but there is nothing more to do than taking the risk and moving forward. There are only 3 sprints left.
In sprint 6 the cake is baked; the cream is too old and needs to be preapred again, then the cake is stuffed and covered with butter cream.
No time to get it covered with fondant since the cake needs anyway to stay 2 hours in the fridge.
So the baker decides not to call the customer at the end of this sprint since ther would be nothing tastable and the artistic parts have already been reviewed.
So they move directly to sprint 7: the cake is baked, stuffed, covered with butter cream. The decorator can cover the cake with fondant and add decorations.
Everything is ready and now a new problem surfaces: if the baker calls now the customer and let him come from tasting and the customer actually tastes the cake, the cake is permanently damaged (i.e. a piece will be missing) and there will be no way to have it ready for sprint 8.
The baker feels guilty, but he decides to let the customer know about this "last minute issue". The customer gives up and decides he does not want to taste the cake; he just want to come in 2 hours to pick it up.
It took 7 sprints (i.e. 14 hours to do the cake) but:
What could have done better:
the length of the sprint should be defined in such a way that something meaningful could have been shown to the customer. In this case a 5 hours sprint may have been more effective. In the specific case this could have made the cake production faster and with less stress from the backe/decorator and from the customer side.
Interactions with customers and mock ups could be made more effective investing more time in designing the solution with the customer (i.e. can I ask the customer how old is the kid, which is the main theme of the cake, is there is anything the kid really does not like).
The issue with tasting should have been addressed at the very beginning giving the customer same samples to taste and sticking to a small set of modifications (e.g. if you want more chocolate the customer should tell at the very first meeting when tasting the samples).
Adopting agile as work methodology is not a guarantee of success. Common sense must always be applied. The length of the sprints needs to be tailored in such a way you can really deliver something consumable and not intermediate artifacts. In some cases having sprints of variable timeframes may be helpful (e.g. longer at the beginning, shorter towards the end of the project).
Continuous customer interactions are not an excuse to completely skip the design at the beginning of the work and not to analyze effectively and actually the customer request and need.
Avoiding these steps will make you move across too big approximations and refactoring. The continuous interaction should help you defining an implementation that is already on the “almost” right path, should not imply the possibility to restart from scratch at every sprint due to negative feedback.
Ensure the customer interaction provides an effective value to you and does not waste the customer's time. Customer do not have infinite time to dedicate to your work, they have their own work to deal with. The end of sprint demo must be a validation of a complete functionality. Showing mock ups or partial implemented functionality may frustrate the customer. If the function is not complete, show it at the next sprint.
Remember to organize the sprint in such a way that all people have a similar workload and that they can work in parallel or independently from one another. Parts that logically need to be developed sequentially may have to be done in subsequent sprints.