After Action Review. Does failure always mean we failed?
We are just humans and sometimes we fail. That’s a fact. But on the other hand, as long as we are able to take the lessons learned from our failures, we are never defeated. This is how we manage our failures at Netguru.
The first step is to admit failure. We truly believe in transparency, so our clients always have to know if something went wrong. As you might already know, we have quite a few communication tools that help us involve clients in the production process, as well as to keep them updated. Whatever happens - our client needs to be informed.
Secondly, we wonder why we failed and then pick out what we’ve done well. Yes, well! Our successes in a particular case are just as important as the mistakes.
Below is our recipe for facing failure. We make an appointment with the whole project team and discuss the four most crucial points:
- What did we want to achieve?
- What did we do well?
- What could have been done better?
- What should we do in the future to avoid the failure?
Those (not so simple) questions might be better known as AAR - After Action Review. This is actually quite a common tool to manage failures in the Kaizen way of working. As mentioned above - AAR helps us not only to define areas for improvement but also allows us to do great things even greater.
What does it look like in detail? Let’s take a look at simple example.
One of our clients was expecting large traffic to his application during the weekend, but sadly we received this information at the last minute. As a result, we only managed to set up a page with an appropriate announcement about server overload (instead of adding server capacity). The weekend passed and happily nothing went wrong, but it certainly could have. We decided to not focus on the happy ending, and instead treat the scenario as a risk.
What did we do well?
Our developers’ reactions were quick, smart, and the most appropriate under current conditions.
What could have been done better?
We could have been informed earlier.
What can we do in order to avoid such situation in future?
Explain to our client how important it is to inform us about these situations even if they find it insignificant, and propose to our client to improve the server.
What did we achieve?
The next time a client will let us know earlier if he or she needs server improvements. We also learned that our developers are great and can manage these situations :).
