What is lessons learned? It is a bottom up improvement: you invite people to give their feedback on the quality of the work they do and the problems they face during product development. Final goal of the lessons learned sessions is to create a better working environment and enable the team to be more effective in future projects.
Unlike top down approach, this one is much more engaging and therefore needs to be done very carefully, as people who are involved in this process get more emotionally involved and expect much more from it in return. That also implies that it will work only if people have trust in facilitator, other team members and the complete process.
Phases of lessons learned:
- data gathering
- data mining – split issues in categories
- identify problems and list actions
- find owner for each action and agree on expected outcome
- follow up on actions
The best place to run the lessons learned sessions is everything but office. You should find a place where people are not disturbed, phones should be switched off and no laptops allowed. Announce the lesson learned session at least few days or weeks upfront so that people can think a little bit before coming to this session.
People should give their opinion on good points and things that need to change. The process of collecting this information depends on few things: whether people trust the facilitator and whether people feel comfortable to speak openly. Another very important remark, issues might be either technical, or social. People are more willing to speak openly about technical problems, such as lack of hardware resources, slow or lousy tools, than about things that are related to personal relations. Before you start the session, facilitator needs to be prepared in order to react and navigate discussion in constructive manner.
If the facilitator is the “boss”, that can only work if they trust him (meaning they know him for a long time and they can say openly everything) – there is an old joke “tell your boss the truth and truth shall set you free”, so never forget this… If that is not the case, you better ask someone externally to lead this process, best would be HR.
How you should collect the data? If people can speak openly, you just need two white boards, and people simply speak loudly and facilitator writes it right on the boards – good points on one board, and things that need to improve on the other one, the order is not important. In case that people for one reason or the other are not that free to speak (I can write a long post on this topic alone), you can ask them to write down all that on the paper, facilitator collects it, reads it loudly and write it on the board. You can as well use stickers, since it is easer to move and group them later.
So, your data is there, on the board, and people will start thinking about all of that. Let them talk and argue…
The first thing team needs to do is to find problems that belong to the same category. Once the team has agreed on different categories, depending on the team size, you should assign task of suggesting solutions for each category to several groups. Each group should have not more than 4-5 people so that everyone in the group gets his fare share of time to say something. Of course, one group can try to address more than one category of problems.
For instance, the team and the facilitator can group topics into categories such as lab issues, coding guidelines, office setup etc. For each problem, every group comes with suggestions how to fix those. Once all groups are finished with analysis, let them present solutions to the complete team, till there is a consensus on all actions.
Identify actions and the owners
Facilitator lists all actions on the board and ask who would be willing to own each of the actions. For every action, the team needs to discuss proper set of activities, expected outcome and date at which improvement is required.
This is a hard one. People are good in talking, good in analysis, but very often very lousy in being consistent. If you really want to make a change, you need to be very good at this. And somehow, we humans are not good in this. The best way to do this is to already provide checkpoints in time, and you meet with team at these points to assess the progress. You can use one of the kick off sessions to quickly go over the status. Tip: if this is not your first lessons learned session, before you do the next one, check how many actions points you have closed from the previous lessons learned session. What you will find very often, unfortunately, is that some issues pop up all over again…
You should do lessons learned sessions after every major release of the product, or at least once every 6-8 months. In agile methodology, there are also scrum retrospectives. These are specific lessons learned sessions, and they are primarily focused on issues related to the current development. These sessions, to large extend can be seen as activities that are related to technical bottom-up short cycle fixes. I advice people to do them as well, next to lessons learned sessions.
One last comment. Try to change things that are feasible to change. Many times people waste their energy talking about issues that they are beyond their control. It is great to list them, you might want to escalate them to people that can do something about them, but don’t assign them to folks you know can’t make it.
And don’t be afraid of hearing people complaining (unless it is always the same guy). Only people who are motivated and engaged will always want to remove obstacles that slow them down.