Back with another article! I’m going to discuss effective ways in reducing cycle time via work in progress limits and other methods for kanban / lean software delivery. These concepts can apply to scrumban as well. Make sure you familiarize yourself with DORA metrics as well as I give a high level overview.
What is cycle time?
In a software delivery context, cycle time is the period it takes from the moment a team begins work on a new feature, enhancement, or bug fix, until it’s delivered to production. Aka done done. Not dev done. This includes all the stages of the software development process such as coding / development, testing, review and deployment etc. It’s not done until it’s in the hands of the customer!
Cycle time is an important metric because it helps teams understand their delivery speed and efficiency. If a team’s cycle time is long, it may be a sign that there are bottlenecks in the development process that need to be addressed. Shorter cycle times typically indicate a more efficient process and faster delivery of value to users.
While cycle time is a useful metric, it’s also important to consider other factors such as the quality of the work delivered. A short cycle time is not beneficial if it leads to a high number of bugs or a product that doesn’t meet users’ needs. Thus, teams should strive for a balance between speed and quality.
How do we reduce cycle time on the team level?
A few ways to reduce cycle time on the team level are the following:
WIP Limits
- Work In Progress (WIP) limits are a fundamental aspect of Kanban, a popular method for managing software development in a highly efficient way. WIP limits are designed to limit the amount of work in progress at any given time. They help manage flow, reduce waste, and make blockers and dependencies more visible.
Setting a limit on the number of work items in the various stages of the workflow process can have several beneficial effects that could potentially reduce cycle time:
- Reduces Multitasking: When there’s too much work in progress, team members can end up multitasking, which actually reduces overall productivity due to the cognitive load of switching between tasks. By limiting WIP, teams can focus on completing one task before moving on to the next, which can make the work go faster.
- Improves Flow: WIP limits encourage a smooth, continuous flow of work, which can help to identify and eliminate bottlenecks or inefficiencies in the development process that might be extending cycle times.
- Increases Visibility of Problems: When there’s a limit on work in progress, it becomes much easier to see when work is piling up or getting stuck at a particular stage in the process. This can highlight problems early so that they can be addressed before they significantly affect cycle time.
- Fosters Quality: By limiting WIP, teams can spend more time on each task, potentially leading to higher quality work. This reduces the time spent on fixing bugs or rework, which in turn can reduce the cycle time.
By limiting work in progress, teams can keep their process lean and efficient, which may help to reduce cycle time and improve the overall speed and quality of software delivery.
Reduce Bottlenecks / Delay
Focusing on bottlenecks in your software development process is one of the most effective ways to reduce cycle time. A bottleneck is a stage in the process where work gets backed up because tasks are arriving faster than they can be processed. This slows down the entire process, as work can’t move forward until the bottleneck is cleared.
By identifying and addressing these bottlenecks, you can significantly improve your process and reduce cycle time. Here’s how:
- Identify the Bottleneck: The first step is to identify where the bottleneck is occurring. This might be a particular stage in your workflow, such as testing or code review, where tasks tend to pile up. Use metrics like lead time, cycle time, and work-in-progress (WIP) to identify where tasks are getting stuck.
- Understand the Cause: Once you’ve identified a bottleneck, you need to understand why it’s occurring. Is there a lack of resources? Is the task too complex? Are there dependencies that are causing delays?
- Address the Bottleneck: After understanding the cause of the bottleneck, take steps to address it. This might involve adding more resources to a stage of the process, simplifying complex tasks, removing dependencies, or even redefining your workflow.
- Monitor the Process: Once changes have been implemented, continue to monitor the process to ensure that the bottleneck has been resolved and to catch any new bottlenecks that might appear.
Focus on finishing to reduce cycle time
Kanban / Lean encourages teams to focus on completing existing tasks before starting new ones. This is in direct contrast to taking on more and more work, which can lead to multitasking, decreased productivity, and increased cycle times.
In other words, “stop starting, start finishing” is a mantra often associated with Kanban & Lean. This refers to the idea that instead of constantly starting new tasks (as new requirements come in), you should concentrate on finishing what is currently in progress.
A few ways “focusing on finishing” is accomplished in Kanban include:
- Work-In-Progress (WIP) Limits: As mentioned earlier, WIP limits restrict the number of tasks that can be in progress at any given time. This forces teams to focus on completing tasks rather than starting new ones, as no new task can be started until an existing one is completed.
- Visualize the Workflow: Kanban boards are used to visually represent the workflow, making it easy to see how much work is in progress, how much has been completed, and how much is still in the backlog. This helps team members see the importance of completing tasks and not overloading the workflow.
- Pull System: In Kanban, work is “pulled” into the next stage when there is capacity to handle it, rather than “pushed” as soon as it’s ready. This ensures that each stage of the workflow only has as much work as it can handle, making it easier to focus on finishing tasks.
Look at statistical outliers and shift left
Outliers are a super important piece to look at. Constantly looking at these and having retrospectives are doing analysis on them will help provide you with data to have discussions around performance improvement. Some steps to looking at statistical outliers are the following:
- Identify Bottlenecks or Problem Areas: Outliers can point to bottlenecks or areas in your workflow that are causing delays. For example, if a particular task takes significantly longer to complete than most other tasks, it might be a sign that this task is more complex or there are issues that need to be addressed.
- Improve Estimations: By understanding the reasons behind outliers, teams can improve their estimations for similar tasks in the future. This can lead to more realistic planning, better resource allocation, and eventually, reduced cycle times.
- Eliminate Waste: Outliers can indicate unnecessary steps or inefficiencies in the process. By identifying and eliminating these, you can streamline your workflow and reduce the overall cycle time.
- Quality Improvement: If outliers are due to high defect rates, understanding the root causes can lead to improvements in quality. Higher quality means less rework, which can reduce cycle time.
How would I measure outliers if I’m starting out?
In order to measure outliers, you can do this via excel or some other tool, There’s quite a few tools if you use jira but you can honestly do this for free. It becomes a problem when you start scaling.
- Gather Data: First, you need data. Depending on your context, you may need to gather data on task completion times, defect rates, code review times, etc. This data should be specific, measurable, and relevant to the cycle time. It could be gathered from project management tools, version control systems, or any other tools your team uses. Ie, how long did it take to go from dev to done for 30 tickets. That could be a manual step and process.
- Visualize the Data: Visualizing your data can make it easier to identify outliers. You can use various methods to do this. For example, you could plot task completion times on a scatter plot or a box-and-whisker plot. These plots can make it easy to see points that fall far from the others.
- Identify Outliers: Once you’ve visualized the data, identify the outliers. These are the data points that are significantly different from the others. In a box-and-whisker plot, for example, outliers are usually the points that fall outside the “whiskers”. For example, I like to look at tickets that are 90% or higher statistically and see where the delay came from. Ie, if a ticket took 300 days to complete (just an example) and it’s one of my outliers, I will investigate the steps where it got stuck and see if there’s any pattern matching.
- Analyze Outliers: Once you’ve identified the outliers, the next step is to analyze them. Why was this task’s cycle time much longer or shorter than the others? Was it more complex? Were there unexpected problems? Or maybe a new approach led to a reduced cycle time? This may require some digging and discussion with your team.
- Make Adjustments: Based on your analysis, identify potential adjustments. If a task took a long time due to its complexity, you might need to break it down into smaller tasks in the future. If a task was completed quickly due to a new approach, you might want to consider adopting this approach more broadly.
- Monitor Changes: After you make adjustments, continue to monitor your cycle times and other relevant metrics. Has the average cycle time decreased? Are there fewer outliers? Regularly reviewing your data can help you continue to identify and address outliers and further reduce cycle times.
Why is it important to reduce cycle time?
Cycle time isn’t the end all be all. However, it is an important factor of high performing teams. Here are some important reasons as to why a team and organization should reduce their cycle time.
- Faster Delivery: A reduced cycle time means that new features, enhancements, or bug fixes can be delivered to users more quickly. This can provide a competitive advantage in today’s fast-paced software industry.
- Better Responsiveness: Shorter cycle times make the software development process more adaptable and responsive to changes. If a new user requirement or market trend emerges, teams with shorter cycle times can adapt their products more quickly. No one wants to work on stuff from 2 years ago when it’s no longer needed!
- Improved Efficiency: Reducing cycle time often involves streamlining the development process, removing bottlenecks, and improving efficiency. This can lead to better use of resources and cost savings.
- Increased Customer Satisfaction: Customers often appreciate quick and regular updates to their software. By reducing cycle time, you can increase customer satisfaction and retention. Shorter cycle times mean faster feedback from users, as new features or changes reach them more quickly. This feedback can then be used to further improve the product.
- Reduced Risk: Delivering more frequently (a consequence of reduced cycle times) in smaller increments can reduce the risk associated with large, infrequent releases. Issues can be detected and fixed sooner, which minimizes their impact.
- Better Quality: When focusing on reducing cycle times, teams tend to put a spotlight on their development process. This can lead to an improvement in work quality, as inefficiencies and error-prone practices are addressed.
Closing
There you have it. A few beginner tips on reducing cycle time. We can get super in depth but it’s tough to write everything out. If you’re curious about how I implemented this and achieved a 60% reduction in some areas organization wide, feel free to contact me! Let’s work together.