Building Trust Through Cadenced Retrospectives

One of the hallmarks of effective teams is trust. This applies not just to the interpersonal relationships between team members, but also to the relationship the team itself has to other teams and the rest of the organization – especially management. In a low trust environment, any attempt to bring about new changes, especially from an external perspective, are going to be hit with a double-whammy: People are naturally resistant to change, but especially when they feel they don’t trust the reason, or the change is being brought onto them without any recourse.

To help overcome resistance, one of the first things I establish in organizational change is a mechanism to give teams control over their destiny. I want it to have several components:

1) It must be a “heartbeat” review – something that happens on a regular cadence the team expects
2) It must be driven by the team
3) It must look at what the team expected to happen
4) It must let the team decide how to change things to fit their operating model

Taken together, teams can rapidly discover how to incorporate surprisingly significant change in a short amount of time. The specific process I use follows the concept of a retrospective – but I’m often quick to point out that what teams normally call a retrospective usually ends up as a gripe session rather than a regular opportunity to reflect on processes the teams want to try. Done well, it encourages the notion of experimentation, because no process is ever permanent.

For example, let’s say someone on a team wants to introduce the concept of No Estimates – breaking work down into similar sized chunks – to their team to help solve some issues they are having with sizing things in story points. The team agrees to try it, and at their first retrospective two weeks later they review how it’s going. The facilitator first starts with a simple 4-column board:

The team starts with the first column: Expect. The facilitator asks: “What did we expect to happen over the past two weeks?” The goal of this column is to review the hypothesis of the experiments we took on during the last cycle. In this case, the team expected to see a reduction in time spent estimating stories.

Next, the facilitator asks the team to talk about the things that went well. I find it important to start with the good in sequence – especially in a low-trust environment – to get people focusing on positive things initially. The team mentions that it felt freeing to not have to size things from a relative perspective, and that the goal of decomposition made it clear what their goals were.

With the positive elements identified, the facilitator now moves on to the things that were not so good. The team mentions that it was not always easy to get things into similar sized chunks without splitting things arbitrarily. It also felt like they got less done because when they counted the number of stories completed it was a lower number than the story points they normally complete.

Finally, the most critical portion of the retrospective, which is what experiments the team wants to run this cycle. In this case the team agrees that they found the previous experiment fairly interesting, and feel like they still have some learning to do to get No Estimates right, so they want to keep the experiment going for another cycle, along with trying some different decomposition strategies.

This process creates a feedback loop where every process the team uses is only ever in place for one cycle, giving them the opportunity to not be afraid of trying something new and that thing being now forever a part of their process. For example, maybe a team feels standups aren’t useful, so they can try not doing standup for a cycle. Or they want to try pairing, or Test-Driven Development. All of these things can be attempted for a cycle or two, with feedback going to the whole team about how it is going.

While the cycle feels very Scrum-like, one doesn’t need to be doing Scrum to have cadences. A team doing Kanban, or Waterfall, or any process can still establish an explicit policy of having a cadence for retrospectives. In addition, teams may choose to have additional retrospectives to focus on different areas – say, after a release which may incorporate additional exercises. I’d recommend the excellent Agile Retrospectives book for additional retrospective ideas.

Finally, any kind of retrospective does rely on some degree of interpersonal trust within the team. If your team doesn’t have that trust, or it’s a high-emotion retrospective then it’s going to take a little more time to establish that trust. Members want to see that they are going to be heard, that action will be taken, and that they won’t “get in trouble” for their thoughts. I generally recommend bringing in an outside facilitator – either an external facilitator, or at least someone from outside the team. But regardless, as the facilitator you have to make sure that your role is actually facilitating, and not participating. If you feel the need to jump in, be explicit to the group about switching roles, and maybe let someone else facilitate.

Change can be quite difficult, but establishing a process where people feel in-control of the cadence and application of that change makes implementing significant change that much easier. Keeping that process regular and consistent helps increase trust and familiarity. That trust is extended when people understand what they expect to get out of the change, can discuss the impacts, and have direct input into how to best implement the change in their sphere of influence. Taken together teams can come together and make amazing things happen.