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

by Dominica Degrandis

When we can’t see our work, our options are obscured. We’re blind to our own capacity and we certainly can’t communicate that capacity to others. The resultant mental overload creates stress. Stress compounds the work we already have, essentially contributing to WIP, compromising the ability to focus, prioritize, make decisions, and complete work with quality, let alone complete work at all.

The visualization and WIP-limiting strategies Dominica offers demystify our cognitive load; normalize expectations among team members; promote focus; situate work in its context, surfacing problems (and allowing for solutions to be made) in real time; and provide a clear path to completion with quality.

The thoughtful observations and easily implementable suggestions Dominica offers are the first step in helping create habits that lead to a virtuous cycle of healthy, sustainable, and improvable work. Work in which we experience more clarity, less stress, increased focus, improved decision-making, manageable workloads, and, by extension, a more fulfilling work day, which in turn affords us the slack needed to fully live our lives rather than simply chase productivity.

Indeed, time is sacred. Treat it as such. Visualize your work. Limit the amount of work you take on. Pay attention to its flow. Build thoughtful work systems to reflect what really matters.

The fact that developers and testers had come to me to ask for status updates was a symptom of a much larger problem that I didn’t recognize at the time.

The amount of requests (the demand) and the amount of time people have to handle the requests (their capacity) is almost always unbalanced. This is why we need a pull system—in which people can focus on one thing long enough to finish it before starting something new—like kanban. Kanban is a visual pull system based on constraints that allow workers to pull work when they have availability instead of work being pushed onto them regardless of their current workload. Since demand and capacity are frequently unbalanced, and it’s almost impossible to get everything done on time, systems like kanban are for helping people balance all their work demand.

We’ll get into kanban and where it fits into the process of making work visible a bit later, but for now, know that kanban is an approach to make work and problems visible and improve workflow efficiency. Kanban helps you get work done efficiently without burning the midnight oil night after night.

David Anderson visited us monthly to teach us how to apply the Theory of Constraints (TOC) to our work in exchange for permission to write a story about the Corbis Agile transformation. TOC is a way to identify the most important limiting factor (the constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor. There was much excitement while reading his book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results as we thought we would do Feature Driven Development, a type of Agile development focused on cross-functional, collaborative, and time-boxed activities to build features. As Darren Davis writes in his blog “The Secret History of Kanban,” David’s methods “...eliminated explicit estimation from the process, and relied on data to provide a probabilistic means of determining when software was likely to be done.”2

We intuitively knew we had too many projects in flight, but it was hard to see until we measured the actual time that it took to get work done, at which point it became obvious the work spent more time in wait states than in work states. We spent time waiting for approval. Waiting for others to finish their part so we could start (or finish) our part. Waiting for uninterrupted time to focus on finishing the work. Waiting for the right time of day/week/month. And while we waited, we started something new, because, you know, with resource utilization as a goal, you have to stay busy all the time.

But busyness does not equate to growth or improvement or value. Busyness often means just doing so many things at once that they all turn out crappy.

The clashing priorities became apparent while looking at the many long-standing branched code lines, but other than that, there was no clear visual of the impact of working on too many things at once. It’s hard to manage invisible work. With invisible work, we don’t notice the explicit reminders that our mental budget is already full. There is no time to simply think.

For example, how to define Lean? For that, I prefer Niklas Modig and Pär Åhlström’s definition. In their fantastic book This Is Lean: Resolving the Efficiency Paradox, they define Lean as, “a strategy of flow efficiency with key principles of just-in-time and visual management.”4

The answer is straightforward and accessible. It doesn’t cost you tons of money, and it doesn’t take geniuses or specialists. All it takes is a shift from haphazardly saying yes to everything to deliberately saying yes to only the most important thing at that time. And to do it visually.

The solution is to design and use a workflow system that does the following five things: Make work visible. Limit work-in-progress (WIP). Measure and manage the flow of work. Prioritize effectively (this one may be a challenge, but stay with me—I’ll show you how). Make adjustments based on learnings from feedback and metrics.

As Edwards Deming said, “A bad system will beat a good person every time.”5

This book is simultaneously an explanation, a how-to guide, and a business justification for using Lean, kanban, and flow methods to increase the speed and effectiveness of work.

Change is hard for humans. So, before we dive into workflow design, let’s investigate exactly what prevents you from getting your work done quickly in the first place. Once we scrutinize the crimes committed against your existing workload, we can proceed with the insight and awareness necessary to do something about it.

The five thieves of time that prevent you from getting work done include: Too Much Work-in-Progress (WIP)—Work that has started, but is not yet finished. Sometimes referred to as partially completed work. Unknown Dependencies—Something you weren’t aware of that needs to happen before you can finish. Unplanned Work—Interruptions that prevent you from finishing something or from stopping at a better breaking point. Conflicting Priorities—Projects and tasks that compete with each other. This is exacerbated when you are uncertain about what the most important thing is to do. Neglected Work—Partially completed work that sits idle on the bench.

In textbook terminology, too much work-in-progress (WIP) is when the demand on the team exceeds the capacity of the team—which is a rather boring way to say that our teams are drowning in work, often because their schedule is completely full.

Too much WIP matters for a number of reasons. It can result in many issues, including delayed delivery of value, increased costs, decreased quality, conflicting priorities, and irritable staff, to name a few.

Cycle time is the amount of elapsed time that a work item spends as work-in-progress. In addition, business value that could have been realized sooner gets delayed because of too much WIP. This is known as cost of delay. It’s a concept used to communicate value and urgency—a measure of the impact of time on the outcomes we want, such as customers buying our product this month instead of next month.

In general and for the purposes of this book, I define customers in two flavors: External customers: People outside your organization who buy or use your product or service. If they move on to greener pastures, you lose revenue—and

Internal customers: People inside your organization who ask you to do something or who consume your work.

WIP is a leading indicator of cycle time. The more items that are worked on at the same time, the more doors open up that allow dependencies and interruptions to creep in.

Most metrics measured in technology and business, such as lead time (the elapsed time it takes to complete a request from the time it was first requested), cycle time, and throughput (the number of things completed over a period of time), are trailing indicators. That is, we don’t know how long certain things will take something until those things are completed.

There is a relationship between the amount of WIP and cycle time—it’s called Little’s Law, where the average cycle time for finishing tasks is calculated as the ratio between WIP and throughput.

Harry F. Harlow, an American psychologist, says in Daniel Pink’s book Drive, “The joy is in the pursuit more than the realization. In the end, mastery attracts precisely because mastery eludes.”4 Mastery eludes because there is insufficient time to pursue something long enough and deep enough before being interrupted.

Kanban is Japanese for signal card—a card that, very simply, signals your availability to do some work. When you pull a card from the backlog onto the in-progress area of your kanban board, you commit to being available to do the work that the card represents.

If WIP limits are set appropriately, the system cannot become overloaded. The WIP limit is what allows you to say, “No, there is no capacity to take on more work right now.” Think of reducing WIP not as limiting but as liberating. The right amount of WIP is what enables us to maintain a healthy amount of work.

Let’s define dependency. From my perspective, when we talk about dependencies, three types emerge: Architecture (both software and hardware)—where change in one area can break another area (i.e., cause it to stop functioning) Expertise—where counsel or aid from a person with specific know-how is needed to do something Activity—Where progress cannot be made until an activity is complete

A similar problem occurs for changes outside of your control in the form of third-party vendors. Major cloud providers, like Amazon EC2, Microsoft Azure, and Google Compute Engine, provide service-level agreement policies that guarantee their customers 99.95% uptime. This equates to twenty-two minutes of allowable downtime per month. When your cloud provider is down, you are down, and Thief Unknown Dependency laughs at you.

Troy Magennis gave an enlightening talk on dependencies at the Agile 2015 Conference in Washington, D.C. Troy uses basic boolean logic (where all values are either true or false) to show that there is only ever one possible combination of inputs that result in an on-time delivery. Every time you remove one dependency, half of the total possible delay combinations are removed. If delivery requires every piece being complete, every dependency you remove doubles your chances of delivering on time.

You know Thief Unknown Dependency is stealing time from you when: Coordination needs are high, and project managers run around trying to get everyone aligned. People aren’t available when you need them. A change in one part of the code/outline/plan unexpectedly changes something else.

Small teams can move fast. Nothing beats a small, cohesive group of people who communicate and collaborate effectively. The problem occurs when dependencies span across teams, causing things to break.

Cross team communication is hard. When a bunch of two-pizza teams with lots of dependencies between them spend a lot of time coordinating to avoid stepping on each other’s code (due to the merging of the different teams’ code branches), the benefit of the small team diminishes. Smaller teams can increase integration costs. We like small teams because they can move fast. Just realize that by moving fast as an individual team, you may be paying the price of not moving very fast as a whole organization.

This is the problem with unplanned work—it sets back planned work. It increases uncertainty in the system and makes the system less predictable as a result.

But often, unplanned work comes in the form of unnecessary rework or expedited work requests.

Let me be clear, I am not suggesting all work should be preplanned. It is irrespon-sible (maybe even delusional), to believe that it’s possible to know everything up front while planning a complex project. Quite the contrary—we don’t know much about what we don’t yet know. Sometimes changes in direction are necessary, because new information emerges as we work to solve problems. A major value of the Agile movement is to encourage responding to change over following a plan.

The 2016 State of DevOps Report survey data show that high performers are able to spend 28% more time on planned work.1

Making work visible is a core component in combating thieves like Thief Unplanned Work and is also a core component of kanban,

Kanban cards live on kanban boards, and kanban boards answer questions like, “What is being worked on?” and “What state is the work in?” and “Who’s doing what?” All essential information is visible on the board, so you don’t have to chase down workers to ask them what is happening and you don’t have to wait for a politically sanitized weekly status report to get a glimpse of transparency.

Focus is a matter of deciding what things you’re not going to do. —John Carmack

In both cases, the common denominator is unclear priorities. Invisible work and invisible priorities hamper the alignment needed among engineers, project managers, and business people to make effective progress. Again, it all comes back to the necessity of making work visible for everyone.

However, for many, there is confusion on what real progress looks like. A team of engineers who look really busy but who are not completing project features are a red flag. Having a bunch of projects that are sitting at 90% complete does the company no good. Sales can’t sell a feature to a customer if the customer cannot access the feature; features are only valuable if customers can use them.

Thief Conflicting Priorities cackles with delight when people are uncertain or disagree on what to work on.

If people can’t prioritize effectively, they try to do too much at once and everything takes longer.

In some ways, aging software is much like an older car that needs regular oil changes and tune-ups to keep it functioning correctly. Old software in itself is not a problem. Old software that is not maintained and is not part of an automated build, test, and deploy process is a problem.

Maintenance of legacy systems is one of the most neglected types of work.

Like financial debt, technical debt incurs interest payments, which come in the form of extra effort required to fix software bugs and develop new features.