Are you in FLOW? Do you "Measure what matters?"


Are you working in FLOW?
No, this is not a mindfulness post, seemingly the opposite when I mention metrics, but yes as I learned two nights ago, metrics can be put around FLOW to better understand effectiveness.
No surprises it comes from software development. Flow is a new form of measurement from 1 year ago, so very new, and I get it the value it adds - you know what 'lever' to pull to be most efficient.

"Measure what matters" was a presentation delivered by Gillian Clark to a more advanced group of attendees than myself as part of the Scaled Agile, Inc. series.
As (probably) the only non-practioner of SAFe, but looking to educate myself none-the-less with a vast gap between this presentation and my basic Agile Certification from years ago I took it in, wrote notes and here we go...
Hopefully I can do this justice with a brief rundown in the blog - it should flow pretty quickly...
And I welcome corrections, commentary and feedback in the comments, as thats how we learn (And I will edit the blog and credit updates to sources)

A read of the Glossary of terms will accelerate one ability to learn 

So the presentation started with the basic overview of taking and idea through to digital enablement, looking at the traditional Competency as a benchmark to ad the 1 year old concept of FLOW and the metrics that matter. 

The whole presentation hinged on the concept that there are 4 types of work in Flow, and each other these need to be balanced against the org/product/industry - ie in financial industry the skew will be different by nature of its heavy gov and compliance. Now, those 4 types of work, which appear in the graphs and measurement later are: 

FEATURE - this is a feature and it can be measured in requests/epics/story - but in short it a new feature delivered, which will make more sense as you read the other 3.

 DEFECTS: bugs, issues are an inevitable output of development and I say in my words, you can spend time working on the now as defects, or they will end up in the next catergory, but grow from what they start as to something bigger and uglier. 

DEBT: Technical Debt - just like debt in your bank account, you can get in the black until you get out of the red so you have to spend a lot more effort digging your way out and this can be from basic delivery, like building a house out of untreated timber, in 10 years it will rot and its not just a paint of the outside, but a full structural replacement while a family is living inside it (does that make sense?) 

RISK: Ahh that old chestnut, whats the risk of that happening? Technically 0.00000001%, but apply Murphy's or Sod's law... so yep we are talking about Security and other matters where its a risk, and thats what makes it hard for some to stomach the amount of investment required for what is like insurance, an ugly cost we likely never need but actually just need to cover it. 

Now how do. we measure these 4 things together in an understandable way? Thats typically an art in itself and I remember interpreting a wall of online ad stats and once I learned how to interpret them it gave a different meaning to simply reading them. 

Therefore there are a range of metrics which if you think of like levers, you need the right mix to hit operational efficiency for your org, your industry. 

Flow Velocity: How many Epic's, Features am I delivering? The meaningful count is how much value did we deliver to our customers? 

Flow Time: How much time was spent delivering - there was a chart with some almost unbelievably low number of development time as the average or standard like 2 days out of 100 - 

Flow Efficiency: This is Flow Time divided by Wait Time then a lovely graph of Flow time (Design, Dev, Testing, etc) and Wait Time which is the time between each delivery time ie waiting for designs to be signed off to then begin development. ie 10 Delivery days vs 30 Wait days = 33% efficiency. 

Flow Load: I'm not sure I understood the difference between Flow Time and Distribution but even others asked and I didn't listen as I was taking notes, so someone fill me in here, perhaps I'll work it out from looking at the two pages and their graphs.

I'm not sure I got all the detail on this one but may have enough, but from "From Kanban" and an accumulative graph showed the relationship between the 4. Ie the higher the feature section in one integration, the higher the Defect, debt and Risk in the next. 

Flow Distribution: I'm not sure I got all the detail on this one but may have enough, but from "From Kanban" and an accumulative graph showed the relationship between the 4. Ie the higher the feature section in one integration, the higher the Defect, debt and Risk in the next.

Flow Predictability: This appeared to be the gold as it shows the Business Value Gained, but few use it in NZ because it is so subjective. I say 10 from 10, you say 2 from 10... mmm who is right? We could spin wheel debating or we could get on with the next iteration as the customers really show the value through their use or purchasing so thats a clear metric of value worth looking at... 

To bring it all together Gillian took us through a dashboard showing how these all interrelated and if we pulled this 'lever' it would affect that outcome later on... I guess the art is in balancing the metrics according to your product/org/industry and do so take understanding. 

So, how is my flow? I gotta say, I was in flow writing this from my notes, but this is just a feature and now the Defects will be found and pending how bad they are I may have some Debt to research and replace and the risk is I've opened myself to complete ridicule, but I feel secure in dealing with that. 

In short, I added a huge amount in one hour to my understanding, I have to thank the Jedi Master as I am beginning my journey to master the force, I mean flow!