Planning iterations accurately and delivering on promises is impossible if Cycle Time is too long (think the majority of a sprint). The biggest drag on Cycle Time? PR idle time.
And half of PRs are idle for 50.4% of their lifespan.
Everyone on the team has a part to play at every stage when reducing Cycle Time.
Leadership needs a bird’s eye view into the engineering organization’s performance, its position within the industry, and which parts need to improve. They then need to work with team leads to set goals, track progress, and communicate success to the business.
Team managers need to investigate further, identify bottlenecks, and work with their team to set and track progress on improvement goals.
Developers need to agree to changes, stay informed on goals, and be the agents of change.
Here are the steps to improve engineering efficiency with LinearB:
DORA defines Lead Time for Changes (a.k.a Cycle Time, a.k.a the best proxy for efficiency) as when work begins (e.g. first commit) to when code is delivered to production and into customers’ hands.
Within that metric there are several phases.
Improve one (or ideally all of them) and watch your efficiency, predictability, and value delivery improve in turn.
There’s a lot of information to glean from this “home” dashboard. Where work is being done, the different phases of Cycle Time, the team’s workload, etc.–and all of it informs efficiency. At a glance, you can see:
Once you have a high level understanding of your team’s efficiency, get some additional context and see where you are using our engineering benchmarks.
Ultimately, you know your team and your code base better than we do. Come up with your definition of good based on your current performance, priorities, objectives, and what’s realistic.