AAR’s is a process used by the US Army where after each action [in army’s parlance] the team meets to capture the learning’s and lessons, what went well and what could be done better. The advantage of such AAR’s is that the activity performed is fresh in the teams mindspace and they can reflect better on the activity performed and learn from it.
Variations of AAR have been used in the software industry(and in other industries also) in form of Post Harvests, Sunset Reviews, Post Mortem Report etc where the team meets at the end of the project, to look back and reflect on what went well, what could be improved and how to gain from the experience.
While all such practices are fine in theory, there are some fundamental issues in their execution. Few of the limitations are:
- Projects, programs etc get executed over a long span of time – maybe months, years. If a post harvest, sunset review etc is conducted at the end of several months, then it is practically impossible for teams to remember what went well and what could have been better. These meetings then usually will turn into blame game, finger pointing, or of things at a very superficial level. The real learning’s may not surface in such scenarios.
- The importance if learning’s, lessons may become trivial. When the team of individual is facing an issue, or trying to solve a problem, then the lessons they learn while solving the issue/problem the first time is the most important. The next time they face the same situation/problem, then they will see little value in the lessons. They already know how to do it and over a period of time, by the time the post harvest, sunset review happens, the very important lesson that the team had while solving the problem could have become trivial to even mention it.
- Team members join and exit the projects/programs throughout the life cycle of the projects/programs (This is especially true of software development projects). This is compounded by the fact that people leave or join a project not in one shot but in a staggered manner over a period of time. Post harvest, sunset review do not account for tapping into the lessons learnt by people leaving the project, nor do they try to tap into the lessons that people joining a project/program midway bring with them.
- Many times during Post harvests, sunset reviews etc, the team members who had left the project and are now part of other teams are asked to join for such meeting. The intent is very noble — to also tap into the learning’s that these people had and benefit from it. However, the problem is that these team members who had left the project are mentally NOT associated with their previous project anymore, they are mentally switched off from their previous project and are very unlikely to contribute any meaningful learning’s or lessons, and even if they do, it will be very superficial. NOTE: It is not that they have noting to contribute, but the very fact they are mentally, emotionally and physically removed and no longer part of the project, make it difficult from these people to contribute anything meaningful.
There is no doubt that learning’s from Post harvests, sunset reviews can be applied to new projects, but the very fact that lessons/learning’s of AAR’s can be applied right away in the next activity of the current project make it very powerful.
It’s about time that the software industry looks real hard at the value it derives from Post Harvest processes.