In the past year I watched the Amazon series Patriot. From a plot perspective, the show is about an American agent who takes on a “non-official cover” with a pipe company to prevent a nuclear threat. At a deeper level, the show is about the complications of flow, mentioned several times as the simplicity of “getting something from Point A to Point B”. The company he works for is a global supplier of pipe and fluid delivery systems; think oilfields, Schlumberger or Halliburton. There are some truly stunning monologues of made-up technical jargon. Kurtwood Smith (That 70’s Show, RoboCop) delivers some incredible line readings showing his level of passion for his profession in dialog that borders on a psychedelic-tinged Star Trek techno-babble as written by Aaron Sorkin.

As it turns out, Smith’s character Leslie Claret literally “wrote the book” on flow. I cackled when the book came up, as I’m actually reading the real book The Principles of Product Development Flow.

As the story in Patriot unfolds, the small and large scale patterns that affect flow come into play — complexities, coincidences, similarities, parallels, counter agendas, competition, enemy action, accidents, misunderstandings, miscommunications, poor timing, distrust, misaligned incentives and more. From an Operations Management and Scrum Agile perspective, these are a part of the normal understanding of optimizing systems.

The simplistic view of scientific management that is still a pervasive leftover from Taylorism is a simple input / output model. Speed is good. More work hours are better than less. Working harder is good. These implicit premises are rarely stated out loud with a full explanation of the assumptions and expectations. The general assumption is that increasing some input (hours worked, workers, speed) the system will increase a desired output (tires, iPhones, lines of code).

The modern history of scientific management from WWII till today has taught us that speed itself is not guaranteed to be correlated with good outcomes. In fact, speed itself can actually reduce outputs. What the sophisticated OM or Agile view has taught us is that overall flow of the system is the primary concern. When the smaller conditions are aligned in order to maximize total flow , it may actually turn out that one or more small inputs are actually under-utilized, or performing below their maximum output. The revolution from Project to Product view tells us that Value is the goal, not maximizing inputs that the customer has no interest in paying for.

With this view as background, I found the following article fascinating.

The World’s Best Exchange Rate: Japan’s Secret to Relay Success

The article details how the Japanese team was constrained by the top speeds of it’s individual runners. So they _ focused on everything else _. As the covert agent in Patriot learns, there are many complications in a process. Speed is only one element of a complex race like the relay. Please read the articles for the fascinating details.

When I shared this article with some online communities, my friend David Lormor (CTO, Wyndy. Find, book, and pay local college student sitters) shared this anecdote:

“I had a similar experience in high school. I was the fifth-fastest kid on my track team, but got promoted to the relay when our fastest runner got suspended due to grade requirements. We practiced our butts off — focusing on many of the same non-speed related “fundamentals” listed in that article. As a result, we took 1st place in all the races we competed in (I believe there were six).

The day before district finals, our “top runner” (who was probably a half-second faster than me in the 100 meter) came off of academic suspension and replaced me on the team. He didn’t have time to hone those same fundamentals with the team beforehand, and we ended up coming in 3rd in that race despite having faster individuals on the team. While we’ll never know how we’d have fared if I had stayed in the team for that race, the team all agreed that the last minute change was a contributing factor to losing that race.”

I love stories like these. Many people believe Scrum is just a way to schedule meetings, or that it means demanding work be done in two weeks. Using it from that limited perspective, it’s only as innovative as a grocery list. Maximizing speed, or “full utilization” are just inputs. These are local optima.

Scrum is more like learning chemistry so you know how to cook.

Putting the fastest runner in is exactly like the Taylorism obsessions of “working faster”, “skip the testing”, or my favorite “everyone staying busy”.

Understanding the difference in the paradigms of Local Optima versus Global Optimum is a fundamental step to maximizing the total flow of Value.