A useful starting point is the path from a recognised need to an outcome used by its audience. If implementation takes three days but the scope decision waits six weeks, increasing coding speed will not solve the problem. Queues, dependencies and too much work started at once need to become visible.
Flow without quality is not an improvement
Delivery time and deployment frequency should be read alongside change failures, recovery time and rework. Faster flow that creates more production problems merely defers the cost.
A delivered change still needs the intended effect
A team can release unused features efficiently. Every important initiative therefore needs a measure connected to its purpose: shorter handling time, a higher completion rate, fewer errors or a change in user behaviour. It also needs a guardrail that prevents one result improving at the expense of another.
In practice, a small and stable set of measures with a regular review is enough to begin. The review should end with one experiment: limiting work in progress, simplifying a decision, automating a test or removing a dependency. Only then can the team check whether the expected signal changed.