The Case for One-Piece Flow (Part 1/3)

January 5, 2009 — Posted by Guy Beaver

Part 1: Stop starting stuff and start finishing stuff[1]

In this 3-part series, I'll cover how too much work-in-process leads to hidden waste at the individual, release, and enterprise levels.

I often ask people what comes to mind when they hear "Lean" mentioned in business context. The most common answer is "Eliminate Waste". In organizations that transition to Lean, waste is often made visible by minimizing the number of projects and products underway, and focusing on completing high-value work as quickly as possible. In doing so, visibility is brought to any impediments to completing work, often in the form of delays due to handoffs and rework due to poor quality. The counter-intuitive result of this insight is that by focusing on fewer tasks, activities, projects, etc, organizational productivity actually goes up. The common goal to implement this is often referred to in Lean circles as "one-piece flow".

There is an illusion underway in large corporate enterprises. It manifests itself in job descriptions under must-haves: "…ability to multi-task." When this skill is put at a premium, it can be indicative of an organization that is challenged with the ability to focus. It is often accompanied by an illusion that the best way to ensure high productivity is to keep people busy. Unfortunately, it hides what people are "busy" doing--typically working on almost the most important tasks related to achieving the highest business value effort.

Perhaps windowing operating systems made it ok to start lots of stuff without finishing. Opening another window to start another task while waiting on one to finish gives the individual illusion that "I'm productive because I'm keeping busy". How many windows do you have open as you read this?

A very good article by Christine Rosen that recently appeared in "The New Atlantis" inspired this post. It clearly explains the myths of multitasking at the individual level, and this post uses Lean thinking to extend the idea up through an enterprise organization.

"When we talk about multitasking, we are really talking about attention: the art of paying attention, the ability to shift our attention, and, more broadly, to exercise judgment about what objects are worthy of our attention." [2]

With no visibility on priority, we create a culture where multi-tasking is necessary. Batching up large volumes of requirements for project work makes prioritization an afterthought, and motivates us to create large up-front designs, maximizing the amount of work-in-process (WIP).

One belief system seems to be that an organization can be more Agile by having Lots of projects in flight, and then close on the most relevant ones as market conditions change. But what is the downside to this? We hide wasteful activities and delays, and we must move resources around (task-shifting) in order to pull this off. In fact, in the matrix resource environments, we are forced to assign our people to multiple projects (since we have so many in flight). This is also complicated by our organizational structure (silos of subject matter experts [3] who must devote time to multiple projects in flight), and this creates the common pattern that we call "The Hand-off Organization" where projects are completed by breaking down large batches of requirements into system function areas, have the teams work sequential (handing off in phases) or else work in parallel and integrate late…

My 10-year-old daughter is in the 5th grade and that seems to be the year when the amount of homework is noticeably increased. She's often challenged with multiple projects and homework tasks, and occasionally looks to me for organizational help. On a recent weekend, she had two projects due on Monday, and I observed her activities in trying to get them both done. I offered some guidance on project A, and I saw with great satisfaction, long periods of engaged, focused activity, but my satisfaction was diminished when I realized she was working on both projects at the same time. Her approach was to work on project A until she got blocked or tired, and then switched to project B until she got blocked or tired. As it got later, her frustration grew, as she realized there might not be enough "awake" time to finish both. My recommendation was to stop working on Project B, and instead focus all her efforts on completing Project A.

"But Daddy, that doesn't make sense," she insisted. "Both projects are due, so I should spend equal amounts of time on both."

"But what if there's not enough time to do both," I replied. "Wouldn't you rather finish one project with high quality, and then turn the second one in later? It will work better if you decide which project is more important, and focus on completing it first, especially since you can't seem to gauge how much time it will take to complete both."

She thought about these statements for a while, and decided project A was indeed a much more significant part of her grade, and proceeded to focus on getting it done (which she did). In the end, it turned out project B wasn't even due the next day, so she lucked into picking the correct project.

What lessons can we learn from this, especially at the enterprise level?

In part 2, I'll cover how organizational focus and visual controls that limit work-in-process (WIP) can make large enterprises much more productive and easier to manage.


  1. Quote from David Anderson
  2. Christine Rosen "The Myth of Multitasking", The New Atlantis
  3. Guy Beaver, "Knocking Down Silos", Agile Journal
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Guy Beaver

Guy Beaver was VP of Enterprise Engagements and a Senior Consultant. He is a seasoned technology executive known for building Lean organizations that are driven by business priorities. With 30+ years experience in Financial Services, Aerospace, Health Care and eCommerce, his technology accomplishments include managing enterprise web development and delivery for world class transaction systems (16 Million users), large data center transitions, and SaaS operational excellence utilizing Lean IT practices. He is skilled at organizational change and is the co-author of Lean-Agile Software Development: Achieving Enterprise Agility.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban