How to Reduce Cycle Time?

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

How to reduce cycle time? It is an important question, especially because reducign cycle time is probably the holy grail of software development. If you’re improving it, reducing it, you’re likely improving everything that feeds into it. Cycle time is so important that it actually is worth obsessing about. Nanoseconds count, just ask the NYSE. As we only live an average of 2.5 quintillion nanoseconds, it’s a wise DevOps manager who makes them all count!

Cycle Time in Agile

Cycle time, for our purposes, is the time between when you start and finish work on a task. It does not include any time a task sat in a queue waiting to be started. For more depth about cycle time’s role, check out our earlier article on Cycle Time in relation to Lead and Takt Time.

Date Finished - Date Started = Cycle Time (in days or hours)

Why are Cycle Time Improvements Important?

Every validated improvement in cycle time provides the potential to improve cycle time further. Validated in this context serves to emphasize as (our CEO) Renata Pataki advised, “an improvement in any other metric that leads to a decrease in quality is not an improvement.” Improving quality is always the control for validating any change in process. That said, improving cycle time translates to:

  1. Increased productivity = delivering value faster = reduces time to market.
  2. Higher quality software = fewer bugs = happier end users.
  3. One + Two = improved profitability = happier clients (or executives)
  4. Happy clients = continued contracts + referrals = more work.
  5. More work = team growth + promotions = happy teams
  6. Happy teams = lower turnover = increased efficiency
  7. Increased efficiency = continued improvement of cycle times
  8. Go Infinite. Cycle back to step one… over and over – until we reach Singularity!

Two more items should also be inherent to this overall process – efforts to improve team collaboration and continuous skill growth. These two components are really at the heart of the process and are built into it with daily standups, code reviews, mentoring, and retrospectives.

It helps to take a step back from the lines of code to see just how beautiful the Big Picture is and how everything fits together. Yes, yes, resistance is futile.

So, How Do You Reduce Cycle Time?

Where to even start? Start simple and add complexity only as needed.

Well-Defined Task Requirements

Much as with taking the time to properly define project requirements, it’s worth being clear about task requirements, too. More ambiguity equates to more room for misinterpreting the task. Tasks are usually defined in the project management software you’re using (Jira, Trello, Monday, Wrike, Clickup, Asana, TeamGantt, Backlog, ProofHub, Zoho Projects, the list goes on…). That there are so many PMS options is a subtle indicator that people have issues with their PMS options. The remedy is almost simple: a) make sure your team is trained on your PMS, and b) set a clear standard for defining and tracking tasks.

Team-Calibrated Story Points

Complexity and difficulty is subjective. Story points are an estimation of the quantity of work, complexity and uncertainty associated with a task. Though not always more accurate than “time-based” estimates, story points are more flexible as they aren’t tied to individual skill levels and don’t need to be “resized” if something changes. If something does change (a team member goes on vacation or the team’s efficiency increases), you can adjust the number of story points with each sprint.

The poker system assigns points in a democratic fashion (secret votes that are simultaneously revealed). Substantial variations may be discussed or you may simply assign it the most points as Planning Poker suggests if you have a mature team. It’s useful to define and share examples, conditions, and characteristics of story point values so that everyone has a common point of reference.

Most teams use the Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21) as each increment is noticeably different (~60%). Instead of quibbling over whether a task is a 3, 4, or 5, assigning it the highest value still accommodates everyone. It reduces the risk of the task spilling over into the next sprint. If someone finishes all of their tasks early, they can either help others finish their tasks or take a new one from the backlog. Either way, it’s all reflected in team velocity which is helpful in planning future sprints. This doesn’t improve cycle-time per se.

Break Everything Into Small, Meaningful Tasks

Small is relative. Though story points may not equate to time, there’s likely some loose correlation. Some tasks might take 6.048e+14 nanoseconds (a week for you non-obsessed types out there), others just a day or a few hours. Trunk-Based Development and Continuous Integration (Delivery and Deployment) efforts advocate for frequent commits (daily or even more frequent) to allow for fast feedback.

Experienced developers likely already know how to break up their tasks into smaller pieces. They might need to be called upon to assist your Scrum Master in defining logical divisions of tasks for less experienced team members.

Agile Team Size

Scaling teams efficiently is one aspect of improving cycle times. Agile promotes cross-functional teams with 3 to 9 members, with 7 team members being close to an industry average. It’s worth reiterating Conway’s Law, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” As noted there, team size can be impacted by the manager’s capacity, team-member cross-functionality, project complexity, financial restraints, and project stage.

Leastwise, bigger teams don’t equate to greater productivity or efficiency. Larger teams inherently equate to increased inefficiency and complexity – it’s something that we bump up against in several different ways (like communications and code review/approval processes).
This is not to say that you can’t have “bigger teams” – the ultimate goal is to create teams of teams. Or to quote PerceptionBox, in attribution to Brigadier General (US Army Ret.) Bernard Banks, Ph.D. in his discussion of Agile team development,

“Companies must become a team of teams.... [each having] a “shared understanding of the desirable outcomes, situational influences, and a cogent awareness of the steps that each member must take to achieve a performance outcome.”

Communication Protocol

Sometimes developers have questions. Our increasingly post-apocalyptic distributed work environment means you can’t throw a paper airplane at a developer to get an answer to an urgent question. Everyone on your team may be working in different time zones, hours, and days. This warrants establishing priority-based communication protocols as we shared in How to Manage Distributed Agile Teams. We have a variety of tools like Slack, Zoom, Sococo, email, and mobile phones to accommodate fixed, routine, casual, urgent, and SHTF communication requirements. Efficient communications may not always improve cycle time, but inefficient comms can really hurt it.

Automated Software Development Analytics

Our expertise here at Gitential is in providing advanced analytics to help software development teams improve their speed, code quality, coding efficiency, and team collaboration. A variety of reports help software engineering managers to see and better understand their team’s coding behaviors and proactively mitigate delivery risks. In terms of process, automated analytics makes it easy to spot issues, examine the impact to better understand why it’s happening, and take action to resolve it.

  1. Easily spot outliers and at-risk tasks and projects.
  2. Quickly investigate the factors contributing to the risk.
  3. The data gathered helps to understand the problem and likely contributing factors.
  4. Steps can be taken to resolve the problem – adjust process or talk with the developer.

Software development is complex, analytics provides a data-driven way to evaluate team and project health. The benefits apply to help developers improve their coding speed, quality, efficiency, and teamwork skills. Managers can also put the analytics to work in optimizing teams around project requirements – as with specific languages and complexity levels.

Holistically speaking, by improving one metric, you’re likely to influence improvements with several metrics – up to and including reducing cycle time.

Shameless plug, but we welcome you to give Gitential a free try – no credit card is needed.

One of our main use cases helps to understand how one team’s code complexity increased as it added new team members. Increasing team size inherently increases complexity. Adding new team members inherently increases inefficiency. The team would have been better off adding one or a few developers with the specific expertise needed for their project vs adding fifty contributors.

Teamwork

Teamwork is the key to tackling anything, including efforts to improve teamwork. The insight gathered from software development analytics can be used when pairing developers for code reviews, mentoring, daily standups, retrospectives, and even continuing education programs. With each retrospective, your team can choose 1-3 metrics to try to improve and how to track progress. A moment or two in your daily standups can be used by the team to share tips for improving each metric. Code reviews and mentoring assignments based upon language skills and experience can help develop team skills in two languages (almost) simultaneously. Again, efforts to improve one metric ultimately help improve a few metrics, ultimately helping to reduce cycle time. Over the course of a year, your team can cover 26+ different metrics.

Automation - CI and Double-CD

The greatest improvements to cycle time are likely to come through automation, starting with Continuous Improvement (CI), and onto Continuous Delivery/Deployment (CD). These steps need to be guided by Agile methods and practices with a DevOps mindset in applying tools to automate work processes and testing. Both CI and CD seek to enable developers to push their code deeper down into the distribution funnel – reducing the need for human intervention to review and approve their commits. The 2020 State of DevOps report by Puppet directly ties human intervention or “orthodox approval” to inefficiency, scaling more or less proportionately to team size. Going back to their 2016 report, they showed that teams with mature/high-performing DevOps (employing CI/CD) deploy 200 times more frequently than those with little or no automation. But, more than that, their lead times were 2,555 times faster, had mean time to recover rates 24 times faster, and all with a 3x lower change failure rate. Teams with mature CD capabilities are deploying multiple times per day instead of once every few months. Perhaps the most complex part is automating the testing in production-like environments. However there are many services available to do that as we covered in Continuous Delivery/Deployment. Between their ML/AI, advanced pattern analytics and algorithms, computers can process in far fewer nanoseconds than… carbon-based lifeforms.

More Advice on Reducing Cycle Times

It’s worth obsessing about improving cycle time, to a point.

Automate Your Software Development Metrics

Gitential helps you to improve the performance of your software development team based on their Git activities with actionable insights. It’ll help you automate the gathering of software developer and engineer performance metrics, interaction analytics, frequency of commits, volume of code churn, and more! With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more. Try Gitential now for free – no credit card needed!

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.