Ok, granted, this time there’s actually something substantial behind the clickbait title.
Imagine the following setting: A room with a big conference table, several people are sitting around it and sharing their negative experiences from the last 1 to 2 years. The leader presents facts and figures. At the end, everyone’s relieved to have made it through the meeting without getting blamed for anything.
What sounds like a self-help group is actually a lessons learned workshop after a project. I may have exaggerated a tad in the description, but I think we’ve all been through one or more workshops similar to this. So why do lessons learned workshops tend to come out like this? Why do we often fail to achieve the intended goals of the workshop?
When is the lessons learned workshop typically held? At the end of the project. You work on something for one or two years, and at the end, you talk about the things that didn’t go too well. Never mind that it’s hard for the participants to recapitulate the entire project history and identify the problem areas – these problems aren't even discussed at the time they come up. There are several disadvantages to this:
Even though the disadvantages are pretty obvious, people insist on saving the lessons learned workshop for the end of the project. Frankly, I have no idea why this is.
Oftentimes, you sit down and compile everything that went badly. And that’s usually where it ends. People neglect to work out why it went badly and, even worse, they neglect to work out what they can do in the future to avoid making the same mistake.
Just knowing that something wasn’t ideal doesn’t mean that I’ve learned anything from it. In order to learn, you have to understand the causes behind the problem and then derive steps or behaviors that would help prevent the issue from reoccurring.
Oftentimes, something gets written down in documents that are then filed in the project portal and sit there, anxiously waiting to be rediscovered. The attempt to carry over actions from the project to the organization is difficult and tends to fail in most cases. Usually, the problem reoccurs sooner than the documentation from the lessons learned workshop is rediscovered.
The way I see it, this is because the lessons learned workshop is held at such a late stage, long after the point when the problems actually occurred. By this time, they just aren’t as critical as they were when they happened – out of sight, out of mind. So, no one’s focusing on them, and people aren’t likely to notice when they hear about a problem that has already been discussed in the past.
Retros. What the brains behind the Agile Manifesto realized is that it’s pretty pointless to wait until the end to talk about what you should have done differently. That’s why they defined the following agile principle:
At regular intervals, the team reflects on how they can be more effective and adjusts its behavior accordingly.
It’s not about increasing work performance – it’s about improving yourself. Scrum uses Retrospectives at the end of each Sprint to do this. This approach is much more comprehensive than the “normal” lessons learned workshop. The idea isn’t to whine about everything that went badly. It’s about making targeted improvements. Of course, this does involve going over the problems that occurred or mistakes that were made. But it also involves optimizing processes and procedures that may have worked well so far.
Retrospectives also demonstrate the advantage afforded by the role of the Scrum Master or Agile Coach who moderates the meeting and provides an impartial outsider’s perspective. This factor is also missing from most conventional lessons learned workshops, because it’s normally the project manager who moderates, even though he/she is actually supposed to be involved in the work itself.
We’ve been using agile methods in our product teams for several months now, and we’ve had very good experiences with the Retrospectives and the use of a Coach. The teams have made noticeable progress. We’ve been able to address mistakes and problems and find ways to solve them or prevent them in the future.
Retrospectives also positively affect and promote team-building processes. Even after a particularly “heavy” Retrospective, the team usually comes out stronger and more cohesive as a result.
In order for Retrospectives to be effective, you need to create the right framework conditions. Any disruptive elements have to be avoided. This includes having members of Management at the meeting, because this could make the staff less candid with their feedback. Be sure to leave enough time, so that discussions don’t have to be cut short. The moderator must prepare and structure the Retrospectives, leaving enough leeway for the unexpected. Retrospectives are not simply meetings for talking about problems. These are actively designed creative meetings. On the website “plans for retrospective”, you can find excellent tools to help you make your Retrospective interesting.
The first Retrospectives that you’ll conduct at your company will probably not be very effective and efficient. Teams have to learn how Retrospectives work and really engage with them. After two or three meetings, you’ll start to notice that the results of the Retro are getting better and the entire process is going more smoothly.
However you choose to design your Retrospectives, there are two basic rules that you always need to follow:
The effect of these two basic rules is to make the participants more open and to create (in conjunction with the conditions mentioned earlier) a stress-free environment that enables the project team and even the company to improve.