Running a Retrospective

Retrospectives are a core part of our process for keeping projects running smoothly, encouraging open communication, and hitting our goals. In this video, Joe Ferris, thoughtbot CTO, leads Chris and Ian through a typical retro while describing the process and thinking behind each step.

This is a companion discussion topic for the original entry at

Great video =) That was interesting you guys don’t use point systems. I like that you guys focus on communication—thanks for sharing this.

One of the things that most surprised me when I came to thoughtbot was how direct and transparent the retrospective process was. Having clients be involved in a frank discussion about the less successful parts of the project was an eye-opening experience. I think it builds a lot of trust and makes the finished work that much better.

That’s really cool. What are the top ten list of things you’ve learned working at Thoughtbot @geoffharcourt? :slight_smile:

“Things I’ve learned since I started working at thoughtbot” could probably be a series of blog posts, and it’s certainly difficult to make a top-ten list, but I’ll mention a few more things that I’ve learned or been surprised about in my time here:

  • The value of code review. I have been very impressed at how important code review is at thoughtbot. Developers (and designers!) get almost everything that is merged to master reviewed by another set of eyes. It cuts down on bad decisions both in low-level things (small bugs, etc.), but also higher-level thinking. Code review doesn’t have to just be for finished PRs, it can also be for something in-progress that you want to get a sanity check against. People are firm with feedback but it’s always delivered humanely. I’m impressed at the ability to deliver constructive feedback and to accept it without ego bruising. Prior to working here I was often the only developer on a project, so it’s been an eye-opening experience to see how powerful the practice of code review can be.

  • Pairing, even briefly, is a great way to solve problems. Often when I’m stuck on a problem and I ask for help, someone (either a teammate on the project or someone else in our Slack room) will offer to pair. We don’t do a lot of full-time pairing on projects, but even in small chunks it’s extremely effective at pushing through blocks and diffusing knowledge between members of a team.

  • There’s more diversity of opinion than I perceived from the outside. We have a lot of great best practices and recommendations that we share with the community, but I think this sometimes creates the impression that everyone has the same ideas. There’s actually a lot of debate and (friendly) disagreement about the best way to do some things, and it’s great. People feel free to express contradictory ideas, and that helps us evolve to better ideas or to understand that there might be other worthwhile approaches.

These are cultural things, as a list of what Ruby/Vim/JS/SQL/Elixir tricks I’ve picked up is probably too huge to even attempt to list here.

1 Like

I really enjoyed this and your retros seem to be a very useful tool in a project, however I have a few questions:

  1. How do you deal with budget constraints? Do you discuss this every week on the retros?
  2. How do you control how far you are in terms of features versus budget burn rate?
  3. What happens in fixed budget projects if for some reason you are delayed? Do you talk to the client to cut on scope? What if he’s not budging?

Sorry for all the budget vs features questions that are not directly related to retrospectives, but in a sense I think they kind of are.


These are great questions. I’ll take a stab at giving some brief answers:

-1. How do you deal with budget constraints?

We are in active communication with our clients all week. At our weekly retrospective, we’re reviewing how much we’ve gotten done, and how much budget we have remaining. In the event some parts took longer than we had planned, we are recalibrating how we plan to spend our remaining time to make sure that the best product gets built with the available budget. Sometimes budget discussions are between a project advisor and the client after the retro (to reduce the amount of team time used), but this is a pretty transparent process.

There’s sometimes an instinct to run away from what can be a tough conversation (talking about limited remaining scope), but it’s always best to discuss these things early and in a transparent fashion.

-2. How do you control how far you are in terms of features vs. budget burn rate?

The answer here is related to what I wrote above. We are shipping code and design several time a day and our clients are reviewing and approving those improvements, so it’s not a surprise how far along we are. Our clients are in standup with us every morning, and we are careful to bring things to the team’s attention if something is at risk of not getting in under the budget early enough that we can course-correct if need be. One corollary of this practice is that we try not to have the last week of a project be aggressively scheduled for new features so that there’s time to tweak anything before our time with the client pauses.

-3. We don’t do fixed budget projects. They are bad for us and bad for the client. You can read why in a response that @croaky wrote on Quora.

There’s a lot more about how we run our company’s consulting and billing practices in our Playbook.


@geoffharcourt, thank you so much for taking time to write this. I really appreciate it. It’s great to hear that people have strong opinions, and I think that is why Thoughtbot has a very solid great best practices. Good workflow only comes out from thinking through hard things together.

Upcase is a valuable product to me, to learn from Thoughtbot—not really to learn Rails or other technical things (although the content is awesome) but to learn about the ethos.

Again, thank you for taking time to share!

1 Like

@antwonlee that’s very kind feedback. We’ve very happy when Upcase has an impact.

I think above all the most important shared values I’ve observed here are honesty and optimism. We’re honest about can be improved and optimistic that we can improve them. It’s not always easy to apply those values across the board (it’s certainly easier when everyone else is doing them), but I think that’s how you improve culture anywhere you are.

1 Like

I’d love to see more videos on these non-technical aspects of building software.

1 Like