werve.net | Running Effective Retrospectives.

Running Effective Retrospectives.

It is not a great surprise that many companies struggle with growth, not because the CTO is incompetent, but because most CTOs are programmers that have had to rapidly pick up a set of skills that are entirely unrelated to technology.

Being a skilled programmer has as much connection to running a team as knitting sweaters for cats does to brain surgery. They both require a great deal of manual dexterity – seriously, have you ever tried to put a sweater on a cat? – but that is where the connection ends.

There are, of course, plenty of books on management, and a bottomless supply of consulting firms that will happily install some ISO-certified Agile Process, but the reality is that while Scrum, XP, or Kanban make great starting points, there is no one-size-fits-all process that will work everywhere without customization.

The trick is to find a way to provide enough structure so that the team doesn’t go full cowboy and descend into total anarchy, while at the same time not constructing a bureaucratic nightmare worthy of a Kafka novel.

Fortunately, there is a large box of management tools to rummage around in for solutions to problems like this, and what we are looking for is right near the top. Agile, for all its problems, does provide one very effective tool that can help you and your team sort the bullshit from the Beluga caviar, and it is the tool most often discarded in the interests of saving time: the retrospective.

But not just any retrospective. A retrospective mixed with science. because retrospectives plus science equals an effective tool for killing bad process before it metastasizes into truly epic stupidity.

As with any other management tool, it is important to understand what the tool does does and why it works, as without that understanding, it is far too easy for retrospectives to turn into little more than unfocused bitch sessions.

With that in mind, let’s take a look at how an average team can apply scientific retrospectives to the process of team improvement, by sitting down with Scrum Mistress Alice and her team of Rockstar Ninja Samurai Cowboy developers at Poogle (a search service that helps desperate travelers locate the nearest lavatory).

The team is gathered in a conference room somewhere within the bowels of the Poogle office, with sticky notes and pens hastily dumped atop the Speakerphone of Clearly Extraterrestrial Origin sitting in the center of the table.
Alice: Alright guys, retro time. Most of you know how this works, but Evan is new to the team, we’re going to walk through the process step-by-step. As always, pipe up if you have questions.; First, grab a pen and a pad of sticky notes. Use them write down your observations on what happened since the last retrospective. We’ll timebox this to five minutes – oh, and no talking during that five minutes, Evan.
Evan: Wait, no talking? Isn’t it easier to just talk about this rather than writing things down in silence?
Alice: Not really. By working in silence, we can avoid a lot of discussion that isn’t necessary at this stage, and by writing down our observations individually, the entire team can see a set of unfiltered viewpoints, rather than just the group consensus.
Evan: But, isn’t the point of this to talk about ways to improve things?
Alice: Yes, but that comes later on in the process. Right now, the focus is on getting information out of our collective heads.

The silent brain-dump technique that Alice uses, and the daily standup, and even the retrospective itself are nothing more than management tools, used in specific cases to solve specific problems within an organization.

And like any skilled craftsman, in this case a craftsman of teams, Alice not only knows what her tools do and when to use them, but how and why they work, and can explain these things to the team in plain language.

Evan: Sounds good to me. So I should just write down whatever has happened over this past week?
Alice: Yep. Also write down your observations about the effects of events during the week.; Take this week’s AWS outage. What else happened because of that? Did it impact morale? Our new coffee maker showed up on Wednesday. Did it rocket us to new heights of productivity? That sort of thing. The key here is to record observations – not suggestions on improvements, just your view on what happened over the past week.
Evan: Got it.
Alice: Great, let’s get started. Everybody ready? Okay, five minutes, starting now.

Alice is using sticky notes, but they could just as easily use index cards or some clever piece of software. Any tool that works is fine, as long as it serves the intended purpose, in this case getting observations out from individual brains and into a format that can be quickly re-grouped and re-arranged by the team.

Alice’s timer rings.
Alice: Time’s up, post your stickies on the board. Bob, you go first, Charlie, you’re next, and then clockwise around the table.; Bob, Charlie, and the rest of the team post their notes on the board, after which Evan steps up with his small stack of Post-Its.
Evan: So, it looks like the idea here is to try and group notes together as we post them, right?
Alice: Exactly. It’s not rigorously scientific, but it gives us a sense of the events that have the biggest impact on the team, as well as things that maybe only one or two people noticed.; For example, everybody had things to say about the AWS outage and our new internal feature blog, but there’s only one post-it about the financials update from the CEO.; That doesn’t mean the CEO’s numbers weren’t important, just that the other two had a much deeper impact on the team, and that gives us a useful starting point to start working on solving our problems as a team.

Humans learn fastest through doing, not by reading a manual or watching a video. By walking Evan through an unfamiliar retrospective format as a full participant, she is saving both her and Evan a great deal of time and effort.

Alice: Okay, next up is to figure out what we’re going to do next.; Alice sets a fifteen-minute timer on her phone.; To start with, let’s take a quick look at the results from our last retrospective. We decided to kill daily standups because they felt ineffective, so let’s vote as a team – raise your hand if you think this has gone well?; Zero hands are raised around the table.
Alice
: Okay, so killing the standup was a bad call. Thoughts?
Evan: Is it okay if I offer up an opinion on this, even though I’m new?
Alice: Of course! You may be new, but you’re still part of the team. Besides, it wouldn’t be much of a discussion if we didn’t bring everybody’s ideas to the table, no matter how experienced or tenured they are.
Evan: Well, I’ve only worked in one other team, but we did standups there, and I definitely felt like I was missing a lot of things this past week.; We got rid of standups here because they were taking too much time, right? At my last company we had the same problem, and in the end, we found that a couple of small things helped us really keep our standups focused…

As they work through the results of the previous week on an issue-by-issue basis, the team has entered the turnpike to the perilous region.

Decisions made here can end up being very expensive. Both in terms of money and time wasted if things go wrong, but also to the reputation of the team as a whole.

It is thus very easy for a team to end up swimming in circles in a subconscious attempt to avoid making a potentially bad decision.

If this happens, then it is time to step in and move things along.

If the team is struggling to come up with solutions to the problem they’ve identified, then punt that problem until the next retrospective. In the interim, have a small working group of no more than three people cook up a prioritized list of solutions worth trying.

Small groups are more creative, and will reach consensus more rapidly than the entire team.

There may be multiple solutions proposed and championed by different team members, which end up arguing back-and-forth about the merits of their ideas, while the rest of the team waits out the debate, their opinions unformed.

When this happens, the champion of each idea must roll for initiative. I have a twenty-sided die in my laptop bag, and the idea with the highest roll is the one we try first.

I am being completely serious. We pick a solution completely at random, because any decision is better than no decision.

At worst, the team will lose a little time, but will in exchange gain useful knowledge that can be applied to the next iteration.

Much better than spending hours on pointless, morale-destroying bickering.

That said, every potential solution needs to come with a set of success criteria, in order to evaluate whether or not the promised results have, in fact, been delivered.

Dave: Okay, that sounds workable – let’s do the pick-a-developer thing and see if it works. If the product owner is happy and the team doesn’t lose steam, we know it works, and if not, we’ll try something else.; Everybody nods
Alice: Since we’re almost at the end of our timebox, let’s wrap things up. Here’s our takeaways from this week:; We’re bringing back standups, but cutting them down only to ‘what I will work on today’. That should keep the standup small, and solve the big problem of accidentally stomping over each other in git.; We agree that the team-wide backlog grooming was a waste of time, but the product owner needs some way of getting feedback before estimation. We’ll kill the team meeting, and instead, give the product owner the right to grab any developer of his choice immediately after the standup for an hour, so that they can do some pair-work on the backlog.; Everybody in the company loves the feature blog, especially sales, and that’s one less meeting we need to set up. Definite keeper. We’ll circle back in three months – I’ve set a calendar reminder – to see how it works over the long term.; Finally, we need a better handle on ops problems, not just this week’s AWS outage, but also to provide backup for our lone sales engineer. Dave and Evan have volunteered to tackle this, and we’ll see what they come up with next retrospective.; If I didn’t miss anything…? Okay, great. Retrospective done. It’s Miller Time!

Now that the Poogle crew has wrapped up, let’s take a look at what happened.

The team started by collecting data on itself, in the form of their observations from the previous week. This data could then be compared to the results expected in the previous retrospective. From that, the team could then make a collectively informed decision about what to try next – and what parts of the process should be killed off completely.

Each change to the team’s workflow is treated as a scientific experiment, whereby a hypothesis is formed, data collected, and expectations compared with actual results.

Such a small thing, but it makes a huge difference.

While this is my current go-to format for retrospectives, it isn’t the only way to run things. Any format that brings together the key elements of the scientific method will do just as well.

That said, there are a few other things that will help keep your retrospectives smooth, focused, and effective:

The retrospective is not a report to management. Finding, hiring, and keeping talented employees requires that they have control over their work. A team-owned retrospective is part of that. Management may be involved in the process, but it is important that the retrospective remains a place where the team can work on itself.
Advance is driven by fire and motion. Keep the meeting focused on the task, and moving forward rapidly. Move long discussions into separate working groups, roll dice or flip coins to break stalemates, just keep things moving.
Prioritize and timebox, working through issues in order of impact on the company and team. It is far better to have a highly-focused half-hour retrospective that hits 80% of the current problems, than a two-hour March of Death that tries to tackle everything.
Kill anything that does not yield tangible benefits within at most one month. It doesn’t matter whether or not the CTO firmly believes that drunken kung-fu programming will triple productivity if they just give it enough time. Either it works, or it doesn’t.
Calendar successful changes for future review. As the company and team grow, past workflow decisions may no longer make sense, because after all, bureaucracy is nothing more than an accumulation of good decisions that have lived past their prime.
Ensure that everybody gets a voice. Nothing kills progress and morale like a lead developer that always pulls rank and shoots down ideas proposed by more junior members.

For such a small time investment, the scientific retrospective delivers an amazing wealth of benefits.

Not only does it provide a highly effective tool for killing bad process before it strangles the very will to live from even the most inspired of developers, but a scientific retrospective also serves to identify beneficial process that just doesn’t market itself well.

In the crucible of critical trial, results speak for themselves, so oddball-yet-effective process becomes easy to recognize.

Regardless of the amount of management experience within a team, scientific retrospectives can help alleviate a great number of the team-killers that I have encountered in my career, but perhaps more importantly, they are a crucial tool in building a culture of mutual respect, constructive criticism, relentless focus, and fearless experimentation.

Or, in other words: a culture of excellence.