Hello <@U02MAFSM535>, great talk! What other metri...
# platform-blueprints
t
Hello @Ralf Huuck, great talk! What other metrics besides DORA would you recommend focusing on? And how to measure. I found also these different kinds of velocities interesting. Would love to learn more about that.
r
Thanks a lot @Tim Fischer! Vast subject and each stakeholder likes to see something different that’s why we think what is the right mental concept that more than one stakeholder can align to.
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.
t
Thank you for such an informative response! Yes, slides would be much appreciated 👏
👍 1
As far as I understand, optimising just one of the components you mentioned wouldn't bring much of a utility
Right?
r
I think it still would. Just see where the value is and where things are stuck.
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.
t
Exactly! The latter is the problem we face at my current company. The management puts the gut feeling first without any measurements beforehand...
r
Yes, and engineers don’t like to be measured 🙂 So it’s important to measure process and value and not people.
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.