DORA & flow metrics
Transition to “flow” in DevOps will lead to reduction in the cycle time of DevOps. This is, per definition of DORA, reduction of Delivery Lead Time, or Lead Time of Changes. This is the time concerned with “flowing” a change from merge to deployment.
Decreasing batch sizes in DevOps, ultimately deploying in one-piece-flow, directly leads to reduction of the DORA metric of Deployment Frequency. Above we argued how cycle time reduction, and reduction of feedback time through that, leads to quality increase and rework decrease. Along the same lines it can be argued how it will lead to a reduction of DORA metrics Change Failure Rate and Mean Time To Restore (or Time To Restore Service).
From this you can directly see how the impact of transition to “flow”, can be measured based on DORA metrics. At least, in DevOps.
Now consider that you want to achieve “ultimate flow” (one-piece-flow), via step-wise improvements, or “continuous improvement”. In terms of the “water and rocks analogy”, as used above, you want to lower the water level in DevOps step by step. And you may define milestones per each step, setting objectives for DORA metrics per each milestone. The lower the cycle time is, the shorter the time between the milestones can be, and the more frequent these DORA metrics can be re-evaluated.
Consider now that you observe, at a certain milestone, that a certain DORA metric did not improve as expected. It will not take you long now to find the underlying problems that cause this lack of performance. Because, due to the short-cyclic nature of “flow DevOps”, there is only a very small set of changes that need to be sorted out. These are the changes that are still fresh in mind of the developers, reviewers, testers, etc., that worked on these changes. In other words: transition to “flow”, in DevOps, makes measurement and continuous improvement of DevOps itself, really effective!