Celebrate learning by making mistakes, one of the keys to driving continuous improvement
The world is moving fast, and for that, we have a challenge in every project. We work in complex environments and because of that, many times we don´t know the results of what we plan to do till the end, till we validate our hypothesis. Those validations let us make mistakes and we learn from them.
For this “mistake” to be exploited, it is necessary to support teams by giving them safe environments where they can make learn without fear of retaliation. A few years ago when I was starting my first steps in this incredible world of agility, speaking with an Agile Coach I came across the phrase: “When we make mistakes as a team, we have to celebrate them, because you are learning.” It certainly seemed like a disruptive phrase to me at that time, I was working in environments where accepting a mistake was not only frowned upon but could even mean a visit to the boss’s office for a reprimand. Taken lightly, it sounds almost naive, but it’s a pretty powerful phrase. Of course, in many work environments to say that we are going to be wrong and we are going to celebrate it sounded almost like a joke, but what would agility be if we are not learning all the time? If we do not validate our hypotheses empirically to be able to correct the course? What would become of our teams if we don’t give them that space to learn, in a safe and even healthy environment?
Unfortunately, we do not always come across that environment. A few years ago I had the opportunity to participate in a very critical accounting project as it hurts the company’s economy if it is not carried out. One day during the synchronization, one of the boys announced that he was leaving, that he could not bear it any longer, that they did not value him and there was no way to talk to him to understand what had happened. I just took his things and the next day he was gone. His place was taken by another of the cell’s developers. One day the application stopped working, everyone looked at the newcomer for explanations. Far from being cowed, he admitted that he did not know why but promised to investigate. With the help of their companions, they reached the end. The person who had left had carried out his development with the static variables (hardcoded) so in the initial tests there were results, but of course, always the same. The importance of the transparency of the second person who took the challenge led us to discover the error and be able to correct it, saving time, money, and greater annoyances.
It is important to work with our teams to give them a safe environment, which is why I recommend a very useful Management 3.0 practice called Celebration Grid.
In my personal experience, I began using this dynamic outside of the work environment, in the university. The problem arose when in a group to complete the practical work we needed to develop a web application. Each of the team members began to experiment on their own, leading to very confusing results and the opposite of what we wanted. Some stepped on the code of another, others modified the design, in short, several headaches. As an objective, we decided to perform a retrospective to review our experiments to align ourselves and for that we held a team meeting after the first delivery to see how we could improve, using Celebration Grid. The objective was to visualize which had been favorable and which had not. We were also able to give each other feedback to encourage us to continue researching to deliver a better product than we already had. To carry out the practice we use a board in Miro with the separations that are seen below and each one of the groups with their post-it color begins to complete it.
As a facilitator, I learned that teams need both space and a safe, supportive environment to learn without fear of retaliation. The failure is part of the process, by doing it we learn and in this case, we learned not only from the code but also from how to carry out the experiments as a team. For future experiments, I will seek to delve even more deeply into the experiments they propose to do in the future so that we do not just stay on what was done and how it came out.
So now you know, experiment, and if you have to fail, learn from your falls as a team and personally!
If you are working with teams that tend to experiment, I suggest that you perform these dynamics with your groups every so often as a check on how we are carrying out these experiments.
