For more than two years we’ve held a weekly retrospective at Cozy. Often, retros are chance for individual teams to reflect on a specific project after it’s finished: what went wrong and what was done well. But we treat retrospectives differently at Cozy. As a result, our retros have helped shape our culture more than anything else we do.
These meetings create the opportunity for constant iteration and improvement, which is an important part of how we work. It’s the time when we discuss how to fix things we don’t like about our processes or tools, or at least understand and try to accept them. We also talk in a broader sense about how the company is functioning, and how we’re expressing our values.
When folks ask what I don’t like about working at Cozy, I answer: “nothing.” I can say that, in part, because of our retros. I’m still surprised by what can happen when you get a group of people together for an hour every Friday afternoon to discuss what can be done better and how.
While retrospecting requires accepting the idea that we can always improve, I’m proud of how far we’ve come. Every improvement took work, starting with the way we executed and conducted retros. Here are some lessons we learned along the way.
Hold a retro every week
How long is your development cycle? One week? Two weeks? One month? Trick question! I don’t care. You should have a retrospective every week.
Retrospectives are about reflecting and improving; a team reflecting and improving every week is going to improve twice as quickly as a team on a two-week cadence. Even if you’re not ready to change your software iteration cadence, you should improve your culture iteration cadence.
Really, every week
I’ll admit, sometimes it’s difficult to motivate your team to hold a retro. Sometimes people leave early or they’re in a groove with their work. Holding a retro with just four people can feel boring.
So by all means, be flexible. Move the time, make it shorter or longer, whatever, but above all else: have the retro, even if you only have four people and meet for 20 minutes. You can’t become physically fit unless you’re rigorous with your training, and you can’t become culturally fit without rigor either. Improvement is all about coping with problems, even logistical ones, and pushing yourself to create solutions and alternatives.
While we don’t always succeed in holding retros, especially over the summer, I don’t kick myself too hard about it. At the same time, I acknowledge that every missed retrospective is a missed opportunity to improve.
Not just for developers
At Cozy, every fourth retrospective involves the whole company. This is a great opportunity to iterate on our entire culture, not just our development process. It’s exciting to see how the company works together as a whole and hear from people I don’t speak with every day. We get a wide spectrum of opinions on issues. These whole company retrospectives are unique and enjoyable for everyone who comes. So, once you’re comfortable running retros for your team, you should branch out and invite other groups.
One key difference between a successful retrospective and a weekly airing of grievances is how the people who attend phrase problems. Just like a large product feature must be broken down into smaller tasks, thorny problems need to be broken down into small, actionable items. There are many formal techniques for helping teams articulate issues during a retro. I prefer to keep asking questions about the issue until I’m satisfied the issue has been addressed, or at least understood.
Often, you may feel like the issues raised are not big ones. In fact, many of them aren’t. But the goal is to keep moving and trying new things. You get lots of points for trying, and in my experience, the mere act of having everyone constantly trying to improve things can itself fix problems.
Management should run retros, at first
I believe culture is created and shaped by management, and retrospectives are a wonderful way to demonstrate what management wants the company culture to be.
Managers, take this opportunity to criticize yourself, your boss, and your fellow managers. Talk openly about what isn’t working and what could be better. When someone brings up an issue that may indicate a systemic problem, it’s your responsibility to uncover what’s going on. If management takes the lead and discusses problems in a frank and mature way, everyone else will follow suit.
Once things are going well, and a retrospective culture has taken hold, management should pull back its role. Facilitating retrospectives and organizing follow-ups are great ways for other leaders to take a greater role in shaping the company. Also, consider rotating who runs the retro, which can help inspire new formats and fresh approaches.
I’d be remiss if I didn’t mention that involving a problematic manager can destroy the kind of healthy retro environment you’re trying to cultivate. However, excluding problematic managers creates its own set of problems. I can’t offer any panacea, but you could try coaxing more senior managers—the people you do consider competent—to attend the retros. That way they can at least witness the dynamic, so they can decide what to do about it.
Try, try again
Retrospectives have inspired us to try a lot of things at Cozy. Most worked, but some didn’t. Here are some problems we discussed, solutions we tried, and the results we experienced:
- Occasionally problems came up during engineering retrospectives that were far removed from development. They were Cozy-level issues. This spawned the decision to create the company-wide retrospective we hold every four weeks, which has been a very positive thing.
- When I started, I established more formal development cycles from Thursday through Wednesday. Some people wanted to try Monday through Friday, so we did, and we liked it. So the rest of the team moved to the same cycle.
- During one retro, we decided the office was too dirty and cluttered, so we created an all-hands office clean-up day. It was incredible to see how much clutter we had accumulated!
- Before we embarked on a new round of hiring, we discussed our recruiting and interviewing practices. This led to a number of important changes that led us to find some high-quality and diverse candidates for all sorts of roles.
- Retrospectives gave us a framework to discuss project management tools. We could observe issues with what we were using, discuss alternatives, and pilot experiments using new tools or processes. In the end, we decided we really love GitHub Issues and HuBoard.
- Whenever we release a serious regression, or run into bottlenecks, we discuss it at the retrospective. We’ve made dozens of improvements to our testing, build, and release process due to problems brought up at retros.