Dominica DeGrandis

Dominica DeGrandis: 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 all the WIP 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, in this session, discover how to deal with the brutal combination of important but neglected work and cross-team dependencies.

I'm going to share my screen out here. All right. And so consider a 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 work, this time thief here, it's fueled 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's involved to keep a system secure, reliable, and functioning. And so 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 distributed denial of service, or maybe a corrupt 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 in some very famous books based on IT transformation, such as "The Unicorn Project." And "The Unicorn Project," one of my favorite parts about "The Unicorn Project" is the emphasis on improving daily work. It actually emphasizes one of the five ideals. Dan Pink talks a lot about motivation from autonomy, mastery, and purpose, and mastery is fantastic. But when we're just learning something, 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 helpful in this.

I like to call this kind of work debt work. Here's some examples of debt work. Debt work, it's an investment in future delivery, right? 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 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 with the five ideals from "The Unicorn Project." Note the third ideal. Its emphasis is on improvement of daily work, allocating time to fix this debt work, to give people an opportunity to make improvements during work. Also note the second ideal, which is on flow, right? Focus on flow and joy. Important.

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, 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 in orange there. These are bugs, issues, whether they're production or pre-production, problems that you can consider this as 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 mandates such as GDPR or taxes, major business risks.

And then we have debt in green. Again, these are the investments in 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, if we can categorize our work like this, then we can start to see what the real priorities are.

When I worked at Corbis, I started out as a build engineer, and I did a lot of configuration management and builds and source code, 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-month 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 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've got to do a hotfix for the hotfix because we never had time to fix the debt work that was involved with the original hotfix.

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

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 having a conversation about what is the strategy, or is this month or this quarter, 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 this team can have three debt items in play.

And quite valuable 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 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 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?

I included unplanned work here because if neglected work continues to be neglected for a long time, it morphs into becoming an emergency. You've got to change the oil in your car every so often, otherwise the engine is very unhappy. And with unplanned work, it delays planned work. It steals your predictability. And so it's useful and interesting to look at neglected work. They're like close cousins. Neglected work and unplanned work are close cousins.

So then let's do an exercise. And the exercise over here is called flow distribution trade-offs. And the purpose of it is we're trying to bring visibility to the trade-offs of the neglected work, which is often debt. Debt usually falls in that category of neglected work. 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 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 group doing this exercise included a lot of people from traditional IT teams with help desk and network engineers, sysadmins, DBAs, those kinds of roles.

And so after a discussion on the neglected work and the unplanned work, then I ask them to sketch out what their flow distribution looks like. And there's a sketch feature in... This is MURAL, by the way. And so I just ask them to, what would your flow distribution look like? Approximately, what's the ratio? And I ask them to do this for the month of May. Good, Sean. That's supposed to be for the month of May.

So blue here is 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 wheel spinning on what can we do in our organization to enable more time 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. Usually, these sessions that I do, these virtual workshops, are for, lately it's been between 30 and 60 people. And I'll present some fundamental basics on flow and too much WIP 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 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 do about it.

And so, just doing a quick time check here. Okay. And then we're going to move into dependencies. Let's talk about dependencies.

So 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 really large retail once, and they had this concept of an away story. And an away story was where you had to go away to a different agile team to get the information you needed to complete your task, to get your job done. And most of the stories were away stories because they had so many different small agile teams that had lots of dependencies upon each other. And 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 in email or in Slack channels. It's not captured in the tool set very well, and so then it gets lost and it becomes invisible.

So dependencies tend to affect almost everyone. It's not just IT, right? We see this on the business side, too. The marketing editorial director waits on the social media director, waits on the editorial director 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. The reality is that we work in this web of interdependencies, if not on people, then on architecture or events.

And when it comes to dependencies, dependencies are asymmetrical in their nature, and so every dependency, the probability is 50% that it's going to double your chance of starting late or being delayed, finishing something late. Every dependency doubles the probability of starting late or finishing late. If you've got three dependencies, then 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. I see, and in my book, I talk about this, that there's three types of dependencies, and with dependencies, we're looking at 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 roles listed on top. These are the people who get interrupted. The people on the left, these are the people who get called, and 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, these squares grayed out in a diagonal fashion like this, is because you wouldn't have a dependency on yourself, not normally. The network system engineer doesn't have a dependency on themselves.

And so what I ask folks to do is, we're not going to identify every single dependency, because then you'd have the intersecting squares flooded. We're just going to 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 key delays, the most crippling dependencies.

And I'll ask people, 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 this exercise is done with the larger group to begin with, and then we break out into 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 icons down here, and I'll let everybody 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 there's already an orange light bulb where you wanted to put one, then just add a thumbs-up icon or a plus-one icon to indicate that that's where you agree with that." And so this provokes a conversation on dependencies.

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. Then I'll copy the dependency matrix back into the breakout group 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'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 notes.

Sometimes I'll get asked, "Well, how do we make this work? We're all working in these separate teams, and 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 Mik Kersten's book on moving from project to product.

After the dependency exercise, and the final point here is that by moving fast as an individual team, you might be paying the price 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 usually wrap up these sessions with an experiment activity, and we'll look at experiments. Let's utilize some science, get some data. 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, then let's go with mine." Right?

And this is where we want to talk about culture a little bit, and 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? So this is a net promoter score survey 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 by Ron Westrum.

But here's some questions that you could ask. You could survey your organization to see how much trust we have. Is there tolerance for inquiry and not blame? And this approach, it's based on curiosity. So when something arises where people feel that they're disappointed or something's confusing, I propose that we just get curious about it rather than making it into a problem or maybe blame.

Sometimes in the dependency matrix, teams, they'll talk a lot about the business and the business side. And so from the dependency matrix, look at those orange light bulbs that we surfaced as a clue to be exposed or to be explored, really. See it as actually something to teach you something, if you're willing to learn. And to be willing to learn, we need to have curiosity, and hence we want inquiry, curiosity to occur if our hypothesis is incorrect.

And also, failures are learning opportunities. We're not going to punish our team. So this Westrum model identifies three kinds of cultures. It's the topology of organizational culture, and we've got pathological culture. This is the traditional command and 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 is modest cooperation. Novelty 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 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. 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. What are some of the activities that you're going to do? How are you going to measure outcomes? And when are you going to start? How long it's 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.

And with that, I think we're at time. And so, looking forward to talking with you and hearing your questions.