How to Run an Agile Retrospective for Leaders
Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros. ...
Engineering-Process
Deliver a Great Standup Report as an Engineer
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. ...
Retros Need Action Items
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. ...
How I Review Code
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. ...
Why I Don't Point Agile Bug Tickets
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. ...
How and Why to Squash Your Pull Request
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. ...