Team Retrospectives

We can learn, grow, and change as people, teams, and organizations. One way we do this is by having regular retrospectives with our teams. These can be facilitated by coaches or anyone who wants to hold the space for teams to reflect on what has happened in their teams in the past in order to make decisions about how they should be different in the future. Teams themselves can be empowered to derive the experiments they want to try out in order to change.

Reteamings can be experiments that fall out of retrospectives, which might lower the fear of trying out team changes, especially if the team compositions have been the same for a while. As one of my interviewees, Mark Kilby, put it, “If it doesn’t work out, no problem—we’ll go back. So far this hasn’t happened. But we try to couch things in terms of experiments so that nobody feels like they failed.”¹ Keeping the experiments informal is also important. According to Mark: “We try not to have too much formality around it. We’ve talked about having more tracking than we do now. But we have found that when we started turning the knob up there is reluctance to experiment.” I fully agree with the strategy of experimentation, as Mark suggests. It helps to reassure people that we are a learning organization, and that we might not have all the answers. We can experiment and learn together.

At another company, I worked with a team that grew quite large to include about 15 people. The people reflected on their size and looked the work that they had on their backlog. They determined that the best thing for them to try was a concept they called strike teams. In their case, they re-formed into three short-lived teams to complete their work, and then they re-formed back into one larger team. After further reflection, this team also experimented by splitting in half and then rotating the two iOS developers back and forth between the resulting two teams. This way, these developers could pair with each other and work on the highest-priority items across the two teams. Later, this team wound up morphing again into two separate teams, splitting the iOS developers. The key part of all of this team-driven transformation is that the team was in charge of its destiny. It was on the quest for higher performance and fulfillment based on experimenting and really owning the team structure.

Along the same lines, Hunter Industries has a very strong retrospective-based culture that has illuminated different reteaming options to try over the years. This is a very people-centered approach to organizational development and change.

Chris Lucian, director of engineering, told me about how they work. Across the department as a whole, they have a retrospective monthly. Within project teams, they reflect weekly. These are projects that involve more than one mob working together to achieve a shared goal. Topics like reteaming across mobs might come up, and within individual mobs they are continually reflecting and tuning the way they work. As Chris described, “Individual mobs kind of naturally end up starting to have their own retrospectives impromptu, just because you’re all working together on the same thing and it’s just right in your face.”²

So what are the topics in these retrospectives? In Chris’s words, “We reflect on anything that we’re currently working on and we come up with an action item about what to change and we do this regularly. […] Since we started hiring a lot of people […] we put in mandatory retrospectives […] because people need to know that they can call out something and change it.”

He went on to describe a common technique they call the happy, sad retrospective, which is done at the team level: “It’s just things that are going well and things that are going poorly, and then we affinity group the items […] then we dot vote them. If something gets a whole lot of votes, we talk about it and then we try and come up with an action item around it. That action item becomes a change to our process.”

On the department level, they have done these in different ways. People might be encouraged to find someone that they don’t normally work with and then go do a retrospective with them. In this way, they mix up all of the mobs to reflect on topics together, and then those groups will bring the results back, and the department will “dot vote” the results as the target for the wider, departmental discussion. The topics that come up in the departmental retrospectives are things that impact all the mobs as a whole. It could be anything from “the placement of a vending machine, to some technical distraction that’s coming from Windows updates, or something along those lines,” according to Chris.

I really like the way that they retrospect at multiple levels at Hunter. Reflecting across teams and coming up with shared policies is a great way to spread decision making about process to the people who are doing the work.

Multiteam Retrospectives

When you have multiple teams that work in the same area of code, or that typically have a lot of dependencies between them, it’s a good idea to have regular retrospectives to reflect on how things are going. You can then make and update team agreements for use with the set of teams. The teams might decide that it’s better for them to join some of the teams together. They may decide that some regular switching between teams would help them attain their goals. The question, “How might we adjust our team composition in order to achieve our goals?” is one you can consider asking. When the leader poses this question, it gives the people the permission to organize or reorganize to best attain their goals.

At one company I worked with, the teams engaged in a lot of dual-squad development. Platform components were being developed in one team, and were then being implemented in a feature set that was developed by a different team. Working out the logistics of this development is important. You can kick it off by doing a joint-team calibration as described in “Team Calibration Sessions”. Then, after you start working together you can meet at regular touch points to monitor the team health of the situation, followed by a retrospective at the end of the initiative.

Multiteam retrospectives can get quite large. Once your retrospective becomes 10 or more people, you need a scalable facilitation strategy so you don’t have two people talking, with 20 people listening. To meet this challenge—trust me, as I’ve facilitated hundreds of people at once—become a student of Liberating Structures. These are open sourced techniques that scale. They are my go-to facilitation strategy for 10 or more people, whether in person or virtual.³

It doesn’t have to be a cross-functional team, or a group of them for that matter, that engages in retrospectives. They can also take place among other groups of people.

Initiative Retrospectives

Getting other groups of people together who are working on joint efforts is a way to drive continuous improvement in other areas of your work. Maybe these people are working on a program together, like onboarding new summer interns. Or perhaps they put on an event together and want to reflect on how it went so that it’s easier to deploy the next time. Beyond that, maybe this group of people was in charge of a large-scale reteaming effort that reorganized hundreds of people. No matter the initiative, it pays to take the time and talk about how it went. The following example shares some perspective on this.

At AppFolio, we started an incredible double-loop retrospective so that we could continuously improve our onboarding of new people in engineering and product development. We would have regular retrospectives with new hires beginning 6 months after they started (the first loop), and then again after 12 months (the second loop). This was managed via a calendar invite so that we would not forget to do it. Two Agile coaches pair-facilitated a feedback session on what it was like to come up to speed as an engineering team member at the company. From that feedback we would derive initiatives for our Engineering Academy guild. Then, when getting that same group or class of new hires together after 12 months, we could share with them how the changes and feedback they had suggested were put into action for future new hires. It was an awesome experience to show people the impact they had made on an organizational program. This is one example of how to tactically build a generative learning organization.

You will also learn how to get better at the large reteaming initiatives that you plan, like those discussed in Chapter 12, if you schedule a facilitated retrospective on them. One way you can do this is to get the planning team together for two hours. You can use a frame for the generation of ideas to discuss. One frame is to write on a whiteboard, either in person or online, the following words in four quadrants: Like, Learned, Lacked, Longed For.⁴ I have used this for years with teams as a way to look back and structure thoughts. Each person generates ideas for each section. Then, you can cluster the similar ideas together, and as a group go over each section. In doing so, action items will come up that you can note for future reteamings.

You could also do a version of the sailboat retrospective. Draw a sailboat with an anchor going into the water, and some visible rocks showing under the water, on a shared in-person or online whiteboard. Near the anchor, write, “What held us back or slowed us down?” Near the sails, write, “What was the wind that carried our initiative forward?” Near the underwater rocks, write, “What were the obstacles and surprises that we encountered?” Then you will gather ideas from people, kind of like in the previous activity, and have a discussion, writing down your takeaways.

A third way you can run an initiative retrospective is my favorite way—by creating a shared time line of what happened. You can do this with just the planning group, or better yet, with members from the wider community that experienced the reteaming. Using a shared online or in-person whiteboard, draw a horizontal line. On the rightmost side, write today. Then, talk with a partner about what happened and, using physical or online sticky notes, write down the milestones and events that transpired over the course of your initiative on the whiteboard. Then take a look at the filled-out time line together as a team. Using red, yellow, and green dots (just draw dots with colored markers or online markers), indicate how you felt at different parts of the time line. You will see patterns emerge when things went poorly (red), when things went meh or just OK (yellow), or when things went well (green). Have a discussion and then bridge into a conversation about what the key takeaways are for future initiatives like this. Ask people to pair up and have a discussion about takeaways, and then have them share with the wider group.

One-on-Ones

On a different level, staying in touch with how the people in your company are feeling as individuals is a great feedback loop to have in addition to the team- or organization-level retrospective loops described already. It’s critical to know how people are doing in your company. Are they excited to come to work each day? Do they feel fulfilled with their current work assignments? Do they need a change?

In some places, managers serve the role of “temperature taker” and meet regularly with their direct reports in this capacity. That’s fine; however, there is a power dynamic at play. I find that having a team member other than the manager tap into the sentiments of people is a valuable thing to do. This person can be a member of a dev enablement team. They can be a coach. The key is that it is an empathetic person who does not have direct influence over the person’s salary or review. Trust needs to be built in these one-on-ones.

There can be a trap with one-on-ones. If managers use one-on-ones as their only communication with team members, then the communication can be obscured and under too much invisible control. For example, I once worked with a manager who, at the quarter’s end, assigned work for the quarter by meeting with his team members one-on-one. Since the team did not have healthy practices of meeting together as a team, the people complained that they had no idea what their other team members were working on. This can shut our opportunities for collaboration. It’s better for teams to come together and choose their work foci as a coherent group. One-on-ones are not a replacement for open team communication.

Further, one-on-ones are also not the channel for the exclusive communication of organizational changes. When something potentially disturbing to the team and organization is about to be announced, or when a topic is sensitive to people (like the departure of a team member), I’ve seen managers first meet with people one-on-one and then make public proclamations of these changes. This is a risk reduction technique to not surprise people in a more public forum. Again, the private one-on-one forum is not a replacement for other communication channels. Instead, it is a companion or addition to them.

Technology deployed to help us manage our organizations has advanced, and we now have access to tools to help us get better at understanding how people feel. Tools like these are important to consider when you are a larger organization.

Survey Tools

When you are working at a larger scale—and here my experience is with about 50 teams—you can use commercial tools to attempt to gather the sentiment of individuals across multiple teams. Gathering this information can inform your reteaming needs, and it can also provide feedback on how reteamings went. Two examples that I’m familiar with are Culture Amp and Peakon. One company I worked with deployed surveys quarterly, managed by the HR department, to keep a pulse on the reporting structures and people’s overall engagement. When getting the results from these quarterly surveys, each department would respond to the feedback to their groups with prioritized action items. These surveys were given anonymously. At a later point, this company deployed weekly five-question pulse surveys so that managers could get even more frequent feedback from their employees that they could respond to individually.

If you start surveying people on a regular basis but do not acknowledge or take any action on the feedback, then your usage of these survey tools will fail because no one will take them seriously. My advice is to figure out how you will process the results from any survey tool before you deploy any surveys. If you do not do this, you will likely regret it. I’ve witnessed survey fatigue in my career, and it can become a type of “organizational health theater” that can do more harm than good.

Moreover, be sure you do not over survey people. That’s another dark pattern of surveying for sentiment. If people get too many surveys, they will likely just delete them or not respond, which defeats the purpose of having surveys in the first place.

In addition to using surveys as a window into how people are feeling, you can also take the metrics route as a feedback mechanism.

Metrics

At every company I’ve been at, we always get to the point where we want to try to track the health of our organization using metrics to help guide our attention and decision making.

There is a wide range of metrics that you can track, and it really depends on what you want to look at and who is going to use the metrics for analysis. For our purposes here, I want to draw your attention to some research-backed, industry standards on software delivery performance, as well as some lean techniques for looking at workflows.

First are four key metrics of software delivery and operational performance, by the Accelerate team, as articulated by Forsgren, Smith, Humble, and Frazelle, in the Accelerate State of DevOps 2019 report.⁵ These four metrics focus on the system level and include the following:

• Lead time for changes (from code committed to running in production)

• Deployment frequency (how often you deploy to production or release to customers)

• Change failure rate (what percentage of your changes result in degraded service and need remediation)

• Time to restore service (how long it takes to restore service from incidents or key defects)

The 2019 report defines elite, high, medium, and low performers according to their research.⁶ For example, elite performers have lead times of less than one day, deploy on-demand multiple times per day, have a change failure rate of 0–15%, and can restore service in less than one hour. How does your organization compare to that?

In my view, no organization is perfect, but we need to have vision and strive to be the best we can be. The first steps are to define what excellence means to your organization, get set up to see metrics that connect to your definition of excellence, and then strive to pursue excellence by experimenting and seeing how your metrics get impacted.

So, if these metrics resonate with you, get a team together and fund it to study this report, read Accelerate, and build in the capacity to analyze these metrics for your environment. Don’t have this as a side project—fund it deliberately. Being able to see your system performance is a window to guide your improvement efforts and your deliberate reteaming.

As your company evolves and changes through dynamic reteaming, you can see how your software delivery and operational performance is impacted by looking at these metrics.

Besides these metrics from Accelerate, for coaching team effectiveness, I recommend coaching teams to pay attention to cycle time and cycle-time stability of work items like stories. Many of us track our work in ticketing systems, which we can augment with other tooling to enable the analysis of lean metrics like cycle time.

In teams I work with, we define cycle time as the time it takes from when you start a ticket to when you deliver the ticket. Teams need to see their cycle time in order to understand it, stabilize it, and lower it. Using tools like Actionableagile.com with Jira, teams can view reports to visualize their cycle-time stability. Once the team stabilizes its cycle time, it can leverage it for forecasting using Monte Carlo and other techniques. These practices give the team a better strategy for answering the question, “When will it be done?” than other techniques such as estimation and velocity tracking. These are metrics for the team to use to pursue improvement. They enable data-driven retrospectives that the team can strive to impact, by better workflow management.

You need to set up a system to view your cycle time. Once you do, you will see most often that when you reteam, your cycle time will probably increase in the short term because, if it’s a one-by-one reteaming, you are training a new hire to get up to speed or you just lost a team member, so work has slowed.

In the case of growth, once your squad is calibrated and off and running, you might see cycle time decrease, especially if you talk about aging tickets in your standup meetings and then take action to move things along. I don’t emphasize lowering cycle time right away in the teams I coach; I emphasize visualizing your cycle time and trying to stabilize it. I do this because I want to encourage working at a sustainable pace, and I want to encourage squads to own their cycle-time stability by reflecting on it in their retrospectives. If they are aware of it, then they can come up with experiments to try in order to stabilize it and then later lower it.

If you have just reteamed into a brand-new team, the advice that experts in this area like Daniel Vacanti suggest is that you can start leveraging cycle-time metrics with as few as 12 to 14 data points. So you set up your ability to see your cycle time, work a bit to collect the data points, and then start looking at cycle-time stability.

You can dig into this topic, and more, by studying the work of Daniel Vacanti in his books Actionable Agile Metrics and When Will It Be Done?

In this chapter we’ve talked about retrospectives, survey techniques, and metrics as essential feedback loops that can help you see the health of your development organization, guide your reteaming, and help you get better at it.

We’ve covered a lot of ground in this book. Dynamic Reteaming is the lens I’ve developed that articulates my view of software development. Just like our teams, this book has evolved and changed over the five years of its being, and it now will come to an end.