Optimizing Cycle Time not only helps engineering leaders but also improves the work (and sanity) of developers. When teams optimize for Cycle Time, developers face less WIP, less rework, and fewer inefficient workflows.

By focusing on Cycle Time, teams are able to effectively highlight the pains they run into. From tech debt to code review, it becomes easy to identify and advocate for improvements.

Note: If you haven't read about Cycle Time yet, we suggest reading this article first.

Now that we've learned what Cycle Time is and how it can benefit our team, let's dive into some ways we can optimize it.

Best (and Easiest) Ways to Improve Cycle Time:

  1. Limit Work In Progress (WIP)
  2. Smaller Pull Request Size
  3. Faster Development Time

Limit Work In Progress (WIP)

One of the largest levers we have to optimize Cycle Time is WIP (Work In Progress).

Little's Law does a great job explaining this universal truth about software development but to save you some reading, we've summarized it:

Reducing WIP leads to faster cycle times.

Gerald Weinberg's research shows that when adding a single extra project to a developer’s workload, 20% of their time is eaten up by context switching. When a third task is added, this increases to half of their time wasted as they struggled to move between tasks.

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.

But that's not all.

Since developers are not longer splitting time between multiple tasks at once, they can focus on a select few projects - leading to higher quality code as well. This leads to fewer bugs, rework, and inefficiency.

Reducing WIP makes developers faster, more productive, less stressed and producing higher quality code.

That's what we call a "Win Win Win... Win... Situation"

Work in Small Batches (Smaller PR Size)

Working in small batches has dramatic effects on Cycle Time. By focusing on small, manageable pieces of work - developers move quickly through the delivery lifecycle from development to review with less friction.

Smaller pull request size (aka working in small batches) also has these benefits:

  • It reduces the time it takes to get feedback on changes, making it easier to resolve problems.
  • It increases efficiency and motivation.
  • It prevents your organization from succumbing to the sunk-cost fallacy.

Code Spends Less Time on your Laptop (Faster Dev Time)

Faster development times means that code spends less time on someone's laptop. Working on this goal essentially means that changes are likely smaller and easier to review. Smaller, easier to review changes are more likely to get reviewed sooner as they aren't a large disruption to other team member's workflows.

By making our changes smaller and faster to review, we're able to get feedback sooner - which is especially helpful if we're headed in the wrong direction.

This also signals to other team members what you're working on and in which portion of the code - allowing the team to avoid nasty merge conflicts.

Finally, faster development times help us reduce our engineering tendency to overthink, overbuild, and/or prematurely optimize code. All of these factors roll into the larger theme of decreasing Cycle Time.

Did this answer your question?