00:00:02

Thanks for coming. Good to see you all. I am Dominica DeGrandis and I spent a lot of time helping organizations make their work visible so they can see where bottlenecks are and pain points. So then they can start to do something about it. Ah, I worked for Tasktop lovely company, delighted to be there. Uh, in this session, what we're going to do is we're going to look at some of the problems that are caused by time thieves. So conflicting priorities and unplanned work and unknown dependencies and whatnot. And then we're going to see how we can expose those problems using flow metrics. All right. So the plan is to expose these common problems using flow metrics so that you can make better business decisions. And the whole point of this is that there's no lack of data collection at the team level, right? If you've got MTTR and you're collecting your change failure rates and how much load teams have then at the team level, it's easy to optimize for that and to see how you're doing and make improvements.

00:01:11

The problem is that there's few compelling sets of data at the high level, right at the organizational level to help you make better decisions. And so if we bring in flow, remember flow it, most of you already know, probably right flow is the first way of dev ops because in order to deliver customer value quickly, right work needs to flow rapidly and smoothly and predictably through the value stream. And so we are working to help decision makers, primarily how many in the room are decision makers or, you know, upwards leadership. Okay, great. Uh, because this is what flow metrics help provide, trying to help you improve your business decisions. So there's five thieves of time that I believe if we could expose, make visible, start to track, could help us improve our throughput and delivering value. Let me introduce them to you real quickly in yellow on the left is thief unplanned work.

00:02:17

These are the interruptions that plague our day. These are the, I can't get the bill to compile, you know, I can't log into the test environment. Can you help me in blue is thief conflicting priorities. These are all the questions like, are we supposed to be working on a or B right now? And if the answer comes back as both, then this thief is probably trolling you in orange, in the middle is what I call that big bully theme. This is thief, unknown dependencies. These are the, oh, by the way, uh, the schema changed yesterday. Like didn't you get the memo? And then in green is thief neglected work. This is usually important work, but it keeps getting delayed, uh, usually by some kind of, you know, revenue generating promise and keep pushing back on neglected work and then on right. And pink. That's the ringleader of all the thieves.

00:03:16

This is the too much work in progress because in one way or another, all the time, thieves play into us having our plates too full, just having too much work on our plate. If there were, if I were to come up with another time thief, I would probably come up with maybe anti-patterns with metrics and how they measure individual teams, right? Because this is, this is John smart from John Smart's talk last year. How many of you saw that fabulous keynote? And he's talking about, look, how ads are we are in dev. Yay. Right? And so when we're just measuring and trying to optimize for one particular function or silo, this is what can happen. Um, but upstream, there's all kinds of problems going on. You've got a monthly triage process. There's a quarterly steering committee review where there's participation happening. And then there's annual approval meetings that need to occur.

00:04:21

So if you want something done in 2020, you need to have had it approved by 2019. All right. How can you call yourself agile or dev ops if you've got these huge extended wait times upstream, it doesn't really matter how fast when piece of the value stream is moving when the bottleneck is somewhere else. And so if you're, if you're doing the dev ops, maybe the right hand side of the value stream is all automated and roll and fast. If not, if you're still doing, you know, monthly integration and quarterly releases. Now you got bottlenecks on both sides of your optimized development function. So what to do about this? Um, we're gonna look at five flow metrics, okay. Flow time. So velocity flow, distribution flow load, and flow efficiency. And we're gonna show you how to expose the time thief problems so that you can do something about it.

00:05:21

And we're going to start with, can I get a clock on up here? Thanks. So we're gonna start with thief unplanned work. This is the problem where things take too long, because when you ask, when I ask most leaders, what their biggest pain point is, they said, things take too long, right? We're always waiting for how you know, on something. Uh, often not always, but often things take too long because of unplanned work. It's all this variability in the system, all these things that we can't anticipate, all these things that we don't know yet, that then interrupt our workflow. And it's what delays planned work, unplanned work, delays, planned work. And it's often invisible. This is an attempt here to bring some visibility to unplanned work, because usually it is just invisible. We can't see it. And that's what steals your predictability away, right? Sometimes we'll set target dates, maybe arbitrary, but we need to get this thing done by October.

00:06:23

And if we're only tracking the planned work, then all the unplanned work at, which is what is preventing us to get work done. Why things take longer is invisible. And so because of that, because people will grumble about things take too long. My first question is, well, how long are things actually taking, right? How are you measuring speed? And there's a number of different ways organizations measure speed. Uh, traditionally they look at lead time and in the literature lead time is typically from when, when the customer declared, they wanted something to, uh, when it's available for them. If we're looking at the dev ops handbook, then maybe we're interested in delivery lead time, which measures the right hand side of the value stream, write code, commit to when that's done, but in all the work that I've been doing with organizations, when I asked them, where do you want to start the clock?

00:07:20

Often they come back with, we want to start the clock at the point where we decided, yes, let's do this thing because that's going to give us a really good indicator and how we can w what's within our control, what we decided to do that we're going to fix. And we're calling that flow time. Flow time has actually been around for a really long time. I didn't make it up. I just started using it about four years ago because my tolerance for the arguments between the difference in cycle time and lead time grew very thin. And I was doing research and I found, you know, Little's law was proved out in the 1960s and they use flow time to identify, you know, if the point, when were it comes into the value stream and when it goes out. So start the clock where you want with flow time.

00:08:07

Um, but in my experience, it's, it's a very interesting measure from starting at when we've decided, yes, let's do this thing. And so flow time, I like to use scatterplots for flow time. There's other ways to do that, but this is showing every work item or artifact or story or epic, whatever term you're using for your work is identified and how long it took to do and the date that it was completed. So the horizontal access is the date that the work item was complete and the vertical access was how many days it took to do so in this chart, the legends on the right were identifying revenue, generating work with, uh, with a black dot. So this would be like your features and then identifying revenue protection work, that's sort of the circle. And the.in the middle revenue protection work would be a combination of your technical debt and your things like risks and security and compliance.

00:09:15

And then I've highlighted unplanned work here, because if you're tracking unplanned work, it's going to show up in your data. And then you can present this to people to explain why this feature that the purple arrow is pointing at was delivered a week later than the target date. If you're not tracking unplanned work, it's not going to show up in your metrics, not going to show up in your flow time. And then when the VP of whatever asks you, why there, you know, new platform is an up and running yet? What, what do you say? You say, well, you know, we've been really busy. Like if it's in, if it's not tracked, it's invisible and it's the perfect crime. If you can track it, you can start to help people see why work is taking longer than they think it ought to take what trying to be, what we're trying to improve.

00:10:14

I mean, wouldn't it be great if we could start to forecast and be more predictable, right? We're trying to be approximately right. Instead of exactly wrong. That's where it using flow time and probabilities for instead of just setting an arbitrary due date that people will March down toward, and then this might be a little bit, you know, next steps, but consider using percentiles. If you're interested in forecasting and probabilities, oftentimes we just look at the 50th percentile, which is what the average, but if you're just using averages, then you're going to be late or early, you know, half the time, if you select 85% tile, that means or not, this is an example of the 90th percentile. That means that nine times out of 10, we are going to deliver feature work within 20 days based on this data set of, of 30 days of one month. And when it comes to data sets, it only takes 11 samples to get to the 85th percentile and about 20 samples, they have to be random, but 20 random samples will get you to 90% probability of your work, uh, arriving on time. So I think this data is useful to convince others, maybe suffering from misconception, that things, uh, can be done sooner than they actually can be. Alright, thief conflicting priorities. So the problem here is teammates. Top priority is not team B's top priority.

00:11:59

Yeah. And so if you're, if there's all these projects happening all at the same time,

00:12:08

Because we can only do one thing at a time, I can walk and eat and maybe talk at the same time, but I'm not going to rearchitect our architecture and do some coding and closure and update Jamo files in Kubernetes, right. Are, you know, when it comes to complex work, we can only do one thing at a time. So if I'm heads down working on project a, that is a decision to not be working on project B cause the decision to do one thing is a decision to delay something else. Uh, and so with this, because there's so many competing priorities, uh, it's blocking flow and what measure we're going to look at flow the last city to see what are, how many things were getting done, flow velocity. It's like throughput, how many items, how many features or work items or stories, whatever you want to call them, did we get delivered? And I like to overlay it on top of flow time, because then you can start to see the impacts of one metric over the other, Right? If you can start to show how one metric is impacting another metric, that's extremely powerful. You can start asking questions, like did the N you know, did these emergencies that pop up that caused our features to be delivered late? Did that impact the number of features that we could deliver? Right. Is that why the number is that way? The flow velocity dropped

00:13:43

The next step is thief neglected work. So usually important nonfunctional requirements, uh, oftentimes things like technical debt or security items that don't get prioritized by product owners and business people. If they're focused on just delivering revenue, generating work like features by how many of you have some of this going on? Yeah. Like half the room. Uh, and so

00:14:20

Flow distribution is a metric that will help you with the problem of neglected work. Flow distribution is a way to look at your categories of work. So imagine your work. And you're able to sort of just tag each work item into one of these buckets, right? It's either some kind of revenue generation work like a feature, or it's a defect, or it's some kind of a risk, like a security breach or something, or it's technical or internal team improvements. Maybe there's a miscellaneous column, but the bulk of most of our work can fit into these four categories. And if you're measuring this, then you can start to understand what the trade-offs are and have conversations. This chart will help provoke necessary discussions on what our strategies should be like going forward. While we worked on a bunch of feature work and we got out a new release, but now we need to spend, we need to allocate more time to fix Defax or look at risks, or maybe we ought to fix technical debt. And if work is categorized like this, then you can start to visualize them when they're work in progress. So here's an example of doing that. It's a board that is showing the four different categories of work and a way to allocate capacity to ensure that it, you know, if your strategy says that we always want to have at least one risk work item in play, then we can allocate that in our work, in progress limits like this,

00:16:00

Right? This is showing that we had, we could have five, five features going on at any one time. You know, oftentimes you'll see work in progress limits at the top of each column, but there's no rule that says that you have to do that. You can allocate work in progress limits by work item type. Um, I've seen it where teams will always allow themselves to be, have one internal team improvement going on at any one time. So in this case, they'd allow themselves some green, some, uh, debt work there. And this helps, you know, it helps others see the conflicts of priorities across the org to,

00:16:44

Uh, this is an actual, um, look at the data, representative the data from a release that we did, where we were really focused on getting a new platform out, uh, so much so that some of our customers wanted to get ahold of it. And that sort of, you know, this went out before GA. And so what happened was then we had this buildup of defects that we weren't really expecting. And so we took a look at this and this is what allowed us to say, Hey, wait a minute. We need to work on some technical doubt and make sure we get these defects done. So it helps you have those kinds of conversations.

00:17:25

Next up is thief to miss work in progress. So this is when you know, the textbook textbook terms, uh, the demand is more than the team's capability to meet that demand. It's out of balance. Uh, is this, we're saying that teams are just drowning, they're overloaded. If you saw Christina masslynx talk yesterday on burnout. This was one of the contributing factors to burnout is overload where people are overwhelmed and that's what causes exhaustion. And when we talk about, well, this is all your work, all your unplanned work, all the post-its around your laptop, all the tickets in your ticketing system, all the interruptions, too much work in progress comes from too much. Yes. I'm going to do an ignite. Talk about that tonight, if you want to hear more about that, but the single most important factor that affects how long things take. Remember our friend things take too long is how loaded people are, how, uh, I mean, like loaded as an how much, what their workload is. Um, we call that flow load, uh, which I'll talk about on the next slide, but the most important thing for you to know about work in progress and flow load is that it's a leading indicator, just like when you get on the freeway and it looks like that it's like backed up to backed up, you know, your commute is going to take longer,

00:18:59

Right? Say if you've got way too much work, then the team has the capability to do things are going to take longer because people aren't available when you need them to be. And so for flow load.

00:19:13

Yeah.

00:19:16

Um, All that partially completed work, we're really interested in a lot of these metrics, including flow load on the trend over time, because it's going to go up and down depending on what your organization is doing, could, could, depending on if you're hiring or reorganizing your teams, but followed is, you know, one of the few leading indicators that encourage you to check out

00:19:46

A quote from Jim Barksdale, uh, about opinions. I, uh, I'll just have to say that I used, so my background, I was a build engineer. I spent a lot of time doing configuration management, uh, releases, you know, build and deployment automation. And the development always used to complain that things took too long. And I used to Chris take that personally and rant that builds don't take too long is because we don't have automated testing. And, but ranting got me nowhere. Absolutely nowhere. Once I could start presenting the data in a calm fashion in front of leadership, that's it just blew me away because I started, I got budget. I got head count, but probably more importantly, I got empathy on the role and what we were trying to do.

00:20:42

So thief, unknown dependencies. So software delivery roadmaps can appear pretty organized. If you look at them in this hierarchical view, like this, where their portfolio is at the top, and then that breaks down into projects. And then that work breaks down into individual team boards, but the details can get lost as workflows across all those different levels. Uh, especially when handoffs and unknown dependencies pop up. And this happens all across the organization. I was working with a sales ops team. These are the people who do, you know, solid statement of works and NDAs and terms and conditions and contracts. So salespeople can close deals. And I asked them, what is your work intake process? Like, like how do you get work? And they said, well, it comes via email. And I said, okay, then what do you do with it? And they said, well, we copy it.

00:21:38

And we put it in JIRA because that's our workflow tool. Okay, well then what happens? Well, then we actually put that information in the updates, in any attachments, back in an email, we send it back to sales because sales is working in Salesforce. They're not working in JIRA. And so information goes back and forth and back and forth and back and forth and emails and the data, you know, it's just, things get lost. And so it impacts their collaboration and their it delays, delivery. It interferes with delivery. So things take too long is a universal problem. Really, no matter what department or company a year end. And it's a problem that every company grumbles about, you know, and when it comes to all the different tools, we have more tools than ever before. So my first job out of school, I was doing builds on IBM mainframes.

00:22:33

I had to work with like four or five tools, just C and JCL and assembly language. And what else do they have COBOL? Now there's, XebiaLabs beautiful. Periodic table of DevOps tools has over 120 different tools on it. But this is what the dev ops community is saying. Allow teams to use the tool of their choice, because they should have the ability to use their best of breed tools to do the job the best way that they can do it. All right, let people use their tool choice to get the job done. So now, but the reality of the situation is that people are working with their team in their tool of choice. And each team is using a different tool and there's a lack of integration. So people have different views of the world. If I'm in service management, my view of the world might be in something like service.

00:23:30

Now, if I'm in quality management, my view of the world might be in quality center. If I'm in portfolio management, my view of the world is going to be in something like plan view. And if I'm in dev my view, the world might be in JIRA or, um, Azure dev ops. So, but there's only one view of the truth. And we constantly have to translate that in order to get our stories straight. And that's done through how manual handoffs spreadsheets T you know, bridge calls and team meetings. We all have a value stream, but how often is it actually designed or architected? Uh, the way we architect our products, I'm not too often. I often see tool fights breakout because developers want ops to use JIRA and ops wants developers to use service now and everybody's bickering about it. And so the just fabulous metric to use here is flow efficiency to bring some, uh, highlight, to expose this pain point.

00:24:43

So flow efficiency is a measure. It's a ratio, there's the calculus. There's the equation. It's work divided by work. Plus wait times a hundred percent. It's the ratio of how long work is sitting, waiting, compared to working, right. If you're going to measure anything, have a think about measuring wait time, how long work is sitting idle, because it's, most of the time, you know, here we are arguing about how many story points something should be and what a due date should be on something and what the estimate should be when the problem is the lack of flow that's going through the system and how things are just hanging out, waiting on people until they have availability. And we want to take a gas at the average flow efficiency for most large enterprises. How many think it's 10%

00:25:37

Or less? Yes. Yeah. So let's think about flow efficiency is that you're going to need to understand when work is in a work state and when work is in a wait state. So you're going to have to sort of find some way to flag that in your system. This is one way to do it. There's other ways to do it, but you know, how waiting states or, uh, in, so in here we've got, you know, investigate work and then investigate done. So the work and investigate Don is waiting until developers have capacity to pull that work in. So you have these queues set up and you can see how long the cues get.

00:26:22

So it's fairly easy to gain a metric. Uh, and we know we're human. We will get gain metrics because we're going to value. What's being how we're being measured. And you tell me how you're going to measure me, and I'll tell you how I'm going to behave. And if you're going to measure me in a logical fashion, then don't be surprised if I behave in an illogical manner. Um, you like gold rat, I think, uh, author that, uh, I'm going to save a few times for questions. So I'm just gonna kind of wrap this up with takeaways and benefits, uh, for you to keep in mind that with flow metrics, the goal really is to keep it, to tie it to the business value. So you can have good conversation with your senior leadership. If you go into your CFO's office and start talking about story points, you'd probably gonna get, like, I'd probably get kicked out of my CFO's office, but if you can go in and talk about how long things took or that we didn't get a feature done last month, or that big, our biggest customer expected it a week before they got it.

00:27:31

Those are useful conversations that will help drive improvement. Uh, flow metrics are based on outcomes, not output. So any metric that's measuring an activity is, is a, I mean, it's an activity metrics. Some might call that a, uh, not a proxy metric. What, uh, I'll think of it probably five minutes after this top vanity metric, right? I mean, it's, it's interesting the number of deployments that got done today, but what does the business do with that decision? How does it help them increase revenue or drive their business value? Okay. Uh, and then flow metrics. That's what we're really trying to do is provide this feedback loop, right? So we can help improve business decisions. So here's a review the metrics, uh, all five of these are detailed, quite nicely and Mitt Kirsten's book, project to product and flow load and flow time and flow efficiency are also in my book making work visible.

00:28:40

And I have flow low too, but we didn't call it flow load back then. So how do you get started with flow mat tracks? You gotta start somewhere. And the guidance here is just start capturing, you know, one artifact, one work item type, maybe it's features in one value stream, right. Uh, and one, just one flow metric. And because everybody's grumbles about time and how long things take flow time can be a good place to start. Um, but it all depends on your context. You know, maybe you want to start with flow distribution to make sure that teams have, are allocated capacity to do some technical debt work, final considerations. Uh it's you know, if you can have a nice balanced set of metrics that will help you have conversations about, you know, how far, how much should we optimize this metric? When is it good enough? You know, when should we start focusing on optimizing another metric to make sure they keep in balance? Now, what do we look for, uh, to see what the impact is on other metrics? And an improvement takes time Can take a lot of time sometimes. So how do we know? You know, what's your baseline? How do we know when we're starting to improve?

00:30:04

So

00:30:07

If you send me an email, that's it. That's my talk. If you send me an email to dominica@sendyourslides.com, I'll send you links to many of my past talks that have most of this information in it. And I linked to workshops that I do, and a bunch of other goodies excerpts of my book. Yes, I did bring more, no less whipped stickers with me today. If you want some, there there's a whole bunch at the Tasktop booth. So check that out. If you want to follow up on any of these, uh, conversations on flow metrics, I'm going to be hosting a link coffee this afternoon, uh, in Riverview, same place as yesterday. And they'll start at three 30 today. So thank you for your time and we'll see you soon.