For that the concept of “Flow” seems quite good. How quick do we get somewhere (Velocity/Lead time), how much capacity do we have (Throughput), what are the impediments (Risks) to get there?

Typically you can optimise for one or two of the above, but it is really a triangle.

The other view is what do you measure? Can you map this to $$$ (execs)? Can you map this to deployments/speed (ops)? Can you map this to “happiness” (devs)? As example/

Some velocities:

• first commit to merge (in branch-based dev) • Jira ticket opened to delivered ◦ features vs bugs vs … • build/deployment start to finish • etc.

Ideally: first idea to out of the door, but tying this all together is not easy.

@Tim Fischer I can share the slides later with you and follow-up if you don’t get them by default.

As far as I understand, optimising just one of the components you mentioned wouldn't bring much of a utility

Right?

If you have a 100 engineers and they get the code in quicker and reviews are not delayed etc. that is a huge payoff.

I think end-to-end is idealistic but no realistic.

The other aspect is visibility to make decisions. Most of the time management has some gut feel but no good data because it is stuck 1 or 2 levels down.

To be honest, engineers are not the high value target for dashboards in itself, but they should be happy for someone to see it and see this as a means to communicated up.