The right to make mistakes in an Agile team.

Emmanuel LEGROS
Agile together
Published in
4 min readNov 3, 2019

All the articles I want to propose will have the constraint to be short and simple. If you would ask me which could be the most complicated topic to adress like that, I would answer you “the right to make mistakes in an Agile team”. So I take the challenge to handle it in the second article I write, just for fun. Hope it’s not a too big mistake ;-)

The links between the right to make mistakes and Agile

In the first article, we said that Agile means: “empirical approach + a great team”. So, we’ll use again this two parts to have the link with the right to make mistakes.

Mistakes and empirical approach

You already know, we learn with the mistakes we do.
Everbody knows it. And I saw it again during the previous week, when I told to my 6 years old daughter she did a mistake in a word she was written. She answered me, very naturally, “Thank you. It’s because I’m learning”.
But, this section of the article is not to tell you something you already know, or to speak about my (of course, wonderfull) daughter. It’s to share with you the empirical approach is an approach which expects to accept the mistakes.

In fact, the empirical approach means to do hypothesis, and check the results during a demonstration of the new increment, or check the statistics of the user usages, few time after we made the hypothesis. We learn with the results. And it means, when we have developped these hypothesis, we have accepted that they could be wrong, and we could have to change a part of the new increment. That’s why we do small iterations… it’s to minimize the impacts of our mistakes.

The right to make mistake is a tool to accept we don’t know everything. It’s a tool to build a software in a complex world.
The opposite was the waterfall approach. With this approach, we told everything at the begining of the project, because we thought we knew everything. So, we was not supposed to make mistakes, especially because to find a mistake late has a higher cost to fix than if you find it early.

Now, with this section, the spotify image I used in my first article, is clear. Right? We accept to take risks, because we manage them (and our mistakes) with iterations and increments.

Mistakes and your team

We said that an Agile team is a great team, a self-organized team. For that, you need the good context, a safe to fail environnement, to have trust in the team. To be self-organized means a lot, including reach decisions and be proactive. I suppose it’s trivial for you to see that not have the right to make a mistake will block the team to be like that. If you are blamed when you do a mistake, you’ll take less risk the next time and for that you’ll stop to make decision by yourself and be proactive… to avoid to make mistakes.

Some helps to use this right

As all rights, we cannot abuse it, so for that, we can have in mind some advices.

We already shared the first idea in the first section: we have to minimize the impact of our mistakes. That’s why, we do small iterations and increments to manage this risk, and we check the results of the new increment we delivered.

The second idea could be an Albert Einstein quote: “Insanity is doing the same thing over and over again and expecting different results”. If we can learn with a mistake, we can avoid to redo too often the same mistake, because we have already learned it.

The third and last advice in this article, in order to help to have a safe to fail environnement, is to share explicitly some rules and organization in your team. To have kindness, listening, …, in the team. Or the rules about the requirements of the team (about the level of quality, the processes, etc). And also, to think about organization like who is reponsible of what, and who delegate what to who (for example with some practices from the management 3.0). Yes, rules and organizations are tools to help us to live together, to work together. It’s not anti-agile ;-) and must not be a taboo. What is anti-agile, is to use rules and processes like a robot.

Conclusion

In the first section, we saw we need this right to make mistakes to be an Agile team. In the second section, we shared some helps to use it well. With that, I think we can live with mistakes and have profits from them.
And in the same time, I have the feeling we have to tell so more things about mistakes. Don’t you?
But, this article didn’t have the goal to describe ideas for the management of an Agile team or an Agile company. The goal was only to explain why we need this right. So after this why, maybe, you’ll add a comment to explain how to have and keep this right in the team?

--

--