Running Experiments To Create Change w/ Dominica DeGrandis of TaskTop

**Dan** (0:22)
That's where Dominica DeGrandis comes in as the Chief Flow Advisor at TaskTop and author of Making Work Visible. Dominica has been helping teams make big changes for decades.
And now she is joining us on Dev Interrupted to explain the steps we can take to start making a change inside our organizations today.

**SPEAKER_2** (0:43)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**Dan** (0:58)
Dominica, thanks for joining us today.

**Dominica DeGrandis** (1:02)
Thanks for having me, Dan.

**Dan** (1:04)
I'm so happy to have you on the show today. What I know about you, and I think many people probably know about you, is you are one of the earliest pioneers of engineering metrics and kind of team experimentation.
This is a subject that is really near and dear to our hearts and our mission at Linear B. But for anyone who hasn't read about Flow before, can you explain what Flow is and some of the top level metrics for Flow and how they came to be?

**Dominica DeGrandis** (1:39)
Yeah, you bet.
So Flow is the movement and delivery of customer value through a process. And in knowledge work, I mean, the reason that we're here is to, you know, deliver customer value. So that's why our process is typically oriented and optimized for Flow, right? And typically it's discussed in terms of value stream management. All the activities that occur to get this customer value through the value stream starts with the customer, ends with the customer. And that's why some of the metrics around Flow are related to what customers might grumble about, right? Like how long things take. Where's my thing? I've been waiting forever for this. So in that, we're gonna measure flow time, probably more commonly heard of as lead time or cycle time to many people. We wanna measure, I mean, the three key metrics are Flow are gonna be out of Little's Law and that's gonna be cycle time, your flow time, your queue length, your work in progress and your throughput. We call that Flow Velocity at TaskTop. And so Little's Law is a relationship of averages between those three metrics that are so key.
In addition to that, we also consider flow efficiency because we wanna know where does work get stuck on its way? Where does work sit idle? Where are the bottlenecks? How efficient are we at doing our work?
And then the other flow metric that I think is critical is flow distribution. And this is the ratio of the types of work that are being done. So, one of the common problems in IT often is that work is prioritized by business people, by product owners upstream, and they're inclined to approve feature driven work. It's like we then get into a feature factory and this important work that would be like revenue protection work, the fixing technical debt, the keeping the lights on, the security work, all this revenue protection kind of work tends to take up on the back burner.
So flow distribution brings visibility to what's the nature of the work that we're doing and what does a healthy value stream look like? And it's not gonna just be 100% features, right? We need to be able to be improving our technical debt. We need to work on bugs and defects too. And we need to pay attention to security.

**Dan** (4:37)
Well, yeah, I'm actually really happy for example, that you mentioned flow distribution.
Sometimes at Linear B we'll call that the team's investment profile, which is measuring how much effort or emphasis we're putting on those different types of work. And what I've seen is when engineering organizations are actually able to invest in things like technical debt and not only work on feature work, your cycle time or the team's cycle time actually has a chance to improve, which is one of the reasons I'm a pretty big proponent of more team-based metrics as opposed to like individual metrics.
But kind of on the flip side, what I've seen you brought up kind of human behavior is that change can also be hard. And I don't think anyone's going to kind of debate that. If you're doing one thing for five years or 10 years and now we want to come into an engineering organization and increase our flow, get more value out to customers faster, and we may need to change in order to do that, that's going to be really hard. And I know that for you, you have worked with a lot of organizations and kind of helped them probably overcome some of this institutionalization, whatever is kind of ingrained in them. And I'm really curious to ask you, in your experience, what is the easiest way to overcome kind of that resistance to change?