Running a Quarterly Team Process Review

Most people inherit the team they are on. The team they join often already has a standup, an on-call rotation, backlog meetings, Slack channels, and a set of processes for how work gets done.

But teams change over time. People join or leave, the scope of the work shifts, and the people who remain gain experience. A process that helped the team in the beginning may no longer be useful, but teams often continue following it simply because it is already there.

To address this, I suggest bringing the team together once a quarter to reconsider how they work together. Keep what is useful, change what no longer fits, and remove what the team no longer needs.

Most team processes are choices

Teams often have fewer constraints than they assume. They need to deliver the work they are responsible for, make progress and risks visible to the people who rely on them, and honor any genuine organizational or operational requirements. But within those boundaries, almost everything about how the team works can be changed.

Meetings, on-call rotations, handoffs, communication channels, backlog management, and decision-making practices are choices. The fact that the team inherited one way of doing them does not make that way a requirement.

Why quarterly

Many teams, especially those working in two-week sprints, hold a retrospective after every sprint, with team process being one of the things discussed.

I’m not a fan of holding a process review every two weeks. That usually isn’t enough time to tell whether a change is working, and constantly adjusting the process creates a lot of thrash.

This doesn’t mean a team should wait three months to fix an obvious problem or reflect on a difficult sprint. Quarterly is the cadence I use for a broader review of how the team operates.

Consider a four-person team that changes its on-call rotation from one week to two. After the first two weeks, the person who just spent two weeks on call may hate the new schedule. Everyone else, who just got a longer break from the pager, may love it. That isn’t a particularly useful evaluation of the change.

A quarter gives several people a chance to experience the new rotation. It also gives the team time to see how the change behaves during both quiet and busy weeks.

At the same time, it is important to repeat the review every quarter. If people believe this is their one chance to change the process, they will be reluctant to try anything unless it solves every possible edge case. Knowing that we can revisit the decision in a few months makes it safer to experiment. We can try a partial solution, live with it for a while, and continue to tweak it if it doesn’t work. The goal is not to design a perfect process in one meeting, but to improve it incrementally.

Do it in person

I prefer to schedule these reviews during an on-site. It is possible to run one remotely, but I get much better participation when everyone is in the same room. People respond more naturally to one another, and it is easier to tell when the group wants to spend more time on a topic.

The setup is intentionally simple: a room, a wall or whiteboard, Post-it notes, and markers. This meeting is about the team talking to itself, so the tools should stay out of the way.

Reserve two hours for the review. If it goes much longer, people have a hard time sitting still and staying engaged. Scheduling less time almost always means cutting off conversations before people have talked them through to a point where they feel good about the result.

Start by getting everyone talking

Start with a deck of open-question cards. Have everyone take a card, then go around the room answering them. Someone can answer the question on their card, or they can answer someone else’s question if it is more interesting.

The questions themselves aren’t important. The point is to get everyone talking before asking them to challenge a process or disagree with one another.

Passing is always allowed. I have had team members tell me they would rather not share, and I respect that. Someone may not be in a state where they want to talk much that day. Giving them a clear way to pass keeps the warm-up voluntary and prevents an exercise intended to create engagement from turning into a demand for personal disclosure.

Explain why the review exists

After the warm-up, explain why the review exists. I use roughly the same language every quarter:

Most of us inherit the team we are on. We join a team with existing ceremonies, communication patterns, and culture. Every person who joins changes that culture, and every person who leaves changes it too, or at least should.

Teams often continue practices created by people who are no longer there. The current team may not understand why a ceremony exists and in some cases it may no longer be needed. The people have changed, the work has changed, or the problem the process solved has disappeared.

This review is a chance to take ownership of the team. We have a few requirements. We need to get work done and we need to communicate our progress. Beyond that, almost anything about how we operate is open for discussion and change.

The team belongs to its members. It does not belong to the manager. My role in this meeting is mostly to facilitate, clarify constraints, and help the group make decisions it can live with for the next quarter.

Repeat this explanation each quarter because the team and its circumstances may have changed. Someone may have joined since the last review, someone else may have left, and everyone has another quarter of experience with the current process.

The last point also changes how I participate. I may have preferences, but for the most part I keep them to myself and focus on facilitating the discussion. A manager cannot dominate the conversation and then claim the team owns the result.

Give examples that encourage bigger changes

At this point, give examples of things other teams have discussed. These aren’t recommendations, and they aren’t a list the team needs to work through. They are intended to show that the review can go beyond changing the team logo or making some other cosmetic change.

Teams can reconsider the length of the on-call rotation, the relationship between the primary and secondary, and what work an on-call engineer should attempt. For example, the team may decide that the primary should work through small backlog items that are easy to stop and restart rather than planning to make progress on an OKR project. The secondary might scrub the backlog, and the team might change what information is passed between shifts or decide that a formal handoff is no longer useful.

These choices are connected. Changing the rotation may change how backlog work is handled, which may change the handoff. The review lets the team consider the whole operating system instead of adjusting one ceremony in isolation.

Write down the topics

Once the purpose of the meeting is clear, hand out the Post-it notes. Give everyone ten to fifteen minutes to write down the processes and ceremonies they want to discuss. When they are ready, have them put the notes on the board.

Starting with quiet writing gives everyone a chance to form their own ideas before the loudest or quickest person in the room sets the agenda.

Group similar notes into topics

Look for notes with enough overlap to form a single topic. Before placing them together, ask the people who wrote them whether the grouping makes sense.

This is important because two notes that look similar may have a meaningful difference to the people who wrote them. It is their agenda, so don’t erase that distinction just because combining the notes would be more convenient.

Vote on what to discuss

Everyone gets a limited number of votes. For a team of around twelve people, give each person four. They vote by using a marker to draw a dot, an X, or any other mark next to a topic. They can spread their votes across several topics or put all four on one topic they care about deeply.

Before voting, explain that the team will not discuss a topic that gets no marks. I used to work through every topic, but this meant spending time on topics that were not priorities for the room. If nobody is willing to spend a vote on a topic, it isn’t important enough for this review.

After the vote, count the marks and start with the topic that received the most. From there, work downward while there is still time and interest.

The vote doesn’t decide the answer. It decides which questions get the team’s attention first.

Turn the discussion into a decision

Once the team starts discussing a topic, give people time to talk it through, but also time-box the discussion so that one topic does not consume the entire meeting. When the time is up, check whether the conversation is still moving forward. If it is, the team can choose to give it more time. Otherwise, ask the team to identify what it is ready to decide.

Usually the team can reach a consensus on its own. If it cannot, ask whether there is something small the team can try that might provide more information. If the team has trouble coming up with an idea, I help brainstorm options: “What if we tried this one small change? What do you all think?”

The small change may turn out to be all that was needed, or the original concern may no longer matter by the next review. Do not automatically put the topic on the next quarter’s agenda. If it is still important, someone can raise it again and put it through the same voting process. This lets the team improve its process incrementally without requiring every discussion to produce a complete and permanent answer.

Record the decisions

At the end, collect the process changes, write them up, and send them to the team. The write-up should be specific enough that someone who missed the meeting can understand what changed. When a decision is an experiment, also record what the team hopes to learn or improve. The team then works under those decisions for the next quarter.

When the next review arrives, start again. Don’t assume that the team still agrees with the previous decisions. The people may have changed, the work may have changed, and now there is evidence about how the process behaved in practice.

A side benefit of a scheduled review

There is also a side benefit to having a known time for process complaints.

During the quarter, when someone raises a non-urgent problem with a ceremony or team rule, say, “That’s a good topic for the quarterly process review.” The concern now has a destination and a date. We don’t need to change the wheels on the car while it is moving every time someone encounters ordinary friction.

Record these suggestions on a team wiki page called Process Discussions. This makes sure that postponing the conversation does not mean losing it. But putting something on the page does not automatically put it on the agenda. If someone still wants the team to discuss it at the next review, they need to sponsor the topic by bringing it to the room and putting it through the same voting process as everything else.

This doesn’t mean ignoring a process that is hurting people or preventing the team from working. Some things should change immediately. But most process questions benefit from a little evidence and a room where the whole team can participate.

Remove what is no longer useful

The review also gives the team permission to remove things. Processes tend to accumulate because adding something feels safer than removing it. Once a quarter, the team can ask a simple question: if this ceremony didn’t already exist, would we create it now?

If the answer is no, and nobody can explain the value it provides, we should probably stop doing it.

A feeling of ownership

The most important result of the review isn’t any particular process change. It is the stronger feeling of ownership the team develops over how it works.

When people help create the process, they are more likely to follow and support it. They understand why it exists and have regular opportunities to change it. It no longer feels like they are doing process for the sake of process.

I find this is true even when someone’s preference is overruled by the group. They may not get the outcome they wanted, but they had a chance to make their case and be heard. They leave with a sense that the team has opted to do this rather than my manager is making me do this.

That is a powerful difference.