Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros. I’ll be covering: What is a retro? Why should we retro? Retro setup Running the retro Let’s get started! What is a Retro? What is a retro? From a dictionary: Retro, short for retrospective: ‘a surveying of the past.’ Retros are a Scrum/Agile ‘ceremony’, a collection of best practices for software engineering teams. ...
I’ve been lucky to have worked with some great engineers, and one thing that they tend to do exceptionally well is reporting about their work at meetings. Today I’d like to summarize what I think makes a great standup report. My goal is a report that’s informative, impromptu, and actionable. Informative I try to consistently bring the expected information to my standup report. Time is limited and valuable. On some teams, this is “yesterday, today, blockers.” I often omit yesterday’s work; it’s the past and likely less relevant. Same with blockers, or obstacles in my path; I try to resolve them before the meeting and avoid situations where I’m frequently blocked. ...
Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these. Why Are They Important? Action items steer a retro away from conversation and toward action. I once worked with an engineer who ran retros among all the contractors on the project. He’d push for action items after every discussion, saying: “I want to respect everyone’s time by making sure this leads to action.” ...
Code reviews are important on many teams. Do them well, and your code ships quickly and safely. Do them poorly, and your code ships slowly and riskily. I try to contribute good code reviews. In this post, I’ll share my process. What I Bring First, I try to be nice 😊. There’s a lot of writing about how internet comments can be perceived as less friendly than the author intended, and code reviews suffer from this. The comments are visible to your team, too, so the emotional stakes can be high. Approaching the work with curiosity, saying “thank you”, and adding emojis and GIFs, are little ways to be more human. ...
When I create Agile bug tickets, I leave the story points blank. Why? Two reasons: pointing bugs creates the wrong incentives, and bugs are hard to estimate. Bug Terminology First, some context. Pointing is an Agile process of estimating how long a piece of work will take, or how complex it is. Bugs are defects in a computer program that produce undesirable behavior. And so, pointing bugs means trying to estimate how long it will take to fix a bug, or how complex it is. ...
Many pull requests go through a cycle: programmer opens pull request, maintainer gives feedback, programmer makes changes, repeat until ready to merge, maintainer merges. Prior to the merge, the pull request can be messy, full of reverts, fixups, and WIP commits. In the end, those commits are noise. We can tell a better story by squashing the branch. Consider this Git branch history: * 724d574 (HEAD -> issue/38) Good to merge! * e2af5ac Refactoring the previous commit * 3e36475 Test are passing here * ea479cb Revert "Ooops" * 77aee1d Ooops * 4c7ead2 Test breaker The final commit at the top, 724d574, has been approved to merge by the maintainer. But this branch is a mess. We have a commit that’s just refactoring (e2af5ac), two commits that cancel each other out (ea479cb and 77aee1d), and one that has failing tests (4c7ead2). ...