Retrospectives: A Business Process Improvement Lesson from the Software Development World
/In a previous post, we talked about the biweekly continuous improvement meetings that our development team uses. To ensure these meetings are effective we use a process called a retrospective, which is commonly used in agile software development teams.
Excellent teams do not simply appear. They emerge over time and then only by deliberate attention to improvement. Retrospectives are a key ingredient in that emergence. Despite sounding like a buzzword, these meetings are a focused way to run a continuous improvement meeting for any type of team. The retrospective meeting emphasizes on how the team is working—its processes and its culture—by identifying what has been working well, what could be going better, and what the team wants to try doing differently going forward.
Running a retrospective is a lightweight and efficient approach to continuous improvement. Here’s a quick guide to help you get started.
The Process
A retrospective meeting focuses on three topics: what went well, what could have gone better, and what we want to try to do differently. Each member of the team comes with ideas for the first two topics, the team discusses each persons’ ideas for those topics, and the team identifies changes it can try before the next meeting. Here’s some more detail about each topic:
What went well? Each person identifies ways that the team worked well. These should be focused on process. On “how” rather than “what.” Perhaps the team did a really good job communicating changes to a product. Maybe the team made good use of a new tracking tool and production went more smoothly than it had in the past.
There are many possibilities and the items that make the list may vary considerably from meeting to meeting, depending on the particular work the team is focused on at the time. The important thing to remember is to focus on how the team is working as those are the areas in which they can most easily make improvements.
What could have gone better? While the first topic focuses on how the team worked well, this topic tackles the areas in which the team felt it struggled. Perhaps they discovered that a shipment was missing components at the last minute before it shipped and someone had to run around trying to fix it last minute. Alternatively, someone may have struggled to find the information needed to complete their task. The team should discuss each observation and consider what they might have done differently or what process they would change to help avoid the issue in the future.
What to do differently? After the team explores what went well and what could have gone better, they should consider what they might do differently before the next meeting. Ideas for these changes could come from items that went well, allowing the team to build on their past successes. Alternatively, the items can come from the team’s observations about its struggles.
When selecting items to try differently, the team should choose items that can reasonably progress before the next meeting and should only choose as many items as they can focus on. We usually find that this is in the 2-4 item range. What if you have more ideas than you can implement? We often create our list for the next meeting and add them to the next meeting’s ideas for improvement so that we can consider them again in the future.
Two tips on keeping your team focused on the areas for improvement:
- Between meetings, review how the team is doing on the items you chose. If the team has a daily status meeting, talk about these items twice a week. If it doesn’t have a status meeting, nominate someone to check on the status and communicate it to the whole team a couple of times a week.
- At the start of each retrospective meeting, review how the team did on the items that you chose to focus on at the last retrospective meeting. In what ways was the team successful? What still needs more work? What items or actions weren’t as important as the team thought? If there are any items that the team wants to keep working on, they can be added as ideas for improvement for the current meeting.
The Logistics
What happens in the room stays in the room. The contents and discussions in the retrospective are meant to be for the team. To ensure that the team can have candid and meaningful discussions, the content of the meetings should remain for the team’s eyes only. Without this confidentiality, the team may not feel comfortable addressing politically charged areas and will not be able to realize their full potential for improvement.
Choose a frequency for the meeting. At Renaissance Information Systems, we hold retrospectives every two weeks, which is common among development teams. Much more often than that and the team doesn’t have enough time test changes between the meetings. Holding them less frequently than every 3-4 weeks makes it difficult for the team to remember what happened so long ago. Think about the rhythm of your business and pick a frequency that makes sense for your team.
Budget an hour or so. Retrospectives take about an hour to run through. The goal is to have an opportunity to discuss each team member’s observations. This gives the team a chance to think about what each observation means for the team and if there is anything they want to do differently.
Designate a facilitator. The facilitator guides the team through the meeting, ensuring the team members understand and follow the process. The facilitator could be the same each time or could rotate among team members. Consider what will work best to build an open, honest team spirit, given your organizational culture.
Document the discussion. Find a way to document the discussion, preferably involving the team members (this helps to keep everyone engaged in the meeting). The method you use to do this will likely vary depending on how your team is structured.
Our RIS team is composed of remote workers, so we can’t meet in a conference room. Instead, we use a board on a tool called Trello. We make a list for each meeting with a section for each category (see below for an example). Each person is able to enter cards to the list ahead of time and we then all discuss during the meeting. Entering cards in the items for improvement section as we go.
We have worked with another team in which all the members are located in the same office. That team uses sticky notes and sticks them on a whiteboard in the conference room. Each person comes with their ideas and takes turns putting them on the board. As each person puts their sticky notes on the board they explain it to the team and everyone discusses.
The Result
We found that this process quickly focused us on bite-sized areas that we could improve and we saw huge improvements in our team processes within just a month or two. We continue using the process, meeting every two weeks and incrementally improving and adjusting our processes.
Just like each team needs to continuously focus on how it can work better and improve, so too should your software. To find out more about how continuous improvement can benefit your team and your software, contact us below.
