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.
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? 
ā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.
I really enjoyed this and your retros seem to be a very useful tool in a project, however I have a few questions:
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.
Luis,
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!
@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.
Iād love to see more videos on these non-technical aspects of building software.