Flow Is For Sissies

Flow: Nice Work If You Can Get It

A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects.

Looked like great place to apply kanban

These sounded like great problems to solve with the help of the Kanban Method and I was eager to get started. This thinking, however, set us on an educational but somewhat fruitless path. The results weren’t what we expected.

Applied the Kanban Method

We mapped out the value stream, modeled it appropriately in a kanban, and used the kanban system for a while to get visibility into the process and gain understanding. That was a success.

The Kanban Method helped us confirm that each analysis, development and QA step in their value stream took little value-added time. Nothing unusual or out of the ordinary was happening in any of the stages. We weren’t worried about vacations or someone getting hit by a bus. There were no bottlenecks.

The kanban helped us discuss Lean concepts and apply them to our situation.

Got some benefits but nothing real or substantial – no WIP reduction or lead time reduction

Our initial goal was to visualize the process, reduce WIP, simplify prioritization, and look for improvement in lead-time, especially through reduction in delay. We got the visualization and felt we didn’t need as much as we got. We more fully understood the amount of WIP, but limiting it would not enable any additional swarming. Perhaps we got the simplified prioritization, but that came more from understanding the system and lean principles than from the Kanban Method or the kanban (the board) itself.

We didn’t achieve the lead-time reduction. We couldn’t. The delay was outside of our control.

Outside of our control

The root cause was that the team was waiting for external IT shops to complete their part of the equation. It took several rounds of interactions with multiple people outside our company to complete a job. After our team did a little processing, the work item went to sleep in a blocked state and (maybe, someday) would be woken up by the external IT shop if they should decide to respond to our pleading.

Our group would benefit greatly from setting up EDI with their numerous business partners, but the other companies had no incentive to do their part of the connection. (Perhaps you are thinking that we needed to give them a financial incentive. We explored many ideas that just didn’t fit into our sales or business model. Changing the business model was another avenue of exploration but let’s save that for another post.) The times that the external group did respond, it was likely because they had some slack time and/or thought the task was interesting or challenging.

It didn’t matter anyway

It really didn’t matter anyway.

Every integration with a 3rd party is of high value to our business — worth the cost of abandonment of work on a large percentage of opportunities. Each successful company pushed through the process is so valuable that it more than covers the costs incurred with those that fail.

Therefore, it was more important to have many “at bats” or “sales calls” than it was to have a short lead-time. Well, maybe ‘important’ isn’t the right word. It’s very important to complete work quickly, but in this case, it’s achievable to have more sales calls. We couldn’t improve our lead-time no matter how important that is.

A better way to look at it is we had extra capacity and used that to push more companies through the process (or, to create demand). We reached equilibrium where a hit suspends additional tries at-bat, and more at-bats ultimately increase hits. Work with an engaged external IT guy competes with making more sales calls. More sales calls yield additional willing external partners.

Yes, that will build up significant WIP over time. Whether we control WIP or not, many of the external companies aren’t going to cooperate and finish the process. We will abandon a lot of work. We try hard to finish whatever we start, but we can’t tell which work will be abandoned before we start.

Ultimately, we considered the cost of being a low priority and deemed it worth it.

Lesson learned

Until this experience, I didn’t fully understand the lean principle of Value trumping Flow and Waste Reduction, a lean principle. I was aware of it, but I only thought I understood it. I knew that sometimes we should accept uneven flow if it helps us get value, but I was thinking that would only ever be exception cases. I was thinking that the norm should be to optimize smooth flow. The implication I had missed is that smooth flow isn’t always a general prerequisite for value. Considerable waste and huge WIP and horrible flow might just get you the most value.

(Anyone can get value if you have flow. This kind of environment isn’t for sissies.)

Finally, I began to think about this situation with the EDI team as having options, rather than as a great place to apply the Kanban Method or Lean Principles. I began to see the options in the system trumping the considerable waste, huge WIP and horrible flow.

The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.

Somewhere in the last decade, I had a similar revelation about eXtreme Programming.

With every shiny new hammer, I find more things that look like nails.