Cycle time: a secret weapon of efficient software teams

What is it that separates the industry leading unicorns from the industry lagging whatever the opposite of a unicorn is... maybe small horses with inverted ice cream cones stuck to their heads?

Is it great ideas? Brilliant developers? Ruthless but visionary CEOs? Great timing? Staying at the office late (remember offices?) to write code and drink Red Bulls?

Turns out it’s not any of those things alone. Rather, it’s the speed and quality of the execution. That is what ensures software companies maintain a wide lead in crowded tech packs (look at Spotify as one notable, agile example). And behind some of these rapid ascensions to greatness lies a secret weapon: optimized cycle time.

Just about every software company on earth measures a set of standard metrics around their development pipeline. These key performance indicators (KPIs) help them understand their burn rate, bugs, throughput, and return on investment.

But without something to tie each of these valuable measurements together, their map to success is incomplete. Cycle time connects the dots between every KPI, allowing software development teams to understand and optimize their production processes and break ahead of the competition.

What is cycle time?

Cycle time is the amount of time that passes between a feature's first commit and the moment it's deployed to customers. In other words, it’s the speed of your development.

If you’re thinking, “Hey, I’ve heard of cycle time, but that’s not how it was defined somewhere else,” there’s a reason for that. Cycle time is used to refer to many different process speeds, depending on the needs of those measuring it.

For example, hypothesis-driven product teams start the clock on cycle time when they start testing a hypothesis. Donald Reinertsen refers to this starting phase as the “fuzzy front end” in his book Developing Product in Half the Time because the phase blurs the line between the design and development work of a project.

By contrast, the most popular starting point for tracking cycle time is at the start of a development cycle with the first commit of a new task, and it’s what we’ll use as the definition for the rest of this article.

Additionally, some organizations measure multiple cycle times at once. Most often, these are:

• End-to-end cycle time (or lead time), which starts at the definition of a task and ends with its release
• Development cycle time (what we’re talking about here), which starts at the first commit and ends at release
• Reviews cycle time, which starts at the first round of code review and ends with the final verification

By understanding and tracking cycle time and the impact WIP and throughput have on it, dev teams can build better code and deliver value to their end users faster.

What’s secret about cycle time

Just about every developer, project manager, CEO, person in a company with a pulse wants to ship faster, build better code, and deliver more value to end users. So if cycle time can so directly and powerfully help them do all those things, why isn’t it more widely used?

Because humans have a tendency to overestimate the uniqueness of their work, misjudge their efficiency, and favor gut feeling over measured metrics.

Some companies assume cycle time doesn’t apply to their use case

Everyone wants to believe that the work they’re doing has never been done before. First off, to quote history's most advanced AI, the Cylons, "All of this has happened before and will happen again," and second, no matter how novel your product is, your work on it can still be broken down into simple, uniform tasks.

When companies are skeptical of using cycle time as a key metric it’s often because the scope of their project is too complex and, as a result, their task sizes are all over the place. While it’s true that each team has unique project needs, this may simply reflect a lack of detailed planning. Optimizing for cycle time ends up making these “uniquely scoped” projects more consistent and manageable.

Development teams (erroneously) believe they’re already working quickly

Humans have the innate ability to judge how well we are or aren’t doing something by “trusting our gut.” While this may help us decide what to eat for lunch (get a sandwich) or who to hang out with (mostly no one, at the moment), it doesn’t help us judge the efficiency of software development.

But cycle time does.

“Software development managers tend to ignore Cycle Time, perhaps because they feel that they are already getting things done as fast as they can. In fact, reducing batch sizes and addressing capacity bottlenecks can reduce Cycle Time quite a bit, even in organizations that consider themselves efficient already.” — Mary and Tom Poppendieck, authors of Lean Software

Cycle time doesn’t just give you a way to talk about how fast your development process is; it also gives you a way to prove that you’re efficient. When you measure average cycle time over multiple periods, you get an invaluable, tested baseline with which you can drive continuous improvement.

Cycle time doesn’t have to be a secret, nor should it be. Optimizing for it will reveal a lot about your processes and how you use code review tools and tests. Combined with other key KPIs, it can act as a lead indicator to predict your success.

How measuring cycle times helps Scrum Masters/team leaders

Optimized cycle time helps project leads and Scrum Masters get a clear picture of what works well (and what doesn’t) in their development pipeline. This understanding helps them better align work with the expectations of stakeholders and customers, ensure their teams ship faster, and enable developers to build better code.

Gives leads a baseline for the development process

Cycle time is impacted by every stage of your development pipeline, from the start of coding to the quality assurance checks to the final steps of deployment. If any one of these factors is inefficient, it’ll affect your cycle time.

To get a baseline cycle time, you’ll average together the cycle time of a variety of tasks that pass through your development pipeline. This gives you a benchmark with which you can evaluate processes down the line and allows you to quickly spot variations and outliers and provides a framework for you to investigate where they’re going awry.

Shows leads what parts of their pipeline are leaky or clogged

Using the baseline, or average, cycle time measurement for their development team, leads have a point of reference that allows them to quickly spot deviations and issues in process.

For example, you know that it typically takes your developers 60-90 minutes to do code review. One day, you see that this time has ballooned to 160 minutes for the last few, related tasks, driving up cycle time. Because you were measuring cycle time, you were able to quickly detect a deviation from the norm. Thanks to this notification, you know what tasks to look at specifically to better understand exceptions and points of improvement in your process.

This is just one instance of how measuring cycle time and establishing a benchmark can reveal a common, fixable issue in your development pipeline. Each time you notice that one task’s cycle time isn’t like the others, your team can look into how that task was handled at each stage. This examination often reveals one of many common process inefficiencies that you can then correct to drive greater efficiency:

• Code review times are slow, meaning developers aren’t prioritizing code review correctly or something is getting in their way.
• The pipeline tooling process is slowing down your developers, meaning you have too many tools being used, or they’re not as integrated as they could be.
• Production is held up by a lack of servers in the production environment, meaning ops should build faster to avoid delays.
• QA cycle times are long, meaning QA checks should be optimized with automated testing.
• Tasks are held up in queues, meaning you have inefficient scheduling practices or too many queues (hint: the only queue you should have is a scheduling queue).

Without measured cycle time, it would take teams much longer to figure out the sources of their inefficiencies, and they wouldn’t have a clear way to see if unblocking these bottlenecks made a positive difference to development.

How optimized cycle time helps developers

Keeping tabs on cycle times not only helps team leads but also improves the work (and, honestly, lives and sanity) of developers. When teams optimize for cycle time, developers face less WIP, less rework, and fewer inefficient workflows.

To optimize for cycle time, your pace (throughput) must stay the same or increase, and your work in progress must go down. This relationship is called Little’s Law, and it tells us an important, universal truth about efficient software development. You can find a food related explanation about it here (which ties back to our brief lunch discussion earlier).

Little’s Law tells us that, if your development pace is consistent, the more WIP in your processes, the slower your cycle time. However, if you reduce your WIP but keep the same development pace, your cycle time drops and your developers can deploy faster.

This optimization of cycle time doesn’t just mean code ships faster. Because your developers aren’t splitting their time between a multitude of tasks at once and can instead focus on a select few projects, they’re able to build better code in the first place.

This reduction in WIP makes developers more productive and less stressed, as Gerald Weinberg proves in his research on the impact of multitasking.

Weinberg found that when a single extra project was added to a developer’s workload, 20% of their time was eaten up by the effort it took to switch between task one and task two. When a third task was added, half of their time went to waste as they struggled to move between simultaneous tasks. That was because multitasking reduced developers’ ability to think deeply and deliver quality work.

As software developer Joel Spolsky writes: “The more things you remember at once, the more productive you are at programming.”

Programming, by nature, requires developers to keep thousands of things in their heads at any given time. If you disrupt their workflow by forcing them to multitask and switch between multiple projects at once, you greatly hinder their ability to think deeply and effectively about the work they’re doing. Or, again in the words of Spolsky: “The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve.”

When cycle time is optimized, WIP and average task size go down. This gives developers the ability to focus more deeply on their code at hand, which means fewer bugs and less rework.

Additionally, developers who work on teams that measure cycle time aren’t as prone to the occupational hazard of productivity optimism (meaning they overestimate how much that can do). Instead of going on their gut feeling, developers’ work is scheduled on an unbiased, brutally honest schedule directly tied to cycle time.

How to measure cycle time to sharpen your competitive edge

So, now that we’ve run you through all the benefits of measuring and optimizing cycle time you’re ready to get started, right? Good.

When it comes to measuring cycle time, you can do it two ways: manually or automatically (we strongly recommend the latter).

If you want to try your hand at manual measurement, your team lead can use a Kanban board and mark down the date and time every time a task moves into the “doing” and “done” columns.

But with tools like Shortcut on the market, there’s no reason to spend valuable time doing this. Instead, our automated cycle time measuring and reporting gives you all the data you need to optimize processes and improve productivity. Read all about our cycle time reporting and then give it a try to see how it can help make your team(s) more efficient.

<!-- Code for CTA component starts here-->

<div class="post_body_cta"><div class="post_body_cta-heading">
Give us a whirl
</div><div class="post_body_cta-text">
Because you shouldn't have to project manage your project management.
</div><div class="common_buttons_wrap"><a href="/signup" class="button primary text-color-white w-button">Get Started - free forever</a>
<a href="https://api.app.shortcut.com/oauth/signup" class="button is-google w-button">Sign up with Google</a></div></div>

<!-- Code for CTA component ends here-->