Dominica DeGrandis

My name is Dominica DeGrandis. Thrilled to be here.

I live in Seattle, Washington, so I've been hanging out in London this week.

For 20 years now, my role in IT has been to make problems and risks visible. And it hasn't always been the most popular role to play, but I think it's important, because making problems and risks visible is the way to start the conversation on how to change and how to improve.

And so today, I want to shed some light on how to do that. I want to show you how to make conflicting priorities visible, how to make the impacts of them visible, and then how to influence others for change.

When I ask people what prevents them from getting their work done, like, "What randomizes their day?" this is what they say. And usually conflicting priorities is in the top two or three every time. I've asked hundreds of teams this question. The idea is that if they didn't have to be working on 20 things at the same time, they could have a clear focus. They'd be able to get their work done much faster.

There are some other time thieves here that get in the way of getting work done, like unplanned work, and unknown dependencies, and too much work in progress. And we'll see that theme through my talk here.

So how do we get here with conflicting priorities? This is one way, a fairly common approach: typical project management plan. And you've got tasks on the left, and some estimated start and end dates, and then the people who are assigned to the tasks, with a Gantt chart on the right showing some dependencies.

So here you can see that Courtney can't start her stuff until Sarah and Nicole finish their items. But what if Courtney's working on three projects at the same time? Right. Teams rarely work in isolation. So how does Courtney prioritize the work across these three different projects that she's working on?

If people could see all the things on Courtney's plate, then the problem would be self-evident. But usually people are not looking at the big picture. They're just looking at their team work, their own project work. And so then Courtney's work becomes invisible, and it's hard to manage invisible work.

And I think this is the problem with many of the traditional project management processes and tools that we see out there. It's very difficult to see cross-team dependencies and the impacts that they have on us.

Too much invisible work, and time thieves love invisible work, like handoffs and dependencies, because then they can sneak in and steal time out of the calendar.

So here's the thing. Team A's top priority is rarely team B's top priority. And so, with expert skills in high demand, you're not available when other teams need you. And this is one of the problems that we have.

The damage just isn't to the team. It's to the larger organization. Because people are supporting multiple projects, they've got more conflicting priorities. This results in having more work in progress. Then people become the bottleneck because of their specialism. It delays other work.

There's a few seats here up on top. We've got one, two, like six seats up here, and a few over here.

And so this results in unmet business goals. And that just drives more projects and more initiatives. How are we going to solve this?

And when the business misses the milestone, what happens? The CEO calls all the execs into the room, and they want to know what happened. And everybody's looking around, wondering what's going on.

Well, everybody's got 20 competing priorities. Twenty competing priorities times 20 people in the room makes for an environment where it's so difficult to focus on any one initiative that nothing gets done on time.

So in this world, people just aren't addressing the elephant in the room. And the elephant in the room is that we've got too much work in progress. There's too many initiatives that are going on at the same time.

Instead of addressing the elephant, people start to describe the problem. So VP of Ops is saying, "Well, we had this security breach a couple weeks ago. We're still dealing with issues in production."

And the VP of Development is saying, "Three of our key people resigned three weeks ago. We're still trying to backfill them."

And developers are complaining about being at too many boring and unproductive meetings, and they've got too much ad hoc work that causes interruptions, and so they don't have enough focus time in their calendar to get their work done.

And then the VP of Product, what do they say? VP of Product says, "Hey, we promised this feature to our customers. They're waiting for it. We're going to lose a big customer to a major competitor because of this feature gap."

And then the CEO says what? They're like, "I need to have confidence in our ability to deliver this before our next board meeting. So I need to see an action plan on my desk next week."

So in a world of ever more competition and competing priorities, there's a need to deliver faster and faster, and more and more solutions. But how do we balance that with the fact that people have a finite amount of capacity?

Kind of like this freeway here. The cars can only move so fast. There's only so many lanes. You cannot move faster than the car in front of you. So you know when you get on this freeway that your commute home is going to be longer.

The same thing with computers. Computers stop responding when they get close to 100% capacity utilization. And we don't let our computers get to 100% capacity utilization, so why do we let our people? We do this to ourselves, and we need to stop it.

The higher the utilization, the longer the wait times, especially in areas of IT, because there's so much variability, because of the unplanned work, because of the interruptions and the context switching.

And so the single most important factor that impacts wait times is capacity utilization. And when you look at the math, you can see why that's so. Wait time increases exponentially as utilization approaches 100%.

So back to Gantt charts. Gantt charts, you can't see the problems that are due to bottleneck people, and wasted time, and blocked times from people who are allocated at high utilization levels. Keeping people busy all the time is neither effective nor efficient.

So if you have some similar problems, and speed is an issue, and you need to get those features out faster, highly recommend checking out managing by queues instead of timelines. Because people get overbooked, and with conflicting priorities, it's going to cause delays.

So when people get overbooked, it doesn't show up in the Gantt chart. It shows up in the calendar. If your calendar looks like this, if you've got this all-day cram going on, no white space, then thief conflicting priorities is stalking you.

You cannot be in two places, let alone three places, at one time. Yet our calendars get double-booked and triple-booked. And I know this sounds obvious, but the calendar, there's only space for one meeting at a time. It would seem obvious, but yet we still allow ourselves, because it's very hard to say no. We're human, and we want to be part of the team, and we say yes, and we over-allocate ourselves. We do it to ourselves a lot of the time.

So what happens if you're double-booked? You either don't show up, you do one of these, "Carry on without me," or you reschedule. And both of those have a cost in rework. Because if the decision-makers aren't at the meeting, then the decision gets delayed, and it goes back to our vicious, perpetual cycle of unmet business needs.

And also, it's not just for the decision-maker. Somebody spent hours preparing material for this meeting. I'm talking about a real meeting, not a status meeting, but a meeting where you need feedback. You need conversations and discussion to determine decisions that need to get made.

The longer the time that goes by from when you needed feedback or a decision made until you got it, the harder it is to get back up to speed, the more you have to rehash conversations, the longer the flow time.

So it's a huge problem, and it's an interesting data point. What is the cost of rescheduled meetings in your organization? Do you know that? Interesting data point. It's a big problem, because people are starting to send me memes about being overbooked.

So high utilization increases wait times and needs to come into play when we're talking about conflicting priorities. Do we even have capacity to take on this new work? Because a decision to do feature A is a decision to delay feature B. I think we don't think of that enough when we're making our prioritization decisions.

So how do we make better prioritization decisions? We start by just laying it all out there for people to see. Let's make the work visible, and let's make the load on the teams visible. What is the team load?

And here's one way to do that. At the very high level, this is a visual showing nine initiatives at the portfolio level, and those are broken down into two programs, and then that gets broken down and out to the teams. And this kind of visual can help you see the dependencies and help expose the load across the organization.

It can be a big eye-opener to do this. But this is just for one initiative. Imagine if all nine of them were mapped out. Imagine if you had the capability to look at all 20 initiatives and all the impacts and the conflicting priorities across the organization.

So this is often the reality. The big picture is invisible, and it's hard to manage invisible work.

So how do teams decide what to prioritize between the different programs? Here's an example of a team board. They're using a pull system. This is Kanban, although maybe they might need to use KanWIP because they have constant demand.

So the legend shows three kinds of work here. The blue work is revenue generation work. These are the feature requests from the business. The green work is what I call revenue protection work. This is the fixing the technical debt, the maintenance, the security compliance stuff, keeping the lights on.

And then in yellow there, that's unplanned work. So you can see there's no unplanned work in the backlog, in incoming. The unplanned work shows up when it's done. If we're lucky, it'll show up in the doing column. We call that born in doing.

But this is the power of visualizing work. Our eyes are looking at this visual, trying to figure out what the colors and the patterns and the text all mean, right? We need very little education to understand here that we've got a million incoming requests, and the team doesn't have capacity to handle them all.

So when it comes to prioritization, it's important to understand capacity utilization and flow time.

So flow time is after we've decided to do something, after it's been prioritized, and it gets pulled into our work in progress queue. So that would be under the WIP column there.

If we can understand flow time, and we have some history on that, we can forecast pretty good how long something's going to take. Right? How long is it going to take this team to do project A or feature A? And do the teams even have capacity to take it on right now?

Because if we can't finish feature A in six weeks or six months, then we need to change priority in the top five there and bump up the priority on feature B.

What we've done here is they've triaged the million things in the backlog and decided what the top five things are to do. And so instead of rank-stacking the entire backlog, we're just saying, knowing that it could take six weeks to do a feature, how should we prioritize our work?

And so if the team load is 10 here, because we've got WIP, eight plus two is 10. Two of those can be green, by the way. This allows the team to work on technical debt or do their own internal team improvements, because that was one of the pain points on that first slide. In addition to conflicting priorities, one of those pain points is, "We don't have time to do our own internal team improvements."

But if you have a policy with your work in progress limit like this, it gives the team an opportunity to do that.

But you can still see there's two items that are sitting idle in the waiting horizontal swim lane. So this is a clue that the team load is too high, and we need to bump down those work in progress limits.

So in my opinion, a visual like this is much more useful than one like this. I call this a beastly practice. It's where we have individually named swim lanes. Several problems with this design. The biggest one, in my opinion, is that it could be that the very most valuable thing for the company is if Jason went and helped Brian finish something.

But there's no incentive in this design to do that, right? Because people are incentivized to just work in their own row and get that work done.

So if you're in this scenario, one thing you can do, the next step would be just to create avatars. Put that avatar on the card so you know who's doing what. And then instead of individual names up front there, put down the skill sets that are needed for that job to be complete. And it'll help you with your hiring, too. What kind of skill sets do we need?

So if people have eight things on their list, how are they going to prioritize? And do they have the visibility on how leadership is prioritizing the initiatives and the programs? Yeah. It's fairly easy for prioritization to get lost as it trickles down from portfolio to program to teams.

So help people at all levels see how work is prioritized, how those decisions are made, and start at the top. How does your organization prioritize?

Here are some common ways that I see teams and organizations prioritizing.

The first is ROI, return on investment. Well, do people at the team level know how that's determined? What is return here for your org? Is it profit? Is it revenue? Is it growth? I mean, it's different depending on your industry and where you are in your transformation.

Maybe some orgs are looking at cost of delay, right? This is the measure of impact of time over your desired outcome. Because return on investment doesn't always take time into consideration, and if it takes six months for feature A to get out, then you might want to reprioritize and do feature B if you know you can get that out faster.

So cost of delay can be useful, although it's a challenge to measure for everything. Some are easy, some not so much.

Next up is weighted shortest job first. And people talk about this when cost of delay is the same and size is the same. Then what you do is divide the delay cost by the duration: weighted shortest job first. If you're using the SAFe model, they use a variant of this.

Next up is first in, first out. That might work well for some standard work. It works in restaurants and at doctor's offices, but it doesn't work in emergency rooms or with security breaches. But it may work for a bulk of your work.

The idea here is, looking at these boards, do you know how work is prioritized, and does it make sense? And maybe we need to look at a combination of some of these. Otherwise, how is work getting prioritized? Is it by the person who's yelling the most? Maybe it's by the HiPPO, the highest paid person's opinion. Maybe that's okay. Is it? Have the discussion.

So visualizing and knowing your work in progress capacity, and your skill sets, and strengths and weaknesses can help, because then people can see the total load on the team.

But this kind of information is hard to see in standard project planning reports, like this red, yellow, green report. How many of you out there are doing this? Red, yellow, green. I see a few hands raised up.

So why are red, yellow, green reports always green? Is this one mostly green because Adam's team went and helped other people finish their projects, their work?

If Adam gets hauled into an executive office because of his transparency on going red, what is the probability of Adam reporting red next week? Pretty low.

And so what we're seeing is that red, yellow, green reports are an oversimplification. They hide details, and they can be misleading, and the truth gets lost. And so it's the reason why I'm observing a lot of leadership saying, "Don't do the red, yellow, green report." They don't want it anymore, because they'd rather see real data in a dashboard that shows the truth over a politically sanitized report.

And so consider shifting. Well, this point here: think about when you visit a badly designed website. How little do you trust that information there?

Instead, the guidance here is to show the real data with the tools that you're using. And I created this exercise to give people an opportunity to learn how to do this, learn some good DevOps metrics, how to track them, how to chart them, how to present them.

And the idea here, which I was very much inspired by Troy Magennis, is to show one metric trend in four different areas. Because it's fairly easy to game one metric, but if you can show a balanced set, then you can start to see how a change in one metric is going to impact the other metric.

So I've got four measures here: one for speed, which is going to be flow time; one for productivity, which is going to be throughput; a quality metric; and then a metric to see how predictable you are.

The x-axis here, the horizontal axis, is the date that the work actually completed, and the vertical axis is how many days it took for that work to complete. And the spreadsheet has a list of all this work that was completed. And when you plot it all out, it looks like this.

So that purple arrow there is pointing to, you can see the legend on the right, it's pointing to a business request, a revenue generation request. And it took 14 days to do, and it was finished on September 19th.

And in this, if you're sporting an all-day crammed calendar, and you're so overbooked, and you have three emergencies that pop up, that unplanned work, if you're tracking it, it's going to show up in your data like this.

And you can show this to people and demonstrate why the feature request was a week later than expected, because all these emergencies came up. Unplanned work delays planned work. That's thief unplanned work there in yellow. And if you're not tracking it, that means you have all this invisible work that's consuming the team's capacity and utilization that's invisible. Hard to manage invisible work.

Now, this is the second metric overlaid on the same chart. This is throughput. This is the number of things that were completed by week. So in the first week there, we got eight things done. The second week, we got seven things done.

Now this starts to get interesting. It starts to tell a story. You can see that our flow time, the time it takes to complete work, is trending up, and the throughput is trending down. Hmm. We can dive into the data and see if there's a relationship there. It's a good hypothesis.

But bringing this kind of visibility of risks up early to the table, it's going to provoke necessary conversations on how we should be prioritizing, and conversations that are going to enable change.

The third metric that I'm using here for a quality metric is change failure rate, and you'll see this in the State of DevOps report. This is essentially just the number of items. We call it failure demand, but it's bugs in production, features that aren't working right, security breach. The total number of work that we did that were problematic divided by the total number of items that we did. It's a ratio, and it's extremely easy to calculate if you're already calculating throughput. It's just simple division there.

Looking at a diagram like this is much less threatening, I think, than looking at a red, yellow, green report. Because you can explain this to people and present it, and people can start to see, "Oh, yeah. Okay, I understand where you're coming from." We can all stand on the same side and look at the chart, and the chart can be the thing to fix.

By the way, I'm going to give you a link to this exercise.

And the fourth metric is the 90th percentile. You can use whatever percentile you like, but the 90th percentile, you're going to have a lot more confidence than if you use the average, which is the 50th percentile. Remember, the CEO wants to have confidence in the team's capability to deliver by the next board meeting.

So with percentiles, this answers the question of what's the probability of finishing this work in so many days. If we want to be predictable, we need to look at probabilities. We're trying to be approximately right instead of exactly wrong.

So I use this in my workshops to help people, teams get visibility on different kinds of metrics, and different kinds of work, and how to correctly measure them.

So I help teams make their work visible so that they can find bottlenecks, and then I help them design systems to optimize their workflow end-to-end. And so with this, we can start to understand the stories and the data instead of being led astray by a politically sanitized red, yellow, green report.

And these kind of charts, they can apply to you personally. You can do them at the team level, and you can do them at the organizational level. If you're already measuring something like this and you're going through a big transformation, then the next step would be, how do we measure this across the whole value stream?

So because we could measure all of our work in progress against the value stream, we'd be in a position to be much more predictable and get our objectives met.

So here's my hypothesis: that having fewer competing priorities is going to help you find good work in progress levels, and it's going to put you in a much better position to meet your milestones, make the CEO happy, and reduce that team pain.

Keep in mind that too much work in progress comes from too much yes, because we have a hard time saying no.

So here's the three takeaways. I'll leave it up there for you to get a shot of it.

So visualize your work. Visualize the problems. Visualize the risks, because it's going to start conversations that are necessary for change. And if you can, capture and present metrics to help other people understand and get it. And then be clear on what too much yes does.

And what if we just took a cue from Warren Buffett here and protected our time by saying no a bit more. No is an honorable response to somebody who's asking you to do something that is not a top priority.

You have my permission to say, "No, we don't have capacity for that right now. Here is our top priority."

You can have a lot of priorities, but there can only be one top priority. So find some clarity on that and get agreement from leadership on what that should be.

Your calendar's not going to organize itself. The onus is on you to do that, and you can do that by making your work visible and your workload.

If I can do it, you can do it, too. Somebody's going to influence your boss, and it might as well be you.

So if you want a copy of this presentation, just send an email to dominica@sendyourslides.com. Make sure you put Flow in the subject, and you'll get an automatic email reply with a link to this deck and a few other goodies here: some excerpts from my book, Making Work Visible; excellent article on Tasktop that has a video that shows how ServiceNow connects up with TFS, that connects up to your front-end ALM system. That's what we do at Tasktop. We're a tool integration platform infrastructure.

Oh, and then we have this really cool free Forrester article. How often do you get a free Forrester article on this new thing called value stream management?

If you want to talk more about this topic, I'm going to be at one of the speaker lunch tables upstairs in Riverview, coming up for lunch today. And then tomorrow, I'm going to be at the Tasktop booth during the morning break, so come talk to me.

Thank you.