I believe in continuous improvement in the professional sphere, in the personal sphere, and I would even say in the spiritual sphere. I also believe it is impossible to reach any utopian perfection, but that perfection serves precisely to show us the direction we should follow at each moment, even if the path is never straight.
There is a definition of improvement that focuses on recognizing mistakes and learning from them so that they are not repeated. When a person makes the same mistake several times, it is a sign of stubbornness. In this way, the defects made in the first project are not repeated in the second; those, along with those from the second, clear the way for the third, and so on, so that over time you accumulate experience of a value that is difficult to calculate. I distrust people who appear never to make mistakes.
The real problem is attitude: many environments punish mistakes, so if one occurs, it is hidden in any way possible; many people personalize the error in themselves instead of seeing it as a magnificent opportunity to learn something new and gain value as professionals. We are not going to jump for joy when we mess up either; what I mean is that there is always something to learn.
For me, there is an irrefutable truth: the person who never makes mistakes is the one who is always doing the same thing, and we know that to progress we must be more often outside our comfort zone than permanently inside it.
Carrying out retrospectives is one of the tools I know to be most useful for improving and learning, in all areas, but especially in those matters that have not gone as well as expected. Doing them is a wonderful opportunity life gives us to improve (at zero cost).
From Solid Stack, we closed an important project a few months ago that took a lot of time and effort to finish for various reasons. This week we held a retrospective to avoid repeating what we did wrong (and also to avoid letting the mistakes and problems of third parties drag us along with them).
Moreover, I do retrospectives every time I finish something of some importance; that is why I believe this work, which is not exactly introspective and requires a lot of honesty, helped me develop my second technical book (The Practical Book of the Agile Programmer) more fluidly and efficiently than my first one (The Programmer’s Black Book, number 1 on Amazon in its category), and the last one better than the second (The Lean MP Method).
In a retrospective, whether you do it yourself while sitting in a café on the terrace of your favorite coffee shop with just a notebook and a pen, or in a broader context with colleagues, it should:
- Allow all involved people to speak openly about what they perceived went wrong.
- Never blame anyone (this only serves to hide future mistakes).
- Clearly identify what did not work quite well.
- Propose clear solutions and new strategies to avoid the same problems in the future.
- Be honest and humble, which will allow the issues to be clearly exposed and analyzed better.
- Learn how to establish the foundations in advance to prevent them from arising.
- Also describe what did work very well so it can be reinforced in other situations.
Returning to the project I was talking about earlier, we all agreed that we let the client abuse the phone enormously and use it at any moment (creating innumerable irritating interruptions), some elements were specified by email (also abusing that tool and lacking a culture of agreed documents between the parties), we became involved in responsibilities that clearly were not those of the team, etc.
A meeting of a couple of hours where all these issues come to light also has a cathartic effect, especially for people who may have felt a spike in stress at some point. By clearly identifying what did not work well, we gain an important base of experience that will prevent us from falling into the same dynamics in the future.
But it is not all about the bad vibes of remembering what annoyed us for a while: in the retrospective we can also recognize what has worked very well, to strengthen it and keep it even more present in the future. For example, in my last book, I fully respected the writing phase until I finished the contents of a first draft (without paying too much attention to corrections or expressiveness), and only then did I enter the correction and revision process in earnest (years ago I confused the writing and revision phases, and while writing new content I would also correct and revise, which is a mistake).
At least in my country, there is a certain culture of hiding mistakes (and personalizing them), when they are nothing more than a sign that there is something we still have not learned. That said, I do not think it is good to praise mistakes either; however, I can say that the best professionals are not just those who have allowed themselves the freedom to make more mistakes (when you have made many mistakes, it also means you have worked on a wider range of topics), but also those who have had the humility to recognize problems and learn from them.
Behind every success, small or large, there are many mistakes overcome.