In agile software development, we preach about continuous improvement. My workplace Vincit has practiced continuous improvement since the company was founded because we believe it is one of the most important principles of agile development. But continuous improvement is not exclusive to software development. The same methods work in all other disciplines, too.
Actually, continuous improvement is a synonym that software developers use for team learning. Team learning means developing team members’ collaboration to help the team reach their goals more efficiently.
When a team starts working together, they agree on their project practices. But by the time the project is coming to an end, those practices might no longer work as planned. Over time, the working environment, team members, and even the project’s goals may have changed.
In software development, continuous improvement means that teams review and discuss their practices regularly and implement improvements accordingly. No one wants to end up wasting time and money because of inefficient working methods.
Arrange a retrospective
Agile software development methods provide a great tool for continuous improvement: retrospectives. The word retrospective means looking back, and agile retrospectives are meetings where we look back to discuss how the project went and make adjustments to the team’s working practices to make things run more smoothly in the future. This is the core of team learning.
The essence of a retrospective is teamwork. It is not a meeting where the team leader makes decisions and others follow. A new idea won’t turn into action unless everyone commits to it and understands how it relates to the team’s goals. Participation induces commitment.
To ensure that everyone’s opinions are heard, agile retrospectives are typically led by a facilitator and follow a certain script. They are divided into five phases: an introduction where you set the goals and mood of the meeting, data collection from the participants, creation of insights based on the data, decision making based on the insights, and closing to sum up the meeting and collect feedback.
The purpose of the data collection, analysis, and decision-making phases is to get the whole team involved. A team is always stronger and smarter than one person. The outcome of the retrospective is better when the decisions are made together. The team will also apply the new practices more effectively when everyone understands the rationale behind them.
Make it a process
At first, retrospectives at Vincit were held at the end of projects. The purpose was to learn what worked well and what didn’t so that the lessons learned could be applied in future projects. And of course, the aim was to generalize the learning across the entire organization. Who would want to repeat the same mistakes over and over again?
But when the teams came up with improvements, they were always left with one question: “why didn’t we do this earlier?” So Vincitizens decided to hold retrospectives during projects. This way, we are able to solve many problems and improve the practices of our ongoing projects instead of focusing on future projects alone. Teams may also commit more strongly to new practices when they apply and adjust them in their own context.
You get the most out of retrospectives when you arrange them regularly. This comes naturally in software development as the work proceeds in iterative sprints. A typical sprint length is 1-2 weeks, but at Vincit, we usually organize retrospectives approximately monthly. This schedule works well for us and allows us to keep our retrospectives in under two hours. The longer the interval is, the longer time the retrospective takes.
Make it work
The same prerequisites apply for retrospectives and team learning. The first one is a safe atmosphere where everyone can openly share their experiences without the fear of risking their status professionally or socially. Good retrospectives address this issue in their introduction phase. But a quick talk about big topics like trust at the beginning of a meeting is not enough.
You need to create an open culture for the whole organization to make team learning possible. Another prerequisite for team learning is goal orientation. Retrospectives are not coffee breaks where you chit-chat about work. To gain real results from a retrospective, you must come up with action points that lead to tangible changes in the working practices. You have to pay extra attention to this during the decision-making and closing phases of the retrospective. Each decision, the people responsible for the action points, and the deadlines should be written down in detail. The SMART goals provide a good example of how to make and document decisions.
You also need to follow up on your decisions to make sure that they lead to action. When you hold regular retrospectives, revisiting past decisions and tracking your progress happens automatically.
Team learning leads to organizational learning
It’s crucial that the whole team participates actively in the retrospective. But facilitating and participating in a retrospective at the same time is very difficult. Try it, and you will see that you either have too much authority on the decisions or end up not being heard yourself. Thus, at Vincit, we always invite someone outside of the team to facilitate retrospectives. We have an in-house team of trained facilitators you can invite to facilitate your meetings when needed. The facilitator and one of the team members usually plan the retrospective together because the facilitator needs to have some insight into the project situation in advance.
Practices like this lift team learning to a new level and lead to organizational learning. When I facilitate retrospectives for my colleagues’ teams, I learn about their best practices and vice versa. The in-house facilitator team and collaborative approach to arranging the retrospectives ensure that best project practices flow throughout our organization.
The history of retrospectives at Vincit also shows how good practices can spread within an organization on an even broader level. At first, retrospectives were held by project teams following the best practices of agile software development. After learning about the benefits of retrospectives from our developers and designers, our executive, administrative, and business teams decided to use the same method for improving their working practices. Nowadays, in addition to project retrospectives, we also hold retrospectives with, e.g., our sales team, Steering Group, recruitment team, and HR team.
And all other fields can apply the same practices, too. Start with team learning, and you can end up with organizational learning!
If you want to try, the book Agile Retrospectives provides good guidelines for getting started with retrospectives.