Hackr News App

<@octo888> Imho cycle time perhaps can only be taken as a reflection across people who are doing similar things (likely team mates) or against recurring estimates if they’re incorrect.

But generally when I’m evaluating cycle efficiency, it’s much better to look at everything around the teams instead. It’s a good way to improve things for everyone across the space as well, because it helps other people too.

<@octo888> YES ALL OF THIS.

- Dev gets a bug report.

- Dev finds problem and identifies fix.

- Dev has to get people to review PR. Oh BTW the CI takes 5-10 minutes just to tell them whether their change passes everything on CI, despite the fact only new code is having tests written for and overall coverage is only 20-30%.

- Dev has to fill out a document to deploy to even Test Environment, get it approved, wait for a deployment window.

- Dev has to fill out another document to deploy to QA Environment, get it approved, wait for a deployment window.

- Dev has to fill out another document for Prod, get it approved....

- Dev may have to go to a meeting to get approval for PROD.

That's the -happy- path, mind you...

... And then the Devs are told they are slow rather than the org acknowledging their processes are inefficient.

<@octo888> It's not just cruel, it's stupid. Not only does cycle time form a very poor measure of individual productivity, using cycle time to measure individuals will create very bad incentives that will make your team perform significantly worse!

<@vasco> No, it doesn't tell you anything. Someone is consistently delivering half the tickets compared to another person. Are they slow, lazy or etc? Or are they working on difficult tickets that the other person wouldn't even be able to tackle? Cycle time doesn't tell you anything about what's behind the number.

<@vasco> Work is never distributed uniformly, that's a silly assumption.

<@vasco> You've misunderstood: cycle time is neither a forecast nor a measure of individual productivity.

Cycle time measures how long it takes for a unit of work (usually a ticket) to move from initiation to completion within a team's workflow. It is a property of the team / process, not individuals. It can be used to generate statistical forecasts for when a number of tasks are likely to be completed by the team process.

For most teams, actual programming or development tasks usually represent only a small portion—often less than 20%—of the total cycle time. The bulk of cycle time typically results from process inefficiencies like waiting periods, bottlenecks, handoffs between team members, external dependencies (such as waiting for stakeholder approval or code review), and other friction points within the workflow. Because of this, many Kanban-based forecasting methods don't even attempt to estimate technical complexity. They focus instead on historical cycle time data.

For example, consider a development task estimated to take a developer only two days of actual programming. If the developer has to wait on code reviews, deal with shifting priorities, or coordinate with external teams, the total cycle time from task initiation to completion might end up taking two weeks. Here, focusing on the individual’s performance misses the bigger issue: the structural inefficiencies embedded within the workflow itself.

Even if tasks were perfectly and uniformly distributed across all developers—a scenario both unlikely and probably undesirable—this fact would remain. The purpose of measuring cycle time is to identify and address overall process problems, not to evaluate individual contributions.

If you're using cycle time as an individual performance metric, you're missing the fundamental point of what cycle time actually measures.

<@jyounker> If it's really important to have an accurate estimate for a large work package you are in trouble, there is no such thing.

<@discreteevent> The book has a chapter about how to optimize variability in the product development process. The key idea is that variability is not inherently good nor bad, we just care about the economic cost of variability. There are lots of asymmetries in the payoff functions in the software context, so the area is ripe for optimization, and that means sometimes you'll want to increase variability to increase profit. But if we're mostly concerned that software development is too variable, there are lots of ways to decrease it, like pooling demand-variable roles, cross-training employees on sequentially adjacent parts of the product lifecycle, implementing single high-capacity queues, etc.

<@discreteevent> PPDF is a great book but hard to apply. I recommend looking at some Kanban literature. Classic in this space is Actionable Agile Metrics for Predictability.

<@tangotaylor> 100% - for me the fact that hasn't been picked up throughout the research undermines the credibility of the rest of the paper.