How fast can you go?

Here’s a simple experiment: consider how long it takes your team to make and deploy a tiny change into production. For instance, what if you only need to change one word of text? From the time you know to change it to when it goes live, how long would that take? Even when you make it the top priority (but don’t cut corners). If your code is already released with people using it, the answer is likely at least several minutes. For many teams with larger teams or heavier process, it might take more than a day. Regardless if you use an issue tracking system, you’ll usually have to... pull down the most recent copy of the code, name or establish a branch, determine what the request is asking for, find where to change the text in the code, update any automated tests that depend on it, change the actual code itself, iterate running tests and fixing until it works, do any other checks like linting, push the branch up, prepare the pull request, wait for any CI/CD actions to run (and repeating steps if it doesn’t), and wait the PR to be reviewed. If you’re not in a shop where changes need to go through User Acceptance Testing (UAT) or deployed to staging first, you’ll then... merge the change to the main branch, wait for the production CI/CD process to deploy it, and (finally!) review it live in production. To be fair, many of those steps are usually pretty quick, especially if it’s just a word of text that needs changing. Still they’re steps you can’t bypass without often risking quality. Minimum turnaround time Because we made the code change in this experiment trivial, it shows the fastest a change can be. Yes, you might skip steps if it’s an emergency bug fix, but that’s not normal. With someone waiting to immediately review, it still takes several minutes at least. And most teams can’t have someone standing by to review every change. Unlike most velocity metrics, this approach is easy to measure. Look for the most trivial issue in your queue that needs work and see how long until it’s deployed. If you make it top priority, how long does it take to be live from when the person assigns themself to it? Whatever the answer is, that’s your Minimum Turnaround Time. We can talk about other process delays preceding the steps in our experiment that have to do with scheduling and prioritization, but we’ll set that aside as out of scope for the moment. To be fair, often developers can grab another ticket to work on while waiting for a PR review. But then they have to remember to check back, likely the next day. Meanwhile, users have to wait longer while the change sits idle. Using MTT Once you’ve measured it, you have a good lower bound on what any request will take. You can see how much wait time or context switching might be imposed on...

Preview: ~500 words