AAR – In other words, how to learn from your mistakes quickly?

Authors: Zbigniew Waz

This well-established practice at the end of a project is intended to make a comprehensive retrospective review (eg in the Scrum after each Sprint, so called Retrospective) to summarize what went well and what didn’t. How does such a process pan out?

• It is most often done once, after the project is finished, when the team is no longer able to make changes to the project, so this summary is only to blame the guilty "put heads on the cutting block" and ensure that the error will not be repeated.
• Unfortunately - there is a big gap between reviewing and action in the next project, which makes learning as unproductive as possible. If the summary was ongoing during the project and applications would be implemented immediately.
• The performance report is most often prepared for senior managers and does not always go to team members, which makes applications and knowledge "fade away".
• The team members can use specific experience in other projects, which may significantly differ from the one they just finished.

After Action Review, or how to learn from your own mistakes QUICKLY

As can be seen - typical retrospective meetings are not very useful and sometimes the valuable conclusions that come after the end of the project are impossible to implement in subsequent projects that differ from the one we just summarized. Another problem is that most retrospective meetings do not have a fixed form, which makes their effectiveness quite low.
So how does AAR work? I would describe it in one word - DYNAMICALLY.

How did we use it in cooperation with Pridictiv?

• AAR dictates that meetings should take place many times during the project and last from 15 minutes to 1 hour. We did them every 2-3 weeks, resulting in effective team work- very soon we stopped being two separate teams on two sides of the barricade: customer - contractor, and we became one team working together on the best possible version of the application.
• In AAR, a strong emphasis is placed on planning specific actions based on lessons learned. During our weekly skype review we could monitor the progress of the work - what was done and what was not and for what reason. Thanks to that, we could react almost immediately. In traditional project management, it would only be possible after the development phase. Here, the time between retrospection and action is very short - the team implements the plan almost immediately after the Review and observes how it affects the development of the project.
• The most common topic is a narrow subject (eg, a specific feature of the application). Then the group of people connected to the topic meet. Thanks to this, communication is fully personal and transparent, there are no intermediaries in the form of project managers and the feedback comes directly from the source - the client. It is irreplaceable in building relationships and communication in a team.

Take a look at how we analyzed the tasks that were correctly made:  Click to see

What does the structure of AAR look like? These are four simple questions!

1. What were our goals? The essence of this question is to clearly define the purpose and our expectations. In practice, it is often the case that the members of the team are amazed to discover that they understood the task they had been given differently. It's a moment when we must go back to the BAR documents, where we scrupulously wrote down the project.
2. What results have we achieved? Here we are looking for facts describing the outcome of our activities, we analyze the effects we have gained by implementing the project.
3. Why have we achieved such results? We try to figure out why we have obtained such and not other results, we analyze all variables, resources and workflow.
4. What do we want to keep and what should we improve? Now we create a plan. I urge you to be as specific as possible at this stage, for example, instead of "we will communicate more" that can be interpreted differently, we write "we organize Daily Scrum Meetings", which is already more clear.

Take a look at how we analyze elements to improve: Click here to see

Our experience with this tool is so positive that we have decided to apply it to all projects, even those that are far from application development and even marketing. We are currently working to make the weekly retrospective of AAR so that we can draw conclusions from good and bad things as soon as possible, so as to streamline the development process as quickly as possible. It's a tool that helps you organize your goals, guarantees transparency and protects you from "turning back halfway". And what experience with IT project management tools do you have?