--- title: How fast can you go? teaser: Speeding up takes just one word. tags: process,economics,technical debt,velocity author: Richard Newman published_on: 2025-12-17 --- 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 developers. If you're under an hour, that's usually pretty good. That is what DORA (below) suggests for "lead time for changes". You can quickly knock out small tasks and injecting a couple into a sprint normally won't be a problem. If you're beyond an hour or whatever you'd like as your Minimum Turnaround Time, you now have a feedback metric. You can redo the quick experiment each month or quarter to see if you can adjust your processes and reduce it. You don't have to make a huge jump at once: any gain helps on every issue and helps your team be more nimble. And this is easy to explain to non-developers. "Once we start, the minimum turnaround time we need to make just a small text change and get it live is X." It's clear, quick to measure, and affects every code change. ## DORA, SPACE, and Lean If you're interested in thinking about process this way, there are other models. [DORA] is a pretty well-known one and often comes up for DevOps folks. It has four metrics: * _Lead Time for Changes_: time from commit to production * _Deployment Frequency_: how often deployments occur * _Change Failure Rate_: percent of deployments that cause an incident * _Mean Time to Recovery_ (MTTR): time to restore service after a downtime incident Lead Time for Changes is the closest to what we described as Minimum Turnaround Time. There is one important problem though: how should one interpret "commit"? If you define "commit" as the first commit in a branch, then it might be pretty close to Minimum Turnaround Time, but could be a little trickier to capture. Often though with a DevOps focus, you're far more concerned with the actual CI/CD run time. It's typically counted from the final-PR-merge-to-main-branch event instead. Doing that bypasses most delays in code construction, review, and testing, except for the final review. That can be deceptively shorter than Minimum Turnaround Time. [SPACE] is another, more broad software engineering model with five main dimensions: * **S**atisfaction and well-being: developer fulfillment, health * **P**erformance: outcomes (e.g., customer satisfaction) not outputs * **A**ctivity: countable actions * **C**ommunication and collaboration: team dynamics, knowledge sharing * **E**fficiency and flow: ability to work without minimal interruptions The "E" in SPACE is the closest in concept, but it's a substantially broader treatment and not as easy to capture. Lean production has two similar terms, [Cycle Time] and [Lead Time], but those have crucial distinctions. * _Cycle Time_ is the time to complete "one unit" once work has begun (e.g.,making a widget, handling a customer support call). However, it's the the average time, not the minimum time. It's found by taking a interval of time and dividing by the number of units completed. In practice, this metric is most telling when there's low variability between units in production. * _Lead Time_ entails everything from when the request was first made (i.e., customer ordering) until delivery. Changes to software often involve planning roadmaps, gathering requirements, and prioritizing features. This can be wildly different than what we're calling turnaround time here. This can be interesting, especially for the minimum case, but it's also often not completely within developers' control. There are interesting and useful concepts in all the metrics above, but they also involve more attention and dedication to apply. [We're happy to help you] speed your software development. The minimum turnaround time to start using Minimum Turnaround Time need only be as long as it takes you to change the words from "slow" to "fast". [DORA]: https://www.atlassian.com/devops/frameworks/dora-metrics [SPACE]: https://queue.acm.org/detail.cfm?id=3454124 [Cycle Time]: https://www.6sigma.us/six-sigma-in-focus/takt-time-vs-cycle-time-vs-lead-time/ [Lead Time]: https://www.6sigma.us/six-sigma-in-focus/takt-time-vs-cycle-time-vs-lead-time/ [We're happy to help you]: https://thoughtbot.com/hire-us