Behaviours and rituals
In business it is a lot about rituals, useful ones or not so useful ones. If you are an experienced manager, maybe you know what I am talking about. But normally the higher managers move, the less they think that topic, although rituals can be a powerful tool for managers at all level to change behavior of their direct environment or even the whole organization.
In regular meetings, maybe as CEO or board level manger with your direct reports, have you ever tried to come first and change your standard seat in the boardroom? Observe what will happen: Will your colleagues be irritated and confused or will they just take another seat? Will they ask you about your intention or will they keep silent?
Breaking patterns can be as powerful as setting patterns or rituals, if these are the right ones. In complexity theory we talk a lot about sensing and observing emergent patterns or setting constraints and attractors to influence appearing patterns. Rituals are nothing more like setting constraints or attractors by a leader than could be adapted by others in the team. If these patterns spread and stabilize in a good way without knowing the reason any more, the result can be called rituals.
Retrospectives as rituals
Over the last years, the agile movement brought a lot of focus on best practices from the past and how to transfer them to the current working environment. A lot of pragmatic tools were invented in the agile community that helped us to apply knowledge in the working environment in a simple way. Retrospectives are one of them:
The word retrospective means looking back, contemplating or directed to the past. But it is not just a review of what happened in the past, but also a learning experience in the present and an outlook to the future. A retrospective can be defined as a universal tool to spend a certain amount of time together in a team to reflect about the past to learn for the future. Retrospectives can be used in various situations. In comparison to traditional lessons learned workshops they are often (but not necessarily) either more frequently or taking longer and go deeper.
Some examples and types of retrospectives
Let’s make this more concrete on some examples:
- Project Retrospective: A project retrospective is done at the end of a project to identify things the team have learned and should be applied in future projects. In comparison to mor traditional project lessons learned workshops, a project retrospective is taken more serious and takes at least one day, sometimes 2 days. In a save atmosphere the team goes deep into the project history and searches for aspects that are worth reflecting, either good or bad. A challenge of this type of retrospective is that often management commitment is missing to spent “so much time” on such a meeting or the culture is more to move on immediately to the next project so there is no time or energy to do another workshop on the last project.
- Sprint Retrospective: Having its roots in the SCRUM project management methodology, the idea behind this type of retrospective is not to wait u til the end of the project to improve the way of working in the project team. So on a regular basis, at the end of every sprint, normally every 1-4-8 weeks, depending on the working cycle, the team spends 1/2 day on the review of the last cycle, simply working on what worked well, what didn’t work well and what to keep an eye on in the next cycle. This could lead to performance improvements up to 50-70% over the whole process lifecycle. Big advantage is that the continuous improvement idea is implemented in a systematic way where results can be seen immediately.
- Meeting retrospective: An even more simple approach is the so called meeting retrospective. This is not limited to projects and can be used more broadly on all kinds of meetings. To apply this at the end of the meeting the meeting organizer asks the participants to answer on three simple questions in every meeting again and again, either by collecting answers on a flipchart or by collecting post-its:
- What worked well/ what did I like in this meeting?
- What didn’t work well/ did I not like in this meeting?
- What should we change in the next meeting (in terms of structure, behaviour, insights, learning, …)?
This can be done in the last 5 minutes of the meeting. In the beginning it will take a little longe , but when it became a ritual, 5 minutes are totally enough. The meeting organizer takes the answers as a valuable gift and uses the last question in the first 5 minutes of the next meeting to focus the whole team on the aspects that need to be improved this time.
Conclusion – real continuous improvement in everyday business is possible
The examples give some ideas, how the idea of continuous improvement and organizational learning cycles can be implemented in daily business in a simple and effective way by doing regular retrospective. From my experience and perspective a very useful und effective and often underestimated tool.
What do you think? Any experiences already?
Hi Oliver,
thank you for sharing these interesting thoughts. I totally agree with your opinion that a regular reflexion of experiences can lead to significant improvement. The hardest part is to get people starting such a routine. A lot of people immediately see the benefits of Lessons Learned / Retrospectives – they are just too busy to implement it (“yes, we should do such a workshop. It’s just not the right point in time right now as we are struggling with some problems. We will do it later…”). Like the story of the woodchopper (“I don’t have time to sharpen my axe, I have too many trees to chop”).
From my experience at Festo, the required time effort you are mentioning seems quite much. I think, project retrospectives can also be done in a half-day or one-day workshop – depending on the duration of the project, the number of participants and whether the team had done regular retrospectives during the project. A sprint retrospective could even be done in a matter of an hour – again depending on the team, the familiarity with the procedure and if you focus on specific topics or try to cover everything (my experience: better discuss only one or two topics in detail and come up with measures that will be implemented then having a long list of activities and find no time for implementation).
I wouldn’t separate between the term “Lessons Learned” and “Retrospective”, though. From my view, they are both basically the same: reflexion of experiences in a team with the objective to improve. Lessons Learned doesn’t necessarily mean, that you are only allowed to do it at the end of a project – this is just, what most people did historically. Since there are obvious benefits when you reflect on experiences and discuss steps for improvement in a running project, we’ve been doing Lessons Learned workshops after important milestones in projects at Festo for quite a while now. For me, the only difference between “Lessons Learned” and “Retrospective” is the title. Usually, “Retrospective” is used in an agile context. This automatically leads to shorter cycles for doing experience reflexion. “Lessons Learned” is used in a more traditional project management context (although the Lessons Learned method is not limited to projects – it can certainly also be used for process improvements, team development or even on an individual level). But actually, you could use several procedures and several time frames with both titles. It is rather a question if the term “Lessons Learned” has been “burned” in a company already.
For your idea of a meeting retrospective, I would like to add another procedure. For this use case, you could also use the questions “How valuable was this meeting for me?” and “What did I do to make this meeting valuable?”. A meeting retrospective is something I would recommend doing only for a limited period of time as a regular part of the meeting and then change the frequency to longer intervals. Other than project retrospectives, a meeting retrospective will have the best outcomes in the first few meetings – as the meeting procedures will improve, the meeting will reach a level of maturity that makes a permanent review rather annoying.
Hi Petra,
thanks for your comments. Fully agree that any learning approaches have a decreasing level of benefit and over time. The improvements are biggest at the beginning of the application of the routine. Nevertheless I have good experiences in doing meeting retrospectives over a longer period of time, as many different facets are discussed and under observation. What I do not agree is that the permanent review is necessarily annoying. When Continuous Improvement is an essential element of the company culture, this routine is a kind of artefact that shows, strengthen and stabilize this culture. If stopping after a certain period of time, I recommend to do this based on a defined procedure, let’s say after 5 or 7 meetings. If this is done individually from meeting to meeting there is a high risk that this best practice approach disapears after a certain period of time.