Roundtable Discussion: Perspectives on Cycle Time - Code Climate Blog

Roundtable Discussion: Perspectives on Cycle Time

This post is part of our historical archive. It represents the beliefs, actions, products, and services of Code Climate as of its publication date. Today, Code Climate focuses on providing enterprise leaders the software development data, context layer, and playbooks needed to build the AI-native software organization their enterprise needs.

Natalie Breuer
Nov 5, 2020
• 13 min read

Your engineering speed is your organization’s competitive advantage. A fast Cycle Time will help you out-innovate your competitors while keeping your team nimble and motivated. It’ll help you keep feedback loops short and achieve the agility necessary to respond to issues quickly. Most importantly, it’ll align everyone – from the CTO to the individual engineer – around what success means.

To discuss Cycle Time and its implications, we invited a panel of engineering leaders and industry experts for a virtual round table.

Code Climate Founder and Former CEO, Bryan Helmkamp, was joined by:

Over the course of the hour, these panelists covered topics such as using metrics to design processes that work for your team, building trust around metrics, and tying delivery speed to business success.

Here are some of the key takeaways:

Prioritize innovation over semantics.

Bryan Helmkamp: When I think about Cycle Time, I think about the time period during which code is in-flight. And so I would start counting that from the point that the code is initially written, so ideally, the time that that code is being typed into an editor and saved on a developer’s laptop or committed initially, shortly thereafter. Then I would measure that through to the point where the code has reached our production server then deployed to production.

Bala Pitchandi: I define Cycle Time as when the first line of code is written for a feature — or chore, or ticket, or whatever that may be — to when it gets merged.

Bryan Helmkamp: I think it’s also important to point out that we shouldn’t let the metrics become the goal in and of themselves. We’re talking about Cycle Time but really, what we’re talking about is probably more accurately described as innovation.

The faster you fail, the faster you innovate.

Bala Pitchandi: When I was pitching this to our executive team and our leadership team, I used the analogy of Amazon and Walmart. Most people think that Amazon and Walmart are competing against each other on their prices. But keeping aside the technology parts of Amazon, they’re basically retailers. They both sell the same kind of goods, more or less...

Katie Womersley: The most interesting business discovery we’ve had from using Cycle Time has been where it’s been slow.

Embrace resistance as a learning opportunity.

Katie Womersley: I got quite a bit of pushback on wanting to decrease Cycle Time.

Bonnie Aumann: Esther Derby has a podcast called Tea And The Law Of Raspberry Jam...

Design a Code Review process that works for your team.

Katie Womersley: Something that we do – and this is really controversial – but the vast amount of PRs are merged without review...

Bala Pitchandi: I couldn’t agree more on the over-relying on reviews.

As coding days go down, productive impact scores go up.

Bala Pitchandi: I guess, of all the bad things that happened with the global pandemic, one benefit was that we all went distributed...

Bonnie Aumann: We’ve been remote from the beginning. The pandemic made everything more intense...

Katie Womersley: I have a great mini-anecdote on that. We switched to a four-day workweek to get ahead of burnout with the pandemic...

Agile provides teams with valuable vernacular, but be wary of doing agile by the book.

Bonnie Aumann: I think it’s complicated, but I’ll try and narrow it down...

The more you rely on concrete data, the more flexible you can be.

Katie Womersley: It’s so important to look at your metrics and figure out what actually works with the team you have and the situation you’re in...

Bryan Helmkamp: Your point reminded me of an interesting quote about agile...