00:00:07

Hello. My name is Dominica DeGrandis and I'm principal flow advisor at Tasktop. This session comes in response to many people who are curious about how to handle too much work in progress, how to handle the web 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 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. We're sharing 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. So in neglected worth this, this time thief here,

00:02:02

It's told by nonfunctional 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 rubbing revenue generating work is top of mind for business people, but maybe not so much the longterm health of the platform and the infrastructure. And as a result, revenue protection work takes a back seat until something blows up like Adidas attack, right? A district distributed denial service, or maybe a corrupt database that brings down credit card fulfillment. Now neglected, where has morphed into an emergency and now becomes unplanned work. It becomes a fire and puts teams in mode. And because this is such a common problem, it's become a theme. Uh, and in some very famous books based on it transformation such as the unicorn project and the unicorn project.

00:03:23

One of my 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 performed 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.

00:04:41

There are, here's some examples of debt work, debt work it's defined. It's an investment in future delivery, right? It said it's, and it's not just technical debt. Technical deck is part of it, but it's an investment in people and process and tools in the, in the culture, whatever we're doing, that's going to 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. No, 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, enjoy important important.

00:06:02

Now, when you have a focus on flow, it's useful to 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 or features. 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 governant government mandates, such as GDPR or taxes, major business risks.

00:07:26

And then we have debt in green. 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 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. 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 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 a whole weekend. And you just pray that the website is up and running by the time that 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 hotfixes in production. So we'd have band-aids 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 got to do a hot fix for the hotfix because we never had time to fix the debt work that was involved with the original hotfix.

00:09:11

If you can categorize work in this way, Then you can start to, um, have conversations and influence prioritization. You can start to make the trade-offs clear, what's the priority. This just leads directly into, you know, conflicting priorities.

00:09:37

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 are, is this month or this quarter, or 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 dat, 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 re-ask, 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 going to 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.

00:11:26

I included unplanned work here because if neglected work continues to be neglected for a long time, it morphs into becoming an emergency. If you don't prepare for it, you know, you got to 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. It steals your predictability. Uh, and so it's useful and interesting to look at neglected work. They're like close cousins, neglected work and unplanned work, close cousins. So then let's do an exercise. And the exercise over here is it's called flow depletion, 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, and the goal is really how do we enable more time to make these daily improvements that gene talks about in the unicorn project?

00:12:49

So 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, with this training, we could see that cross training was neglected. Professional development was neglected. Vulnerability management was neglected as well as upgrades and alerts. And then on the right hand side, we can see what turned into an expedite 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 help desk and network engineers, this admin CBAs, 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.

00:14:07

And there's a, there's a sketch feature in, um, this is mural by the way. And so I just asked 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 that's supposed to be for the month of may. So blue heres features, orange is 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 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 wheels spinning on what can we do in our organization to enable more time to do this important neglected word before it morphs into an emergency before unplanned work gets its hands on it.

00:15:26

So then we'll come back this, um, usually these sessions that I do, these virtual workshops offer any, you know, lately it's been between 30 and 60 people and we'll have a, um, I'll present some fundamental basics on flow and, and too much whip and time thieves. And then we'll 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.

00:16:22

Uh, and so, um, just doing a quick time check here. Okay. Um, and then we're going to move into dependencies. Let's talk about dependencies. 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 in a way story was where you had to go away to 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 teams rarely 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 the situation, it becomes very hard to communicate across teams. And a lot of communication ends up happening and email or in slack channels. You know, it's not captured in the, in the tool set very well. And so then it gets lost and it becomes invisible.

00:18:05

So dependencies tend to affect almost everyone. The, um, it's not just it, right. We see this on the business side to the, the marketing editorial director, White's 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 that byline. So then she can look at the trends and collect metrics. Uh, the reality is, is that we work in this web of interdependencies if, if not on people then on architecture or events. And when it comes to dependencies, their dependencies are asymmetrical in their nature. And so every dependency ha uh, the probability is 50% that it's going to double your chance of starting late or, or being delayed, finishing something late. Every dependency doubles the probability of starting late or finishing late.

00:19:15

If you've got three dependencies, Dan, it's not a 33% probability that something's going to 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 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, texts. 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.

00:20:30

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 means something come 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. The people on the left. These are the people who get called, uh, and there is their expertise, their skill set, if you like are necessary for the folks at the top to get their job done. And the reason that we have gray squares, the squares are 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 dependency on themselves.

00:21:39

And so what I ask folks to do is we're not going to identify every single dependency because then you'd have the inner, you'd have the intersecting squares flooded. We're just going to identify the intersecting square of the most crippling dependencies. So that seems structions 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 a number TLC, okay, visualize your dependencies by adding an orange light bulb icon into the intersection between two roles that you see. And if in this one, this exercise is done with the 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.

00:22:55

And so there's lots of activity and there's moving orange light bulbs everywhere. And I'll say, well, 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 are 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'll continue the conversation on 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.

00:23:59

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 hair will 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 Mick 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.

00:25:06

And so what do we do about the site? I usually wrap up the sessions with an experiment activity and we'll look at experiments. You know, let's utilize some science, get some data. Uh, I think it was Jim Barksdale, who said, if we have data, let's look at the data, but if all we have our opinions and let's go with my right, and this is where we want to talk about culture a little bit a B, and I get people in the mindset that experiments by their very nature are prone to failure. And so we're going to 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?

00:26:23

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 by Ron Westrum, 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 this approach is based on it's based on curiosity. So when something arises where people feel that they're disappointed or it's, 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 that teach you something, if you're willing to learn.

00:27:37

And in that to be willing to learn, we need to have curiosity and enhance. We want inquiry, curiosity to occur. If our hypothesis is incorrect, um, and also, you know, failures or learning opportunities, uh, we're not gonna punish our team. So this Western model, uh, identifies three kinds of cultures, the typology of organizational culture, and we got pathological culture. This is a traditional command and control. It's run by fear, low cooperation and blame note, hell novelty gets crushed. So maybe not the best environment to do experiments in the bureaucratic environment. This is run by rules. There is modest cooperation, novelty leads to 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.

00:28:50

And so the experiment activity on this side over here, we take about 45 minutes to do this, and we're just going to use this space 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 am, 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 going to do? How are you going to measure outcomes? Uh, and when are you gonna start? How long going to take, do you need to get sponsorship to do this experiment or is it all going to 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.