00:00:05

Thank you everybody for being here. It's really great to see you all here today. So as Jean said, I'm Dominica DeGrandis and it's been my, my background. It was a build engineer. That's what I did. So I spent a lot of years doing configuration management and trying to make things visible for people to see, you know, what build was on what server and what environment it was in and where it was and when it was going to production and all of that, just making things visible. And for the last 10 years, that's what I've been doing is helping people make things visible. I help teams to see and how to measure the things that prevent them from getting work delivered. And then I help them design Kanban systems so that they can optimize their workflow. And today I want to talk about, uh, something very near and dear to my heart. And that is that we are people take on more work than they have capacity to do. And it's a big problem because they overload themselves and they overload their teams and that creates bottlenecks and constraints and it delays the delivery of business value. So that's what this talk's gonna be about. I want to talk about why, how that happens and what to do about it.

00:01:28

So three things really, why do we take on this overload? How do we unmask that overload? And then I'm going to show you some hopefully tactical examples, some compound designs that you can take back home that can be bring visibility to what's killing your team's capacity. Alrighty. So first off, why are we so overloaded? Why do we think we can finish work faster than we actually can? I think we tend to underestimate the number of distractions that sidetrack us from focusing on our work and finishing it on time. And we tend to say yes to requests when we should probably decline them or at least postpone them. And before you know it, it's two 30 on a Sunday afternoon and we're working on that thing. That's due Monday morning at 9:00 AM. So why do we overload ourselves to the point of making Sunday the new Monday?

00:02:25

Because when somebody asks us to do something, we say, yes, we say, yes, we take, we take on more work than we can complete in a timeframe. And just to clarify, there are sometimes burnout cultures that come, that play a role here. And I want to acknowledge that, but often we do this to ourselves often. It's us that say yes all the time. And so I want to argue that there's four reasons that we say as I think there's a few more on my research, but I'm just going to talk about for today. And the first one is nobody wants to be the person responsible for the team losing, right. We are team players and we pull one on we'd love to pull one on for the team. Number two is shiny new object syndrome, starting something new and shiny is much more enjoyable than doing the grunt work. It takes to finish something older and unglamorous it's like, gee, do I want to implement new microservices using Docker containers? Or do we want to, I mean, prepare for this security audit, right? Do we want to go have fine dining for dinner tonight with some prime rib and farm fresh vegetables? Or do you want to stay home and eat three day old tuna casserole?

00:03:52

Number three, everything always, always takes longer than we think it will. Especially other people's work. Number four is it's much easier to say yes to the boss or to people that we like than it is to say, no know as an executive consultant trainer, coach, I work with teams all the time for many years now. And people will, when I ask them this question, why do you take on more work than you have capacity to do? And they say, because the boss asked me, it's really hard to say no to the boss. So you bosses out there. Remember keep that in mind. So I think this is a call for a change in behavior, right? We need to train ourselves not to say yes all the time. We need to give us sort of self some, no cred. I think it's helpful to look at some of the practices that we find in the DevOps culture.

00:04:51

So here's just a few attributes here and you see these all the time. I'm not gonna go into detail. You know, we hear high cooperation and trust a lot, and that people should like their job and that, you know, information is flowing across silos and teams and people are aware and can anticipate what's headed their way. And that there's a climate for learning is considered an investment and not just an overhead or a cost, but all of these attributes at some level require respect for people, which is a main pillar of lean and many of the DevOps attributes stem from the lean movement, right? We've got continuous improvement. We've got systems thinking and value streams and creating value fast for the customer and flow. And so it's these lean attributes that embody the lean house. Um, I've got a lean boat house here because we're doing this deep dive thing.

00:05:49

And so I just want to call out that respect for people is a major pillar of lean and people use that term all the time, respect for people. I want to tell you my definition of that, which really for me, because people don't, I don't hear people defining that. And I think respect for people is all about giving honest feedback and it's, it takes a lot of courage to do that. It takes a lot of courage to tell people why they may not have gotten that promotion or that merit review or, or you know, why there was a problem and how to deal with some of the problems. And it's the respect for people that provide the leadership, you know, basis, the foundation for people to have that safety, to be honest. And that's what enables the continuous improvement, which in turn helps improve customer value. It's just one big ecosystem. And then, and then flow flow is a major pillar. So in continuous a does theme here, I just want you to pay attention to the little yellow submarine. That's going to be a visual cue cause we're about being visual, visual key on some slides for you to pay special attention to some extra good learning tips.

00:07:05

All right. So real quickly, what is flow just smooth and fast movement of all the activities that it takes from all that the work goes through from the beginning, all the way to the end, including delivery, including maintenance in production, right? It's not done when it's delivered. There's still some maintenance that needs to be done and some support. And that the biggest determinant determent to that flow is too much work in progress, too much whip. So there are three other, you know, there's, there's three things that come into play with improving flow. The first one is making work visible, and then we've got batch size, reducing the batch size of things and then trying to build quality. And, but this talk, I'm just focusing on that first bit, making work visible. So why is flow the biggest deterrent cover that real quickly because it scatters your brain across multiple things and you have interruptions and context switching and you get out of the zone.

00:08:10

Like it's like when you're in flow, you're in the zone, you're focused, nothing's interrupting you. And it's amazing the amount of work that you can get done too much, which sabotages our ability to deliver work on time. I worked with an ops team once in LA 41 engineers. So CIS admins, network engineers DBHs, they were building out six data centers all at the same time, they were supporting 33 revenue generating projects on the business side and they were still carrying the duty pager. So they're, they're just, they're trying to get all this work done. They're not getting a lot of sleep and, and things are slipping through the cracks and they're starting to use, lose respect from other teams. Um, people are, you know, oh, ops what a bunch of losers. They don't do what they say they're going to do. Their reputation really went down the drain.

00:09:05

It was sad to watch. So we, I have, I have a talk, a whole talk on that, um, how we got out of that rat hole and came back. But the point was that when we start to work faster, when we take on new work, faster than we can finish the older work, we're going to get more work in progress. And, you know, queuing theory comes into play. So for you, for those of you interested in math, and you want to learn more about queuing theory and what that is, there's Kingman's formula for you that basically shows the relationship that whip and flow have. And the more whip you have, the, you know, the longer things take the wait time increases dramatically as utilization approaches a hundred percent. You know, we don't let our servers get to a hundred percent capacity utilization. Let's stop doing that to ourselves too.

00:10:03

All right. So whip, you know, it's a primary factor of flow. The amount of work in progress we have. It's what, w it's really what makes whip a leading indicator. A lot of the metrics we have our trailing indicators. You look at cycle time, lead time, throughput, velocity, those are all trailing indicators. You don't know how much you had or how long it took until after it was finished. If you're looking at work in progress as a metric, you know, from the onset, if something's going to take longer, if you're in an airplane and you're getting ready to take off, and there's 10 airplanes queued up in front of you, you know, it's going to take longer before your airplane takes off. Same thing with boats and a canal going with the boat. Same here. Okay. So now that we know why people take on more work than they have capacity to do, and that we know that whip is the biggest deterrent to flow, um, to our too much whip.

00:11:01

Let's talk about what to do about that. Um, so making work visible, just the art of making, putting your workup in a visual space immediately, it gives people something to view the, I can take it in and they can see what's happening here. This is just a very elementary example to introduce this. There are many, many different ways to design combine boards. I'm going to show you just a few here today. They won't all be the same, how you design your system, depends on your context and in what problems you're trying to shine a light on and what you're trying to accomplish. So this design, you know, we've got the states that the work moves through prep work, implement work review, done. That's a fairly simple generic kind of workflow. Often we just see planned work on the board, but more often than not, a lot of teams have unplanned work. So this is a view that's just bringing visibility to unplanned work, to show that, you know, partially completed work can be very expensive. So make it visible. And hopefully it'll provoke some conversations about how to speed it up.

00:12:16

Here's the flow that we're just, we're trying to bring visibility to where things get stuck, where a things stuck here validate, right? When, when you make work visible, you can start to see the problems. You know, this one's a little bit obvious, but then this is a real example here. There's this is the team of 41 engineers who had a hundred things stuck in their validate queue. And when you see things pile up like this, it should start a conversation about what to do about it. How can we avoid work, getting stuck and validate, uh, if you, by the way, if you don't have this capability yet, then just start out by querying your ticketing system or your workflow system, whatever you use and just query everything that hasn't moved or had been touched in over 30 days. It's probably a pretty interesting list. Some of you may need to go 60 or 90 days, and then you put your work up on the board and then you can stand back and ask this question, you know, why is this expensive piece of business value stock?

00:13:23

And then you can consider what's the cost of the delay of that value being stuck. And that should, you know, help get some things moving. I'm going to argue that your expensive piece of business value is stuck or isn't it moving because it's competing with one or more of the following obstacles. Number one is unplanned work, two conflicting priorities, three dependencies. I see these as some of the biggest impediments to getting work flowing again. So let's look at those unplanned work. Let me define that unplanned work. I'm defining that as the interruptions of the day, many of them are emergencies or incidents, productions down. You know, what happened to the NFS mounts? Where did they go? Um, you know, people interrupting you in your, in your queue. These are things that never go in the backlog. These are born in doing, they just appear in doing, and it's why you can't get to your to-do list until 6:00 PM at night, sometimes, right? It cuts the interruptions in the context, switching cut into the business value or the customer value or whatever kind of value that it is. You're trying to deliver. That's going to generate revenue or protect revenue in some way.

00:14:45

And so I also want to be clear that I'm not saying that we can bring unplanned work down to zero. That would be delusional. We're always going to have unplanned work. So let's just plan for unplanned work because of all the uncertainty planned for it. So you can put yourself in a position so that it doesn't kill you. And one way you can do that is I'm gonna talk about just, you know, maintenance, keeping a regular cadence of maintenance is super helpful for reducing unplanned work. So pull a maintenance card or two, if you have a work card type, a maintenance, uh, pull some of those into your, um, on your board every now. So you always have one or two that you can be working on.

00:15:32

So here's a board how to unmask unplanned work. And we got a call, a swim lane for maintenance work. So we can always have some maintenance work and play. It's also got an unplanned work row up on top there, and it's bringing visibility to unplanned work. Like it never goes to to-do, it's just always shows up and doing, and these are flowing through the system and interrupting the planned work. Um, usually there's some resistance to this, and it's usually in the form of somebody like platform ops manager, Eric, who will say, I don't have time to create a card or a ticket. Every time I get interrupted, like not doing that. And then, you know, after weeks of interruptions, the CIO wants to know why usher isn't up and running yet in production. And what is Eric say? Eric says I've been busy, but there's no evidence. It's like a perfect crime.

00:16:38

So, you know, I'm not suggesting that you do this forever, but if in your context, unplanned work is a problem and it's invisible. Then maybe bring some visibility to it for, you know, experiment with it for a couple of weeks and see how much unplanned work you have. If you can bring visibility to unplanned work, then you can show it to people and explain, this is why I wasn't getting that other stuff that you wanted done on time, because all these emergencies popped up. So next step conflicting priorities, competing requests is a major culprit of too much work in progress or too much overload. You know, when you hear my project is more important than that project, you know, there's a problem there, or that priorities are unclear. So, uh, you know, 33 projects all happening at the same time. That's, that can be a problem because it competes for the same people's time and the same resources you're competing with all those other projects and resources.

00:17:44

It blocks flow, it slows flow down and increases partially completed word. Everything cannot be a top priority. We can have a lot of priorities, but there can only be one top priority. And that's where prioritization policies come into place and need to be really clear. So let's me just show you one example of that. This is a, an accounting team, you know, the finance teams. I hope that some of you can go befriend the finance team because they are probably one of the last remaining holdouts being lean and trying to get on board with flow and dev ops. But they have end of the month, you know, they have the regular cadence work. They have end of the month invoicing that needs to occur. So sales teams can meet their monthly quotas. They have, they have to get expense reports out so people can get reimbursed.

00:18:38

It just, and that competes with other work that they have to do, like customer account upgrade requests. So, you know, they have, they're juggling a bunch of work too, just like we are an ops. So for cadence driven work here, um, you know, whether it's end of the month invoicing or a quarterly business reviews or annual security issues recognize that those have to be prioritized over other work. And so some of that other work is going to be delayed. And to have that conversation, you can have a board like this, that showing all the different kinds of work that you have, right? And the cadence work there, that's that second row, we've got these things and they have a hard due date. This work has to be done on the 30th or payroll won't happen. So put some, make them big, make them bold, put some dates on and make them very visible and show them there, along with all the other work that's going on, you know, we, we still have expedites or unplanned work that's happening.

00:19:35

There's still business requests, feature requests, um, you know, revenue generating work. That's got to get done that we promise customers to do. So we need to get that done. And what about all the internal team improvements we're trying to make? And the automation we're trying to do. So if you look at everything in the doing column there, and you know, now, instead of sort of people arguing face to face about what to do, you can look at some data and see what's competing with each other and then have a conversation and say, look that red X on that great ticket on the bottom there, isn't, isn't getting done because we have this cadence work we're doing, and we have an emergency when you can, when you can see the work like this, when you unmask it, you can start to have the conversations that need to be had about how are we going to prioritize.

00:20:26

So the main point here is fit. You know, what be really clear on what your prioritization policy is? Is it really just whoever gets paid the most or talks the loudest or cost of delay or whatever that is help people understand. Number three, dependencies affect just about everybody. I'm going to give it a marketing example here, because I was working with the marketing team a while ago. So the marketing team, editorial director waits on an author to write a blog so they can do the copy editing. And then the social media director waits on the editorial director in order to promote the post. And then the data analyst waits on the post to go out. So she can do the social media part about it. The reality is that we work in webs dependencies, if not on people than on architecture. And it's just hard to do.

00:21:22

This is one of the hardest things we do, I think is dependencies. And so just to demonstrate how dependencies create a whip overload, let's imagine you go out to dinner to a fine dining restaurant. You must think I like fine dining restaurants. Really. I do enjoy just seating at home. Um, but it's the fine dining where they don't see you until you all arrive on time. And so say three people are going to you, your friend and your brother, and you all work at different places. So you're all getting there independently. You're not arriving together. You're meeting at the restaurant. There are eight possible outcomes of arriving at a certain time, right? Either you're on time and your friend and the brother are late or your late and the friend's on time and the brother's late, or you and your friend are late. And the brother's on time.

00:22:11

You get the idea there's eight possible outcomes. And only one of those is going to guarantee that you're going to be seated on time for dinner. Cause dependencies are asymmetrical in their impact. It's not a 33% probability that you're going to arrive on time, or it's an 87% that you're not going to arrive on time. And every, you know, because it's seven, seven out of the eight times, it's much more likely that one of those seven is going to happen than the eight. So it's much more likely that you're going to be late. And every dependency doubles the chance of being late. So what to do about it? This is one example. We have many, but this is between two teams because oftentimes the dependencies between two teams is what gets really hard in three teams and fourteens and a hundred teams and portfolio level across boards.

00:23:05

But here just showing a card on team dev board and two child cards on team ops board. So we're trying to bring visibility to these dependencies and we're using whatever method we can. Orange cards here mean dependencies. We've got headers in the top. So this is a task a or project a or feature a, and it's got two kids and they live on another board. And so we've got one of two and two up two on the other board. And if you open those cards up, there's links that take you to the other cards and communication and comments. And you can see all the dependencies that are in there and you can do this at many different levels, but it's very expensive when teams are mutually unaware of critical information. So trying to bring some sense of visibility to dependencies is helpful. And just to give downstream teams a heads up, all right, next step.

00:24:04

So in order to get more out of Kanban flow, there's two practices that are essential. One is bring visibility to the work and two is limit work in progress. So limiting WIP happens by setting the amount of work that you think the team can handle. At one time, the team comes up with that decision and actually, um, whip is WIP limits, intentionally insert tension into the system. They are what put the constraints in the system because it's what gives people permission to say, no, if your whip limit is 10 and you're at 10, and somebody asks you to do something, this is what gets, this is the honesty that the, the truth, the trust that says, you know, we're full right now. Uh, you know, sorry that, you know, that's going to have to wait unless your prioritization policy kicks in, which says, if production's down, then drop everything else and go work on this production issue.

00:25:12

But think of a WIP limit as a friendly constraint. It's like, if you went to, um, I got a food thing going on. If you went to a food buffet, like you can't eat everything out, the food buffet, like they only, they give you a plate, a certain size, that's a constraint. You can only fit so much food on the plate. My youngest son is really creative with this. And he finds a way that he like puts the French fries out off the plate edges. So all the food piles on, so you can get creative. I mean, the WIP limits, you know, it's not that you went to ever break them, you know, but if you're not using WIP limits, you're at a disadvantage because it's prevents blocking flow. So start limiting your whip. So this team that had over a hundred things in Dalla date, I mean, first of all, there's many, many different ways to set WIP limits.

00:26:05

This is one, you see this a lot with LWWIP limits at the top of the column and people ask, well, how are we supposed to do that? What should our whip limit be? I'm just going to tell you my favorite way, which is probably very different from many of the other lean coaches and what they say for how to women lip, how to limit whip. Um, my favorite way is to accurately reflect how much work is there and put that number on the board. You got a hundred things and validate, let's put a hundred there and then stand back and look at it and ask the question. Does this make sense? Does it make sense to have a hundred things on the board and validate? No, that doesn't make sense. Okay. So let's lower it. How much lower it should it be at this point? It doesn't really matter. I mean, 80 is better than 98. And then you work with that for a little bit and ask the question again, you know, your, your volume comes down to 80. Does that make sense? Probably not. Lower it again. Keep Loring your WEP, uh, gradually over time until you can find some smooth flow through your system. And then, you know, that's about right, but maybe new people join the team, or maybe there's some attrition, WIP limits are meant to be adjusted. They're not permanent.

00:27:25

Okay. There's no rule that says you have to have whip at the top. You can have WIP limits on rows like this here. We've got a whip of one silver bullet. I was going to explain that, but I'm kind of running low on time. So come afterwards to the ask the speaker, if you want to hear about silver bullets, we've got three items and team improvements, and we got a WIP limit of five and business requests, and we've gone over that. There's eight things. So now you have this conversation, you know, that's money flowing through there on its way to being delivered. So which one is the most valuable and what, what, when do we need to drop right now?

00:28:05

Keep in mind that partially completed work results and unmet business goals. Okay. And one way to be more predictable to meet those business goals is, you know, limit your web. Maybe, you know, 80% of capacity is a nice general rule of thumb. And then to sum up just in order to reduce the overload, think about using a pull system or a real pull system like Kanban that has WIP limits has a constraint in there, gives the team permission to say, sorry, we're full. Can't take that on right now. That would overload us. Um, and so that you can do something about it. Um, so I hope I've provided you with some tactical ways to limit your work and make things visible. Um, basically, you know, lose the mask.

00:28:52

There's still a problem here though. People, people are taken on more work than they have capacity to do. So the leaders in the audience please consider your positional power that you have over your teams when you ask people to do things because they want to say yes, and more likely they will say yes, even if it overloads them and overloads their teams and prevents you from your ultimate goal of delivering business value. So thanks so much. If you want a copy of this presentation, just send me an email dominica@leankit.com put flow in the subject, and I'll send you this presentation along with some other goodies, along with updates on my upcoming book, making work visible. Thank you.