Making Work Visible: Exposing Time Theft to Optimize Work & Flow

by Dominica Degrandis

If I had to identify what kind of work is most neglected, it would be the work related to improving quality, including deferred maintenance, bugs, technical debt, and code without tests (legacy software, as defined by Michael Feathers).1

Busy people, however, do not signal productivity—delivered value does.

The more people invest in a project, the harder it becomes to abandon it, even when a more rational decision based off of future value would be better. This is known as sunk cost fallacy. In The Principles of Product Development Flow, Donald Reinertsen suggests we should only consider the incremental investment needed to finish the project in comparison to its economic return.3

In other words, it’s okay to kill zombie projects. If they are really needed, zombie projects can return from the dead.

Businesses frequently prioritize new feature releases over fixing technical debt. They choose to work on revenue-generating work instead of revenue-protection work.

You know Thief Neglected Work is stealing time from you when you delay important tasks that will eventually become emergencies.

There is a reason our schools and offices are plastered with whiteboards. We acquire more information through vision than through all the other senses combined.1 Of the 100 billion neurons in our brains, approximately 20% are devoted to analyzing visual information.2 The visual-spatial learner thinks primarily in images. A study done by psychologist and founder of the Institute for the Study of Advanced Development, Linda Kreger Silverman, suggests that two-thirds of the population have a visual-spatial preference.3 The left hemisphere is sequential, analytical, and time-oriented. The right hemisphere perceives the whole, synthesizes, and apprehends movement in space. For visual-spatial learners, if the right hemisphere is not activated and engaged, then attention will be low and learning will be poor.

Making work visible is one of the most fundamental things we can do to improve our work because the human brain is designed to find meaningful patterns and structures in what is perceived through vision. Thus, it makes sense that when we can’t see our work, we have a hard time managing it.

Once we have visibility of our work, we have the tools to manage the problems that slow our workflow down and are able to create the solutions for the unexpected when it arrives.

Visibility matters when a majority of people think in pictures rather than in words. It’s also important to know that this isn’t a learned preference, visual-spatial learners have a different brain organization than auditory-sequential learners.

The goal here is to show how making our work visible is an extraordinarily simple way to show our work demand—the amount and the type of work requested from us by everyone, including ourselves—and begin fixing the time-thief problem. You just have to jump in and start doing it to reap the benefits.

Imagine this board hanging in your office: It’s so simple and simultaneously so informative that you don’t have to explain it to others—anyone

First, there are some things to take into consideration. For instance, if you have a to-do list that looks like it’s the size of War & Peace, then you may be asking if you really need to put everything on your board? No, you do not. The question becomes, what do you trim? Some things are so low on the priority list that it doesn’t make sense to clutter your To Do column with them because that will distract you from the most important work. Also, by the time you finish your top three to five priority items, your next set of priorities will probably have changed.

The guidance here for what to put on your board is to weigh the time cost of managing work items with the value received. It’s not uncommon to see teams implement a policy whereby they don’t create cards for work that takes less than fifteen minutes. Usually there are exceptions to this rule. Knowing when to break the rules is something that comes with experience.

A ten-minute task probably doesn’t need to be tracked unless one of the following is true: Only one person knows how to do it (Thief Unknown Dependencies). Making the work visible can prompt some much needed cross-training. The work impacts other teams (Thief Unknown Dependencies). As discussed in Part 1, cross-team dependencies can be very expensive. The one to two minutes it takes to create a card on a board is low enough overhead to be worth cross-team communication. Someone’s job primarily involves doing tasks that last fifteen minutes or less, meaning if that person’s work isn’t tracked, then it’s invisible (Thief Too Much WIP). If a lot of the work is invisible, then it’s awfully easy to pile too much WIP on top of that person’s normal workload.

you need to start asking questions about your demand, if you haven’t already. Such as, what kind of work do you do? What kind of requests float across your desk, inbox, and chat window? What are the priorities of the work items on your list?

I’m here to say that unnecessary, overnight heroics suck. Here’s the thing: Everyone I worked with at that time was doing the same thing. We were all overburdened with too much WIP, conflicting priorities, and a disjointed work flow, resulting in negative impacts to our health as well as to the company’s organizational health.

Identifying team pain is a portion of the Demand Analysis exercise at the end of this section.

One of the other lessons I took away from my time at Corbis is the need to consider other teams’ pain carefully, particularly customer pain (or business pain). By this I mean your internal customers who are unhappy about the way your work results are impacting them.

You are going to need your internal customers buy-in to limit WIP.

It’s not just all about us. We must consider the whole system by using a Systems Thinking approach to optimize workflow across all teams in order to deliver business value.

Once work demand and pain points are identified, you’ll want to consider your work item categories. Creating categories for your work allows you to see different types of work—not all work is the same! It’s important to have this clearly articulated because different types of work may have different levels of urgency and different workflows need different rules to accommodate them. When we create categories for our work, we can collect the data necessary to create the metrics for the different types of work that shows us (and leadership) the health of our system.

Since there are numerous ways to categorize your work item types, it’s important to always consider what should be visualized in order to gather the proper data and to bring visibility to address problems.

The people doing the work should always be involved with designing their workflow management system for two reasons: It helps ensure you have the right number and types of categories that cover the needs and demand of your entire team. When people participate in creating something, they have ownership, which motivates them to invest in solving problems and achieving desired outcomes.

When you define your work item type categories, you are creating a legend to help your team work with a kanban board effectively. It also allows others, from management to other teams, to interpret the board when they see it.

Card ID Header Title Description Assignee(s) Comment section Tags for query capability Icons for extra visibility Priority Subtasks or connected card fields Date field for date driven requests

Then, list out any roadblocks preventing you and your team from finishing work.

When making your list, be specific. If your IT team’s work is late because of constant interruptions due to competing priorities, note it. If your Marketing team’s work is late because work piles up in the Design department, note it. This is your time to rant about the things you usually just mutter about. Come on, get it out.

Next, list out your customer and/or business pain points.

Multitasking is merely the opportunity to screw up more than one thing at a time. —Steve Uzzell

WIP limits per person are sometimes the first step folks new to kanban take in order to stem the bleeding of overburdened people. More advanced teams set WIP limits at team levels in order to optimize workflow at the bigger-picture level, instead of just the local level. This helps multiple teams to collaborate on team goals instead of focusing narrowly on individual goals.

Visuals like this help team members hold each other accountable with transparency. The WIP limits add tension to the system. People are compelled to innovate and resolve issues preventing them from finishing their work. WIP limits provoke necessary conversations.

Silver bullet requests tend to come directly from leadership. This swimlane is sometimes called the VP lane. CIOs and VPs often don’t realize the disruption created when they ask for things outside of the standard process. Bringing visibility to silver bullets helps show the cost associated with these requests.

Remember, categorizing work by who requested it brings visibility to the communication involved—internal, external, or leadership.

Flow requires clear and prompt feedback. Waiting on feedback from others is one of the biggest delays in workflow. The longer it takes to get feedback, the easier it is to forget details and the harder it is to be able to pick the work back up again.

If you want to be more predictable, limit WIP to the team’s capacity. What is the team’s capacity, you ask? Good question. Don’t let it be 90–100%.

You’ve got to start somewhere. Starting with a thin layer of something good is sometimes the only way to get started. Sometimes trying to make too big a change to your current process, such as implementing a strict set of WIP limits, could cause you to crash and burn.

The hardest thing we do is communicate across teams. —Troy Magennis

When a crisis occurs with one project team, people from other projects can be pulled off of their work to address the crisis. This leads to what is known as a high coordination cost. When the coordination cost between teams is high, people aren’t available when you need them to be—and a project manager is often put in place to coordinate.

Now, what to do about dependencies? If they are a problem for you and your dependency matrix, or if software isn’t providing the necessary visibility, then you must find a way to make them visible across impacted teams.

Teams rarely work in isolation. If a skill set is needed from a different team, then hand-offs between the two teams need to happen. To avoid the “out of sight, out of mind” issue, visualize work flowing between teams. This helps people anticipate work that’s headed their way and avoid “Oh, by the way, you need to do this thing today” situations. It also provides them with a heads-up on potential issues that are coming their way, which is usually much appreciated. Visualizing important cross-team information helps communicate across teams.

In this way, the project team’s expertise becomes a domain knowledge dependency.

Organizing teams around a product allows the people who developed, tested, and delivered the functionality to stay in their area of expertise. There is no need for complex, dependency-driven hand-overs. Instead, organizing teams by product decreases dependencies during hand-off to ongoing operational support.

The project/product distinction is an important one for many reasons,

Projects come and go and require extra coordination and communication to set up and organize temporary teams. Many issues can arise when maneuvering through a cumbersome, project-oriented process.

In contrast, organizing and managing by product keeps the same group of people with the necessary expert domain knowledge consistently involved.

Project teams tend to be measured by vanity metrics (e.g., test teams within a project team are measured by the number of software bugs), whereas product teams are measured by the business value derived.

“Architecture is so tied to how we do our work. The preferred architecture is loosely coupled components, individual microservices, built by individual teams—autonomous product teams, not project teams.”

I asked two IT project managers responsible for supporting the team of forty-one engineers what prevented them from getting work done. Their immediate response was constant interruptions. They were being bombarded with project status questions from other teams and product owners.

There’s usually resistance to this in the form of Platform Operations Manager Erik, who says, “I don’t have time to create a ticket every time I get interrupted!” But after weeks of interruptions, the CIO wants to know why Azure isn’t up and running in production. And what does Erik say? “We’ve been busy.” This is the problem—there is no evidence of the issues preventing Erik from completing the platform work.