{"id":11935,"date":"2014-05-21T14:31:09","date_gmt":"2014-05-21T19:31:09","guid":{"rendered":"https:\/\/blog.planview.com\/?p=11935"},"modified":"2020-01-31T14:38:15","modified_gmt":"2020-01-31T20:38:15","slug":"what-is-flow-and-why-it-matters","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/what-is-flow-and-why-it-matters\/","title":{"rendered":"What is Flow and Why it Matters"},"content":{"rendered":"

\"\"<\/p>\n

Flow means to \u201cmove along in a steady, continuous stream.\u201d In knowledge work, the ability to visualize and manage your flow is essential to achieving faster and more consistent delivery. It allows you to understand your capacity, easily identify problems and improve that flow.<\/p>\n

In a system designed to manage the flow of tangible deliverables, such as a car assembly line, it\u2019s relatively easy to see where bottlenecks are forming and slowing down progress. For knowledge work, flow problems aren\u2019t quite as easy to see. This is a major reason we use\u00a0Kanban boards<\/a>\u00a0to visualize our work.<\/p>\n

But what exactly is flow?<\/h3>\n

Let\u2019s use an example we\u2019re all familiar with: the security screening checkpoint at an airport. Like a Kanban board, airport security is a system. People flow through the system, from step to step, beginning with reviewing their ID and boarding pass, and ending with walking away from the checkpoint toward their departing flight.<\/p>\n

The system\u2019s capacity, or the number of people that can be processed effectively, can be affected by many factors \u2014 the number of available security agents, how many lanes are open, what technologies are used for the screening, etc.<\/p>\n

When the number of people passing through the checkpoint is low compared to the system\u2019s capacity, people flow through with relative ease. A pause to check IDs, walk to the conveyer belt, remove belt and shoes, place your bag on the belt, walk through the scanner, pick up your bag, put on your shoes and belt, and then you\u2019re on your way.<\/p>\n

Lots of things can interrupt that flow.<\/strong>\u00a0Perhaps someone takes a long time getting their shoes and belt off. Or someone sets off the metal detector and has to go back, empty his pockets and try again. Or someone\u2019s bag needs to be searched. Or someone requires additional assistance getting through the line.<\/p>\n

When there are relatively few people passing through the checkpoint, these interruptions in flow cause only minor delays. But when the system is nearing its capacity, a small interruption in flow is magnified many times over. The more people moving through the system, the more chances there are for something to take longer than normal, causing a ripple effect.<\/p>\n

Flow in Knowledge Work<\/h3>\n

Now let\u2019s consider how flow applies to knowledge work, using a software development team as an example. Work flows through the system, starting from when a customer requests a product feature and exiting the system when it\u2019s delivered to the customer and is actually working and creating value. Our software development system has a capacity, based on how many developers, managers\/analysts, testers, designers and other roles filled by people we have available.<\/p>\n

There\u2019s usually a fair amount of variability in the complexity and difficulty of the work. Some things take longer to design, some are harder to build and others take more time to test. As work flows through the system, there are interruptions in flow, like tests failing and rework being done, or work sitting and waiting to be tested long after it is complete, or design work that takes several iterations to get it right.<\/p>\n

If the system is operating at less than its capacity for work moving at \u201cnormal\u201d speed, then these interruptions may not have a massive effect on the rate at which work is delivered. But if the system is running at near its capacity, any variability causes a cascading effect on flow. Even worse problems can occur when you start having flow problems at one point in the system and continue loading the system down with more and more work.<\/p>\n

Identifying Flow Problems in Knowledge Work<\/h3>\n

Flow problems at the airport are easy to see. When you see a line that disappears around a corner, you know you\u2019re going to have a long wait and most of it will be spent standing still.\u00a0For knowledge work, flow problems aren\u2019t quite as easy to see. This is a major reason we use Kanban boards to visualize our work.<\/p>\n

When we map the steps in our process onto the board, cards represent the work that\u2019s flowing through the system. When large bunches of cards form in an area of the board, it clearly indicates problems with work getting past that point in the process. When there are large empty areas of the board, we can also surmise that somehow work is getting stuck before that part of the process and not coming through in a nice, smooth flow.<\/p>\n

\"\"<\/p>\n

In this example, work is getting stuck in Design and not flowing steadily through to the Development part of the process.<\/p>\n

There are two major ways we can influence flow: managing queues and limiting work in process.<\/p>\n

Influence\u00a0Flow by Managing\u00a0Queues<\/h3>\n

In the security checkpoint example, what we often think of as one long line is really a series of queues. First, you wait in a queue to have the security agent check your ID and boarding pass. After that activity is performed, you wait in another queue for the plastic bins, where you can put your shoes and belt and pocket change.<\/p>\n

After emptying your pockets you place your bag on the conveyor, along with the plastic bins, and wait until you see them move into the X-ray \u2014 that\u2019s queue #3, if you\u2019re counting. Now you wait in a (usually short) queue to go through the metal detector or millimeter wave detector.<\/p>\n

And finally, you wait on the other side to pick up your bag and get dressed. That\u2019s five queues. The first two are usually the longest wait, but delays in the last few steps can have ripple effects all the way back to the beginning of the line.<\/p>\n

Knowledge work has queues, as well. On a software development team, design work happens and then sits in a queue, waiting for developers to be available to start the work. Once development is done, work may sit in another queue while waiting for some additional testing. After testing is complete, it may wait in another queue to be deployed to production.<\/p>\n

Real-world examples are often much more full of queues, especially if work has to be handed off to someone in a different department or on a different team to perform the next action in the flow of work. Any time there\u2019s a handoff of work from one person to another, there\u2019s usually a queue.<\/p>\n

So, to visualize just how much of our work is in queues, you need to design your Kanban board to explicitly call out those queues.<\/p>\n

\"\"<\/p>\n

In the board above, the \u201cDone\u201d column is a queue. When development work is done, for example, it\u2019s placed in the \u201cDone\u201d queue so QA testers know to pull their next work item from this queue, when they have capacity.<\/p>\n

Now that we can see the queues on the board, we can start to see their effects. If work enters the \u201cDevelopment:Done\u201d queue and sits there for several days waiting for testing, several things can happen. First, additional work may be added to the queue during that time, and the size of the queue will continue to grow.<\/p>\n

If errors are found by the testing team, and the work has to come back to development to be fixed, the cost of context-switching from whatever new work they are doing to going back and fixing broken code from a week ago can be very high. This causes at least two interruptions in flow, where the work with the defect goes backwards and the current work in development is paused while the defects are corrected.<\/p>\n

Influence Flow by Limiting Work In Process (WIP)<\/h3>\n

Once you begin to see the effect of queues, you can start explicitly limiting the size of queues to keep the work flowing smoothly. This may mean, at times, that a particular person in the system sits idle for a short period of time, rather than piling more work into the queue. Through the lens of systems thinking, idle time is preferable to loading the system with more work that slows down everything else.<\/p>\n

\u201cBut wait!\u201d you say. \u201cHow can I possibly\u00a0limit my work in process<\/a>? The project schedules, the customer demand, the growing backlog \u2014 these things don\u2019t just stop because I say so. At the airport, the staff can\u2019t just tell people not to get in line because they\u2019re \u2018limiting their WIP.\u2019\u201d<\/p>\n

Actually, they can. And they already are.<\/p>\n

At the airport, most of your queue time is spent in those first two queues, before you arrive at the conveyor belt and the scanner. They\u2019re intentionally keeping those queues long and only allowing a limited number of people through the final stages so the final steps flow smoothly. They also have lots of security agents at those final stages, ushering you along, making sure that the flow stays as smooth as possible. We can do the same with our teams.<\/p>\n

\"\"<\/p>\n

Improve Your Flow<\/h3>\n

By limiting not only the amount of work we start, but also the work we commit to doing, we can improve our flow and achieve better quality, better throughput and more consistency. This may mean there\u2019s a longer backlog or request queue, but the benefits of faster and more consistent delivery will allow you to prove that working on fewer things at once actually benefits your customers more than saying \u201cwe\u2019ve started on it\u201d and taking much longer to deliver after making that commitment.<\/p>\n

Recommended Readings<\/h3>\n