Hi,
Could a bar or a restaurant apply some agile concepts in its service? In this post, through a practical example, I'll show the answer is yes.
The motivation for this post came after the situation occurred last Saturday, in a restaurant, and I will start the text describing to you here what happened.
The problem
We were a group of nine people and were there over an hour consuming on site. At that moment three people at our table asked for a no sugar caipivodka, so that each one could sweeten to your taste.
When the drinks arrived they were with (a lot of) sugar.
We explained that we had order with no sugar. The waiter took it back and we wait for the new drinks to arrive.
The recurrence of the problem
The caipivodkas came again with no sugar, now slightly discolored, leading us to suspect that they "watered" the drink so they don’t need to do another.
Call the waiter, talks the drinks are still with sugar, take the drinks back, wait again.
The waiter came back and for the third time the caipivodkas are brought with sugar, now even more diluted, but with the presence of the sugar.
O garçom volta e pela terceira vez as caipivodkas são trazidas com açúcar, agora ainda mais diluídas, mas com o açúcar ainda presente. Clearly, those were the same drinks.
Call for the manager com duas opções:
After the waiter comes and goes (and this process takes time) we called the restaurant manager, who said he would personally prepare the drinks. After that, finally the drinks came the way they were initially requested: with no sugar.
Applying agility
Comparing with the concepts of agile we learn and practice, we could say that at this restaurant/bar scenario the customers are the PO, and the Cook and waiter are the development team. We will also consider the order was a backlog item.
When receiving the order back with the three rejected drinks, the Cook found himself with two options:
- A) Make the three drinks again and discard the old ones;
- B) Try to fix the old drinks so that looks like new. What we know as a “workaround”.
The Cook wrongly chose option B, and his bad choice gave him even more work.
Sometimes, when faced with certain problems we have to evaluate what changes need to be performed, since a reuse can be more costly and no guarantee that it will meet customer expectations, than start from scratch.
After the bad choice, the Cook missed again the chance to think agile. He could:
- A) Test his workaround in just one drink, ask the waiter to take and check with the customer if the modification was enough;
- B) Implement the workaround in all the three drinks and take to the customers, thinking the problem was solved.
Again the cook chose B. This choice has tripled his work. This attitude shows us that, when the development team has uncertainties about the functionality being developed, the best thing to do is to have as soon as possible the PO feedback, to make the necessary adjustments and avoid rework.
That was the story I wanted to share! If you have been through a similar situation and realized that with some agile concepts everything would be solved easier, tell us your story in at the comments.
Till the next post!
Muito interessante o post!!!
Parabéns!
Muito legal rever princípios ágeis com exemplos do dia-a-dia.
Nesse exemplo fica claro também o quanto é importante a comunicação direta entre DevTeam e PO, sem ninguém no meio para fazer o leva-e-traz.
Será que o garçom passou a informação correta para o DevTeam? Há uma grande diferença na ação tomada pelo DevTeam se o garçom diz: (1)”O PO reclamou que a bebida está muito doce”, quando na verdade ele deveria dizer: (2)”O PO reclamou que a bebida era para vir sem açúcar”.
Se o garçom, falou que as bebidas estão muito doce, tentar diluí-la não deixa de ser uma gambiarra, mas resolve, não?!
Agora se ele diz que o pedido era para vir SEM AÇÚCAR, aí não tem jeito… é fazer uma nova bebida.
Bacana mesmo a ideia! Dá para discutir inclusive outros aspectos ligados a agilidade, mas vou deixar para outro comentar ; )