SCRUM Cooking: Observations from the SCRUMKITCHEN

SCRUM-Cooking Event

I have been able to enjoy the SCRUM Cooking experience with a few teams and would like to share with you what I have observed.

SCRUM Cooking: Observations from the SCRUMKITCHEN

Very briefly: What is Scrum Cooking?

SCRUM Cooking is cooking according to the SCRUM methodology. Thereby you learn and experience in a team how SCRUM works, have fun and never forget what you have learned, because it has been experienced.

Observation 1: People love to work in a team!

The atmosphere during SCRUM cooking can be compared to a class trip. I have often had the experience that participants even like to stay longer to clean up so that they can prolong the experience. In fact, it is very nice for people to create something together.

The question occupies me why in working life this joy is not always felt to the same extent. Well-functioning SCRUM teams succeed in keeping this joy alive in their working lives. But why does it often not work? I think one obstacle to joy at work is hierarchies. People feel bullied by superiors and organizational structures, and their self-determination is impaired. Hierarchies create competition for promotion positions, which encourages selfish behavior. Managers often do not have the time to take care of their essential leadership tasks because they are busy managing the work organization. Scrum allows a team to self-organize, giving management the time again to make strategic decisions and care about the well-being of their employees. This creates the framework for people to work together in joy.

Observation 2: Scrum Cooking is more than the sum of its parts or 3 + 4 = 15

In SCRUM cooking there is always a creative part. The teams are given a motto and come up with dishes themselves. What is cooked there within the shortest time (45 minutes) with given food is indescribable. The buffets can compete with, if not surpass, the most refined and best restaurants. The cooks are people who not long ago claimed they couldn’t cook. Some of them didn’t even want to cook. What emerges in this creative space through mutual inspiration sends the participants into raptures. From this, one can learn that a well-functioning team always finds a better solution than the best and brightest individual fighters. People can also gain this experience professionally in Scrum teams. Superior developers realize that they too can still learn from others and that their solution becomes even better when they cooperate with others. And it’s great to witness how individuals slowly give up their ego and win in the process. The burden falls from their shoulders, they have a team behind them on which they can rely and from which they can learn. And, of course, they experience the wonderful feeling of being part of a team to which one contributes.

Observation 3: More freedom of design = more fun.

A SCRUM cooking event consists of two sprints. In the first sprint the requirements are relatively precise, in the second sprint there is a lot of room for self-design and creativity. At first, the participants usually feel overwhelmed by the task of the second sprint. In the exchange with each other, the participants inspire themselves and find the energy to face the task. So the overwhelm soon gives way to lively activity. In the final retrospective, many participants report that they particularly enjoyed the second sprint. The free space was inspiring for them and had a great fun factor. This can also be observed in Scrum teams. Working in a Scrum team is more fun simply because requirements are worked out together. People with different skills, such as developers, product owners and business users, develop completely new points of view and insights in joint discussions, which sharpen and specify the requirements. The energy level is higher when working together and results are produced more quickly, provided that people work constructively with each other. In communicating with each other, mutual understanding and knowledge grow. Requirements, on the other hand, that have been developed in secret reflect the limited view of an individual. In addition, the process is very tedious for the requirements manager. It is obvious that requirements formulated in mutual exchange are more sustainable.