Making Work Visible: How to Unmask Capacity Killing WIP

Are you scrambling to meet deadlines only to find more requests piling up in your inbox? Hidden WIP is a major contributor to clogged value streams and overloaded employees, burdened with too many meetings and frustrating work routines. Making work visible highlights the problems leading to low productivity across the organization.

In this talk, Dominica shares how to unmask the things that are killing your team’s capacity and their ability to optimize workflow.


Dominica DeGrandis

Director, Learning & Development, Leankit



Thank you everybody for being here. It's really great to see you all here today. Uh, so as Jean said, I'm Dominica DeGrandis, and it's been my, um, it was 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 gonna 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. Um, 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 wanna 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. Uh, so that's what this talk's gonna be about. I wanna talk about why, how that happens and what to do about it.


So three things really. Uh, why do we take on this overload? How do we unmask that overload? And then I'm gonna show you some hopefully tactical examples, some combine 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? Uh, 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?


Because when somebody asks us to do something, we say yes. We say yes. We take, we, 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 wanna acknowledge that. But often we do this to ourselves. Often it's us that say yes all the time. And so I wanna argue that there's four reasons that we say yes. I think there's a few more based on my research, but I'm just gonna talk about four 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 wanna implement new micro services using docker containers? Or do we wanna, i, I mean, prepare for this security audit, right? Do we wanna go have fine dining for dinner tonight with some prime rib and farm fresh vegetables? Or do we wanna stay home and eat three day old tuna casserole?


Number three, everything always, always takes longer than we think it will, especially other people's work. <laugh>,




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. Uh, you know, as an executive consultant trainer coach, I, 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, you know, it's really hard to say no to the boss. So you bosses out there, remember, keep that in mind. Uh, 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 ourselves some no cred. I think it's helpful to look at some of the practices that we find in the DevOps culture. 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, 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, the 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 boathouse here because we're doing this deep dive thing. Uh, and so I just wanna call out that respect for people is a major pillar of lean.


And people use that term all the time. Respect for people. I wanna tell you my definition of that, which really for me, 'cause people don't, I don't hear people defining that. And I think respect for people is all about giving honest feedback. And it just 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, uh, have that safety, to be honest. And that's what con enables the continuous improvement, which in turn helps improve customer value. It's just one big ecosystem. Um, and then, and then flow. Flow is a major pillar. So in continu with the does theme here, I just want you to pay attention to the little yellow submarine that's gonna be a visual cue. 'cause we're about being visual, visual cue on some slides for you to pay special attention to some extra good learning tips.


All right, so, uh, real quickly, what is flow? Just smooth and fast movement of all the activities that it takes from all the, 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, determinant to that flow is too much work in progress. Too much whip. Uh, so there are three other, you know, there's, there's three things that come into play with improving flow. And the first one is make broker visible. And then we've got batch size, reducing the batch size of things and then trying to build quality in. But this talk, I'm just focusing on that first bit, making work visible. So why is flow the biggest deterrent? Let's 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, right?


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 whip sabotages our ability to deliver work on time. I worked with an ops team once in LA 41 engineers. So cis admins, network engineers, DBAs, 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. Uh, they're not getting a lot of sleep and, and things are slipping through the cracks. And they're starting to use respect, lose respect from other teams. Um, people are, you know, well ops, what a bunch of losers. They don't do what they say they're gonna do. Their reputation really went down the drain.


It was, um, sad to watch. So we, I, I have a, I have a talk whole talk on that, um, how we got out of that rat hole and came back. But the, 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 gonna get more work in progress. And, you know, queuing theory comes into play. So for you, for those of you interested in math, then you wanna 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.


Alright, so whip, you know, it's a primary factor flow. The amount of work in progress we have, it's what, uh, it's really what makes WIP a leading indicator. A lot of the metrics we have are 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 gonna 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 gonna take longer before your airplane takes off. Same thing with boats and a canal going with the boat theme 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, or too much whip, let's talk about what to do about that.


Um, so making work visible, just the art of making, putting your work up in a visual space immediately gives people something to view. The eye 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 Kanban boards. Um, I'm gonna show you just a few here today. They won't all be the same. How you design your system depends on your context and 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. Here's the flow that we're just, we're trying to bring visibility to where things get stuck. Where are 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 the 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 been touched in over 30 days. It's probably a pretty interesting list. Some of you may need to go 60 or 90 days


<laugh>. Yeah.


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 stuck? And then you can consider what's the cost of the delay of that value being stuck? And that should, you know, help get, uh, some things moving. I'm gonna 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. Uh, many of them are emergencies or incidents, productions down. You know, what happened to the NFS mounts? Where did they go? Um, 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 and 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 gonna generate revenue or protect revenue in some way. And so I also wanna be clear that I'm not saying that we can bring unplanned work down to zero. Uh, that would be delusional. We're always gonna have unplanned work. So let's just plan for unplanned work because of all the uncertainty plan for it so you can put yourself in a position so that it doesn't kill you. And one way you can do that, you know, is I'm gonna talk about just, you know, maintenance. Keeping a regular cadence of maintenance is super helpful for, uh, 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. So here's a board how to unmask unplanned work. And we got a column, uh, swim lane for maintenance work so we can always have some maintenance work in 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 in 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 Azure isn't up and running yet in production. And what does Eric say? Eric says, I've been busy, but there's no evidence. It's like a perfect crime, <laugh>.


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 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. 'cause 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. <laugh>, 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, um, projects and resources.


It blocks flow, it slows flow down and it increases partially completed work. 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, uh, 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 of being lean and trying to get on board with flow and DevOps. But they have end of the month, you know, they have regular cadence work, they have end of the month invoicing that needs to occur. So sales teams can, uh, meet their monthly quotas. They have, they have to get expense reports out so people can get reimbursed.


Uh, 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 in ops. So for cadence driven work here, um, you know, whether it's end of the month invoicing or 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 gonna be delayed and to have that conversation, you can have a board like this that's 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, you know, 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 'em 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. There's still business requests, feature requests, um, you know, revenue generating work that's gotta 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, um, 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 gray 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 gonna prioritize.


So the main point here is, 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, or whatever that is, help people understand. Number three, dependencies, which effect just about everybody. Uh, I'm gonna give it a marketing example here 'cause I was working with a marketing team a while ago. Uh, so the marketing team, editorial director waits on an author to write a blog so they can do the copy editing, right? And then the social media director waits on the editorial director in order to, you know, 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. Uh, the reality is that we work in webs of dependencies, uh, if not on people then on architecture.


And it's just hard to do. 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 sitting at home. Um, but it's the fine dining where they don't seat you until you all arrive on time. And so say three people are going, 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 you're 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.


You get the idea. There's eight possible outcomes and only one of those is gonna guarantee that you're gonna be seated on time for dinner. 'cause dependencies are asymmetrical in their impact. It's not a 33% probability that you're gonna arrive on time or it that it's an 87% that you're not gonna 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 gonna happen than the eight. So it's much more likely that you're gonna 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. 'cause oftentimes the dependencies between two teams is what gets really hard and three teams and four teams and a hundred teams and portfolio level across boards. 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, 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 of two on the other board. And if you open those cards up, you, 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. So in order to, you know, 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 what happens by, you know, setting the amount of work that you think the team can handle at one time, and the team comes up with that decision actually. Um, WIP is WIP limits intentionally insert tension into the system. They are what put the constraints in the system. Um, because it's what gives people permission to say no, if your WIP limit is 10 and you're at 10 and somebody asks you to do something, this is what gives, this is the, the honesty, the, the, the truth, the trust that says, you know, we're full right now. Uh, <laugh>, you know, sorry, that, you know, that's gonna have to wait unless your prioritization policy kicks in, which says if production's down, then drop everything else and go work on this, uh, production issue.


But think of a whip 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 at 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 to, 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 whip limits, you know, it's not that you wouldn't ever um, break them, you know, but if you're not using whip limits, you're at a disadvantage because it's, it's blocking flow. So start limiting your wip. So this team that had over a hundred things invalidate, I mean first of all, there's many, many different ways to set WIP limits.


This is one, you see this a lot with whip limits at the top of the column. And people ask, well how are we supposed to do that? What should our WIP limit be? I'm just gonna tell you my favorite way, which is probably very different from many of the other lean coaches and what they say for how to limit 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 in 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 lowering your whip, 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. Whip limits are meant to be adjusted. They're not permanent,


Okay? There's no rule that says you have to have whip at the top. You can have whip limits on rows like this. Here we've got a whip of one silver bullet. I was gonna explain that, but I'm kind of running low on time. So come afterwards to ask the speaker if you wanna hear about silver bullets. We've got three items in team improvements and we got a whip 'em at a five in 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, and what do, what one do we need to drop right now? Keep in mind that partially completed work results in unmet business goals, okay? And one way to be more predictable to meet those business goals is, you know, limit your whip. 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. A real pull system like Kanban that has whip 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.


There's, uh, still a problem here though. People, <laugh> people are taking 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 wanna 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 wanna copy of this presentation, just send me an email, uh,, put flow in the subject and I'll send you this presentation along with some other goodies, uh, along with updates on my upcoming book making work visible. Thank you.