Visual Flow: A Guided, Virtual Tour Through Interactive Exercises to Expose Neglected WIP & Dependencies

Neglected work often plants invisible technical debt in the system, knowing that short-term thinking sways prioritization in favor of new revenue generating features over protecting valuable assets. Adding in dependencies on highly utilized experts exacerbates the invisible problems.

This guided tour takes you through virtual exercises where teams can discover how to deal with the brutal combination of important neglected work and cross team dependencies.


Dominica DeGrandis

Principal Flow Advisor, Tasktop



Hello, my name is Dominica DeGrandis, and I'm Principal Flow Advisor at Task Top. This session comes in response to many people who are curious about how to handle too much work in progress, how to handle the whip that they're dealing with, in particular, neglected work. It's usually important work, but it's still neglected all the same, often due to the heart of much neglected work. And that's dependencies on highly utilized experts given the work from home policies, I've been facilitating lots of work virtual workshops over the last few months, and this presentation is a guided tour to take you through some of the virtual exercises I do to help teams discover in this session, discover how to deal with the brutal combination of important but neglected work and cross team dependencies.


I'm gonna share my screen out here. All right. And so consider partially completed bridge. It's already expensive, but vehicles can't use it. There's no value in this bridge until it's delivered, until it's finished. And so good time management means spending time on important things, not just urgent things. Making time to work on fire prevention helps you reduce the amount of time you spend putting out fires. Uh, so in neglected work, this, this time thief here, it's trolled by non-functional requirements work, what I like to call revenue protection work. It falls victim to thief neglected work because it gets overpowered by the promise of revenue generation. Business folks are often unaware what it's, what's involved to keep a system secure, reliable, and functioning. And so revenue, revenue generating work is top of mind for business people, but maybe not so much the long-term health of the platform and the infrastructure. And as a result, revenue protection work takes a backseat until something blows up, like a DDoS attack, right? A dis distributed denial service or maybe a correct database that brings down credit card fulfillment. Now, neglected work has morphed into an emergency. It now becomes unplanned work. It becomes a fire and puts teams in firefighting mode. And because this is such a common problem, it's become a theme, uh, in, in, in some very famous books based on it, uh, transformation, uh, such as the Unicorn Project and the Unicorn Project.


One of my, um, favorite parts about the Unicorn Project is the emphasis on improving daily work. It's actually, uh, emphasizes one of the five ideals. You know, Dan Pink talks a lot about motivation from autonomy, mastery, and purpose and mastery is fantastic, but when we're just learning something, you know, some days it would be an improvement. It'd be an advancement if we could just become more familiar with something, even if we could just be mediocre at something instead of being lousy at it. Having time to make improvements for learning and training and improvements increases happiness. There's many studies that show that from the state of DevOps reports to HBR articles. It shows that happy teams perform better. And allocating time for teams to make daily improvements is, is helpful. In this, I like to call this, uh, uh, this kind of work debt work.


There are, here's some examples of debt work. Debt work. It's defined. It's an investment in future delivery, right? It's an, it's, and it's not just technical debt. Technical debt is part of it, but it's an investment in people, in process, in tools, in the, in the culture, whatever we're doing that's gonna help us in the long term, not just the short term, right? Hence why this list includes training. It includes spending time doing internal team improvements in addition to refactoring code. So a bit of a spoiler alert here, uh, with the five ideals from the unicorn project note, the third ideal, it's the emphasis is on improvement of daily work. Allocating time to fix this debt work, uh, to help, to give people an opportunity to make improvements doing during work. Also note the second ideal, which is on flow, right? Focus on flow of enjoy.


Um, important, important. Now, when you have a focus on flow, it's useful to, um, categorize your work so that you can see the amount of work that you're able to spend improving, you know, doing that debt work, making investments in future improvements. So here we got a focus of four category types, features. This is the revenue generation type of work. And features is just a word that encompasses anything really that has to do with delivering business value, whether it's epics or stories or capabilities, uh, or features. Uh, this is business value that's flowing through the value stream. Defects and orange there, these are bugs issues, whether they're production or pre-production, uh, problems, uh, that you can consider this as like failure, demand. And then risks. Here we're talking about major risks to the business, not the situation where a project is at risk at being late, but risks such as security breaches or security vulnerabilities that could lead to a breach.


Security compliance. Things like government, government mandates such as GDPR or, or taxes, major business risks. And then we have debt in green. Uh, again, these are the investments and future delivery capability, whether that's tech debt, whether that's in your tools, culture or process improvement. And because revenue, uh, protection work like debts doesn't always get prioritized easily. When we, if we can categorize our work like this, then we can start to see what the real priorities are. Uh, when I worked at Corvus, I started out as a build engineer, and I did a lot of configuration management and builds and source code, uh, uh, configuration of branching strategies and whatnot, and ended up managing a, a build and release team. And at the time, we were doing these really big quarterly and every six months releases, the type where it takes the whole weekend, and you just pray that the website is up and running by the time the east coast comes online Monday morning, and because they were such big releases, there'd be an issue, but we never rolled back. We just rolled forward. And that meant implementing hot fixes in production. So we'd have bandaids in production, but at least things were up and running. And we'd say, okay, we'll fix those later. Well, later often never came because it was hard to get that kind of debt work prioritized. And then the next thing you knew, we'd be doing another release in three months, and now we've gotta do a hot fix for the hot fix because we never had time to fix the debt work that was involved, uh, with the original hot fix.


So if you can categorize work in this way, then you can start to, um, have conversations and influence prioritization, right? You can start to make the trade-offs clear. What's the priority? This, it just leads directly into, you know, these conflicting priorities.


Um, oh, here I wanted to show this. And so, when you look at your work in progress, if you categorize your work in such a way, you can start to tackle thief conflicting priorities up here in blue by, by discussing having a conversation about what is the strategy? Or is this month or this quarter do, are we getting out a new feature? Do we really need to focus more of our capacity on feature work? Or do we have a lot of bugs to fix? This way you can set work in progress limits for the different types of work that you're doing. And if you need to allocate capacity to do debt, then you can do that here on this, where we're seeing that there's, this team can have three debt items in play and quite valuable, um, to show the different kinds of work in progress by work type distribution. Because if a team has capacity to work on X amount of work, and the situation is prioritizing fixing, uh, debt and risk, then that means that feature and defect work should be reduced, right? There's only so much that you can do. And if priorities are such that feature work keeps getting prioritized, then debt work's gonna be neglected. And this is one thing that business and IT leadership really need to understand what are the trade-offs that are occurring? Because we're making decisions on the type of work we're doing.


I included unplanned work here, because if neglected work continues to be neglected for a long time, it morphs into becoming an emergency. It, if you don't prepare for, you know, you gotta change the oil in your car every so often, otherwise the engine is very unhappy. And with unplanned work, unplanned work, it delays planned work, right? It steals your predictability. Uh, and so it's useful and interesting to look at neglected work. They're like close cousins, neglected work in unplanned work or close cousins. Uh, so then let's do an exercise. And the exercise over here is, is called flow distribution, distribution, trade-offs. And the purpose of it is we're trying to bring visibility to the trade offs of the neglected work, right? We're trying to, which is often debt. Debt usually falls in that category of, uh, neglected work. And the, and the goal is really how do we enable more time to make these daily improvements that gene talks about in the unicorn project?


So what we might take 20 to 30 minutes to do this, and the first step here in the instructions is just list out the common neglected work that your team has to deal with. And so people will spend some time identifying what their neglected work here in this. Um, with this training, we could see that cross training was neglected, professional development was neglected, vulnerability management was neglected, as well as upgrades and, and alerts. And then on the right hand side, we can see what turned into an expedite or, or more of an emergency that they have to stop everything else to deal with, including help desk tickets, which would be reasonable for this. This group doing this exercise included a lot of people from traditional IT teams with, uh, help desk and network engineers, CIS admins, DBAs, that kind of, those, those kinds of roles.


And so after a discussion on the neglected work and the unplanned work, then I asked them to sketch out what their flow distribution looks like. And there's a, there's a sketch feature in, um, in, this is mural by the way. And so I just ask them to, what would your flow distribution look like, uh, approximately what's the ratio? And I asked them to do this, uh, for the month of May, which, um, that's supposed to be for the month of May <laugh>. So blue, here's features, oranges, debt risks are yellow, red is defects, risk is yellow, and purple is debt. You can see that there's just this tiny sliver of debt work that was completed. And I'll ask them to put in percentages here for, uh, what they see as their work. If they capture this data in their tool set, then they'll copy that in and paste that so we can have a conversation about it afterwards.


So this gets the wheel spinning on what can we do in our organization to enable more time to, to do this important neglected work before it morphs into an emergency, before unplanned work gets its hands on it. So then we'll come back this, um, usually these sessions that I do, these work, virtual workshops are for any, you know, lately it's been between 30 and 60 people. And we'll have a, um, all present some fundamental basics on flow and, and too much whip and time thieves. And then we will break out into smaller groups to do these exercises. And then after each exercise, we'll come back into the larger zoom or the larger teams, um, session and talk about our outcomes. So there'll be spokespeople in each breakout room. I'll usually share my screen out, and then people can speak to their outcomes, their findings that they do. And so then we'll have a discussion on what to, what to do about it.


Uh, and so, um, I'm just doing a quick time check here. Okay? Um, and then we're gonna move into dependencies. Let's talk about dependencies. Let, so it's just, it's impractical for lots of people working on lots of different projects to be aware of every decision that impacts them. I worked at a, I worked at a really large retail once, and they had this concept of an away story. And an away story was where you, you had to go away to a different agile team to get your job, to get the information you needed to complete your task to get your job done. And there were, most of the stories were away stories because they had so many different small agile teams that had lots of dependencies upon each other. It seems really work in isolation. The larger the organization, the more teams, the higher the probability that there's dependencies, invisible dependencies, or unknown dependencies. And when that's a situation, it becomes very hard to communicate across teams. And a lot of communication ends up happening in email or in Slack channels. You know, it's not captured in the, in the tool set, uh, very well. And so then it gets lost and it becomes invisible.


Uh, so dependencies tend to affect almost everyone. The, um, it's not just it, right? We see this on the business side too. The, the marketing editorial director waits on the, um, the, the social media director waits on the editorial director to, in order to promote a byline or a blog post, and then the data analyst waits on the social media director to post the byline. So then she can look at the trends and collect metrics. Uh, the reality is, is that we work in this web of inter dependencies, if, if not on people, than on architecture, uh, or events. And when it comes to dependencies, there, dependencies are asymmetrical in their nature. And so every dependency ha, uh, the probability is 50% that it's gonna double your chance of starting late or, or being delayed finishing something late. Every dependency doubles the probability of starting late or finishing late.


And if you've got three dependencies, then it's not a 33% probability that something's gonna be late, because if you have three dependencies, there's eight ways that you can have those three dependencies. There's actually just a one in eight chance of on-time delivery. And if it goes up to four dependencies, then it's just a one in 16 chance because people, specialists, experts aren't available, uh, when needed. And let me define dependencies here. Um, I see, and in my book I talk about this, that there's three types of dependencies. And with dependencies, we're looking at, um, technol, you know, tech. So dependencies on code, dependencies on tools, events, and experts. And that's what this next exercise on dependencies is, is dependencies on an expert. And so let's walk through this second exercise here on dependencies.


So this is a dependency matrix exercise. And how this works is the roles listed at the top here, where you have to turn your head sideways to read. Those are the impactors. For example, the software developer needs something from the network systems engineer to get their job done. So the people listed on the left are needed by the people, by the roles listed on top, right? These are the people who get interrupted <laugh>, the people on the left, these are the people who get called, uh, and their, you know, this, their expertise, their skillset, if you like, are necessary for the folks at the top to get their job done. And the reason that we have gray squares, uh, these squares, uh, grayed out in a diagonal fashion like this is because you wouldn't have a dependency on yourself, not normally, right? The network system engineer doesn't have a de dependency on themselves.


And so what I ask, uh, folks to do is we're not gonna identify every single dependency, because then you'd have the inter, you'd have the intersecting squares flooded. We're just gonna identify the intersecting square of the most crippling dependencies. So that's the instructions for number one. We'll take about 45 minutes to do this. And the purpose is to surface the mo the key delays, the most crippling dependencies. And I'll ask people, uh, number two, I'll say, okay, visualize your dependencies by adding an orange light bulb icon into the intersection between two roles that you see. And if, and this one, this exercise is done with a larger group to begin with, and then we break out into smaller, the smaller breakout groups. But this gives everybody a chance to see where everybody else in the workshop thinks the biggest dependency is. So I'll provide these, uh, icons down here, and I'll let everybody move and move the icon where you think the biggest dependency is.


And so there's lots of activity, and there's moving orange light bulbs everywhere. And I'll say, well, if somebody, if there's already an orange light bulb where you wanted to put one, then just add a thumbs up icon or plus one icon to indicate that that's where you, uh, you agree with that. And so this provokes a conversation on dependencies. Uh, does your workflow give you visibility on where these dependencies are? And then have a discussion on what actions you can take to reduce the negative impacts. And I'll copy this. Um, I'll copy the dependency matrix back into the breakout group, uh, canvases, and then we will continue the conversation on what, what actions can be taken. And this is also an opportunity for the team in a smaller setting to revisit the exercise. And when we do it again, I'll say, okay, let, let, let's try again, because somebody might not have gotten it in the right place. And so we give people an opportunity, let's do this again. Move the pink triangle. Now in the intersection where you see the highest dependency is, and over on the right here, we'll capture insights and, and notes.


And this has, uh, sometimes I'll get asked, well, how do we, how do we make this work? You know, we're all working in these separate teams and how, you know, how could we organize to reduce our dependencies? And that's when we look at, okay, well, if you're managing your work by project now, then maybe let's take a look at moving to a more product centric way of working, and take a look at Mitt Kirsten's book on moving from project to product after the dependency exercise. Uh, and the final point here is that by moving fast as an individual team, you might be paying the price of, of not moving very fast as a whole organization, if there's a lot of coordination costs.


And so, what do we do about this? I I usually wrap up these sessions with an experiment activity, and we'll look at we experiments. You know, let's utilize some science, get some data. If, uh, I think it was Jim Barksdale who said, if we have data, let's look at the data. But if all we have are opinions, and let's go with mine, right? And this is where we wanna talk about culture a little bit, uh, be, and I get people in the mindset that experiments by their very nature are prone to failure. And so we're gonna do safe to fail experiments. If the hypothesis isn't correct, it's still a win because you've learned something. And with that, I bring up a measure of what I like to call flow safety.


And flow safety is a measure of trust, right? Um, this, so this is a net promoter score survey, uh, that you would do normally. The NPS question is, how likely are you to recommend working for this company? We know that high trust organization culture emphasizes the flow of information and it's predictive of organizational performance. And this idea is based on research, uh, by Ron Westrom. But here's some questions that you could ask. You could survey your organization to see how much trust we have. Uh, you know, is there, is there tolerance for inquiry and not blame? And, you know, this approach is based on, it's based on curiosity. So when something arises or people feel that they're disappointed, or it something's confusing, i, I propose that we just get curious about it rather than making it into a problem. Or maybe blame, um, sometimes in the dependency matrix teams that they'll talk a lot about the business and the business side.


And, and so look at from the dependency matrix, look at those orange light bulbs that we serviced as, as a clue to be exposed or to be explored, really, um, see it as actually something to teach you something if you're willing to learn. And, and that to be willing to learn, we need to have curiosity. And hence, we want inquiry curiosity to occur if our hypothesis is incorrect. Um, and also, you know, failures are learning opportunities. Uh, we're not gonna punish our team. So this western model, uh, identifies three kinds of cultures. It's the topology of organizational culture, and we got pathological culture. This is the traditional command of control. It's run by fear, low cooperation and blame. Note how novelty gets crushed. So maybe not the best environment to do experiments in the bureaucratic environment. This is run by rules. There's modest cooperation, novelty leads to, uh, can lead to problems. There may be some tolerance for cooperation. We're really trying to get over here to a generative culture where we've got novelty being implemented, there's tolerance for experiments here.


And so the experiment activity on this side over here, we take about 45 minutes to do this. And we're just gonna use this space, uh, to identify how to improve some of the team pain points, business pain points, the neglected work that we discussed in the first exercise, the crippling dependencies that we discussed in the dependency matrix exercise. I, and we're starting out really simple here. Just give it a title. What's your problem statement? Here's an example that I provide folks. Um, what are some of the activities that you're gonna do? How are you gonna measure outcomes? Uh, and when are you gonna start? How long it's gonna take? Do you need to get sponsorship to do this experiment? Or is it all gonna be within your control? And then these are some examples that teams came up with. Uh, and with that, I think we're at time. And so looking forward to, uh, talking with you and hearing your questions.