Retrospectives seem to be created specifically for the new technology projects, however, implementing them in the processes inside the other industries makes a lot of sense. Here's why.
Imagine a situation where you are working on a complex project. A few weeks pass and you see that you haven't moved on with your work as much as you expected. You stand still, the pressure is building up, you feel that the people who were supposed to deliver something last Wednesday have suddenly dropped out of sight. Team communication stopped unexpectedly in the middle of the project? Time to borrow a retrospective from IT.
Why is it worth it to observe IT and borrow solutions from this industry?
Working in the IT industry often requires meticulousness and precision. It also requires time so that the solutions delivered have business value in a constantly evolving market. Therefore, projects are often lengthy and complex. Even if the team's enthusiasm and motivation are initially at a high level, with the weeks and months of deep work on the horizon, you can come across burnout, discouragement, or just boredom with the topics surrounding a given project.
But in IT, projects stretched over time are part of everyday life. Among the methods supporting work around building code for complex solutions, there are several tools from the family of agile methodologies. These tools help maintain the pace of product development while taking into account the development of teams, their influence, decision-making, responsibility, and expertise of team members.
Team —> process —> communication
The pattern is quite transparent: projects tend to have dedicated teams around them. Around the teams, the processes are built, and around processes, the communication aspects are taken care of.
So, when I’m talking to people who work outside the IT industry about how it is to build projects inside IT, I hear "wow, it could be so useful to our team", "why haven’t we thought about it? It could make our work so much easier!"
Working with the company culture and arranging processes, for example in the creative or engineering industries, I try to weave elements of agile methodologies into team operations. Among them, one of the most enthusiastically implemented (and effective) tools is the retrospective meeting.
In the Ola's article you can see what it looks like in IT as well as about its individual elements. However, the retrospective affects not only the work on the project but also the entire organization.
- productivity
- leadership
- awareness of the fact that feedback is a natural part of communication and can be done painlessly
- sense of agency and team integration
Liked - Learned - Lacked or another?
The retrospective is most often an ordered form of a meeting and there are plenty of variants that can be found in ready-made tools such as RetroTool. It’s good to remember though that Retro does not limit creativity - we can create our own formula, tailored to the needs of the team and the meeting. However, the frames and the agenda itself give the team a sort of a structure that keeps Retrospective productive and effective.
The template we'll use depends on the situation in which we are conducting a retrospective - whether it's inside or outside the IT industry, we can use retrospectives in various contexts and processes.
Imagine that, for example, a team is working on a new model of the workshops with customers. The workshop has been built, it was tested with their clients - and now we are in a place where it would be useful to summarize a demo meeting with those who created the whole concept. However, there is still not enough time and space for doing this.
Taking care of feedback and emotions
The conversations behind the scenes show that the team feels a certain distaste after the workshop, but no one knows why. In addition, everyone has scattered and already started working on something new. The team is not too eager to provide feedback. And yet during the workshop, it turned out that there were moments when something did not go exactly as planned. Perhaps emotions are accumulating between the leaders, perhaps the boundaries have been crossed.
In case an organization has an imposed feedback model (for example, feedback sessions are organized quarterly or every six months), there is a risk that topics related to the above situation will either be forgotten or people will remember only the most emotional part of the feedback.
However, if right after the workshop we organize a summary meeting - a retrospective, the team will be able to share their insights and feedback safely, without blaming anyone. The topics that require improvement can be taken care of by the team with Action Points. And they will be implemented by the team members themselves. Makes sense, doesn't it?
So, when to start implementing retrospectives in your team?
You don't need to wait until the whole team is available in the office. You can successfully schedule an online retrospective with remote retrospective tools, such as Retrotool. If you feel that the communication is slightly blurred, invite the team to a half-hour meeting during which all the team members will share, in an orderly manner, what they liked, what they learned, and what they missed over a specific time.
You name what you want to look into the most - it might be a demo workshop, a process you went through, something that was happening over the last week, or last month. Don't expect too much from that first meeting though. Treat it as an experiment, a new beginning, a starting point for the team improvement.
During the meeting, remember that there are emotions that might come up and may need to be taken care of. Also, there might be some aspects of communication to unblock and allow the team to continue to operate more efficiently. The most important element of it is the atmosphere of mutual respect and safety, letting the team members express their challenges.
Don’t forget about the action points. And don’t forget to address them next time you organize your retrospective meeting. I promise - you’ll love it.
