How to Visualize Impacts to Your Workflow & Metrics

The following is an excerpt from a presentation by Dominica DeGrandis, foremost expert in Kanban Flow within the IT industry, titled “How to Visualize Impacts to Your Workflow & Metrics.”

You can watch the video of the presentation, which was originally delivered at the 2018 DevOps Enterprise Summit in London.

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

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 impact of them visible
• How to influence others for change

When I ask people what prevents them from getting their work done, what randomizes their day, this is what they say:

Usually ‘conflicting priorities’ is in the top two or three, every time, and 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, and 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,’ ‘unknown dependencies,’ and ‘too much work in progress,’ you’ll see a theme emerge here.

How do we end up with conflicting priorities?

This is one way, fairly common approach, a typical project management plan. You’ve got tasks on the left and some estimated start and end dates, and then the people who are assigned to the task with a Gantt chart on the right showing some dependencies.

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. 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 aren’t looking at the big picture. They’re just looking at their teamwork and their own project work, so then Courtney’s work becomes invisible and it’s hard to manage invisible work.

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.

Time thieves love invisible work. Things like handoffs and dependencies, they can sneak in and steal time out of a calendar.

The truth is team A’s top priority is rarely team B’s top priority

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. Since people are supporting multiple projects, they’ve got more conflicting parties. This results in having more work in progress, and people becoming the bottleneck because of their specialties, which delays other work.

Which all results in unmet business goals, and that just drives more projects and more initiatives.

When the business misses the milestone, what happens?

The CEO calls all the execs into the room and to ask what happened. Everybody’s looking around wondering what’s going on. Well, everybody’s got twenty competing priorities. Twenty competing priorities times twenty 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.

people 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 are too many initiatives that are going on at the same time. Instead of addressing the elephant, people start to describe the problem.

• The VP of Ops is saying, “Well, we had a security breach a couple of weeks ago, we’re still dealing with issues in production.”
• The VP of Development is saying, “Three of our key people resigned three weeks ago, we’re still trying to backfill them.”
• 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 focused time in their calendar to get their work done.

• The VP of Product says, “Hey, we promised this feature to our customers, they’re waiting for it. We’re going to lose big customers to our major competitor because of this feature gap.”
• And finally, the CEO says what? “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.”

In a world of competition and competing priorities, there’s a need to deliver faster 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 are only so many lanes. You cannot move faster than the car in front of you. 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.

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%.

With Gantt charts, you can’t see the problems that are due to bottleneck people, or wasted time, or blocked times from people who are allocated at high utilization levels. Keeping people busy all the time is neither effective nor efficient. If you have some similar problems and speed is an issue and you need to get those features out faster, I highly recommend checking out managing by cues instead of timelines, because people get overbooked, and with conflicting priorities it’s will cause delays.

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 with no white space, then the time thief of ‘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 there’s only space for one meeting at a time. It would seem obvious, but we still allow it to happen to ourselves because it’s very hard to say no. We’re human and we want to be part of a team, so we say ‘yes’ and over-allocate ourselves.

What happens if you’re double booked?

You either:

• Don’t show up
• Say “Carry on without me”
• Reschedule

And all of those have a cost and 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 it’s not just the decision maker who suffers, 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 be made. The longer the time that goes by from when you needed a decision made until you got it, the harder it is to get back up to speed.

It’s a huge problem and it’s an interesting data point. What is the cost of rescheduled meetings in your organization?

Ultimately, high utilization increases wait times and needs to come in to play when we’re talking about conflicting priorities.

Do we even have the capacity to take on this new work?

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. Which begs the question, 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? 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.

This type 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 those. But this is just for one initiative. Imagine if you had the capability to look at all 20 initiatives and all the impacts and the conflicting priorities across the organization.

This isn’t often the reality. The big picture is invisible and it’s hard to manage invisible work.

How do teams decide what to prioritize between different programs?

Here’s an example of a team board, they’re using a Poll System.

This is Kanban, although maybe they might need to use CONWIP because they have constant demand. 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.
• Then in yellow there, that’s unplanned work.

You can see there’s no unplanned work in the backlog and 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 boring and doing.

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

When it comes to prioritization, it’s important to understand capacity utilization and flow time. 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, which would be under the WIP column there.

If we can understand flow time, we can determine, we can forecast pretty good how long something’s going to take.

• How long is it going to take this team to do project A or feature A?
• Do the teams even have the 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 the priority in the top five there and bump up the priority on feature B. What we’ve done here is they’ve triaged a million things in the backlog and decided what the top five things are to do. Instead of ransacking the entire backlog, we’re just saying, “Knowing that it could take six weeks to do a feature, how should we prioritize our work?”

If the team load is 10 here, because we 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.

You can still see there are two items that are sitting idle in the waiting horizontal swim lane. This is a clue that the team load is too high and we need to bump down those ‘work in progress’ limits. 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 went 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. Because people are incentivized to just work in their own row and get that work done.

If you’re in this scenario, one thing you can do would be to create avatars. Put that avatar on the cards, so you know who’s doing what, and then instead of individual names put down the skill sets that are needed for that job to be complete. It’ll help you with your hiring too.

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

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

Here are some common ways that I see teams prioritizing.

1. 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. Some orgs are looking at cost of delay. This is the measure of the impact of time over your desired outcome, and return on investment doesn’t always take time into consideration. 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. A cost of delay can be useful, although it’s a challenge to measure for everything.
2. Weighted shortest job first. People talk about this when the cost of delay is the same, and the 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.
3. 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 is, do you know how work is prioritized and does it make sense? Do we need to look at a combination of some of these? Or is it just getting prioritized by the person who’s yelling the most? Maybe it’s by the hippo, the highest paid person’s opinion.

Visualizing and knowing your work in progress capacity, your skill sets, 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.

Why are red-yellow-green reports always green? Is this one mostly green, because Adam’s team went and helped other people finish their work? If Adam gets hauled into an executive office, because of his transparency ongoing red, what is the probability of Adam reporting red next week? Pretty low.

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. It’s the reason why I’m observing a lot of leadership saying, “Don’t do the red-yellow-green report,” Because they’d rather see real data in a dashboard that shows the exact truth, over a politically sanitized report.

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.

I created this exercise to give people an opportunity how to do this

So they can learn some good DevOps metrics, how to track them, how to chart them, how to present them.

The idea here, which I was very much inspired by Troy McGinnis, is to show one metric trend in four different areas. It’s fairly easy to gain 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.

Here I’ve got four measures:

• One for speed (which is going to be flow time)
• One for productivity (which is going to be throughput)
• A quality metric
• A metric to see how predictable you are

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.

When you plot it all out, it looks like this.

That purple arrow there is pointing to a business request, a revenue generation request, and it took 14-days to do, and it was finished September 19th.

In this, if you’re sporting an all-day cram calendar, and you’re so overbooked and you have three emergencies that pop up, that unplanned work will 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. The 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 in utilization, that’s invisible. Hard to manage invisible work.

This is the second metric overlaid on the same chart.

This is throughput. This is the number of things that were completed by week. 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. You 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, 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.’

This is essentially just the number of items we call 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.

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

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.

This answers the question of “what’s the probability of finishing this work in X number of days?” If we want to be predictable, we need to look at probabilities. We’re trying to be approximately right, instead of exactly wrong.

With this, we can start to understand the stories and the data, instead of being led astray by politically sanitized red-yellow-green reports. These kinds of charts 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 measuring this across the whole value stream? Because if 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.

Here’s my hypothesis

Having fewer competing priorities is going to help you find good work in progress levels and is going to put you in a much better position to meet your milestones.

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

Here are the three takeaways:

1. Visualize your work, visualize the problems, visualize the risk because it’s going to start conversations that are necessary for change.
2. If you can, capture and present metrics to help other people understand and get it.
3. Be clear on what to much yes does. Because no is an honorable response to somebody’s who’s asking you to do something that is not a top priority.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•