Comment by octo888
15 hours ago
> The primary value of measuring cycle time is precisely that it captures end-to-end process inefficiencies, variability, and bottlenecks, rather than individual effort
Yes! Waiting for responses from colleagues, slow CI pipelines, inefficient local dev processes, other teams constantly breaking things and affecting you, someone changing JIRA yet again, someone's calendar being full, stakeholders not available to clear up questions around requirements, poor internal documentation, spiraling testing complexity due to microservices etc. The list is endless
It's borderline cruel to take cycle time and measure and judge the developer alone.
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.
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.