← All writing

My Thoughts on One Piece Flow

I am a big believer in a person performing the best when they have full focus on a single task at hand. In my personal experience, when I have multiple tasks ongoing at once, I don’t deliver to the best of my ability on any of them. As an Engineer, I believe the single biggest impact to being able to achieve high quality code is context switching and not having full laser-sharp focus on the job at hand.

Little’s Law

Little’s law is a theorem that suggests working on multiple tasks simultaneously will increase the time spent in total. It highlights a fundamental relationship between the number of items you are actively working on and how long it takes to complete a given task. In essence, the more work you have in progress, the less you release, which increases the cycle time and that decreases the amount of work done in a sprint.

Using this theorem and averages, we can apply it to calculate a definitive equation on Cycle Time:

Average Cycle Time = Average Work in Progress / Average Throughput

Analogy

If you had 20 customers / hour in a coffee shop and a customer takes 15 minutes in the shop, then, in theory, on average of 5 customers are in the shop at any given time.

Strict One Piece Flow Process

An example process of a team working in a strict one piece flow manner is:

  1. Taking one feature from the backlog
  2. Completing analysis
  3. Moving directly to development
  4. Conducting immediate testing
  5. Deploying to production
  6. Only then starting the next feature

My Personal Opinion

My two pence on this is that I want my engineers to be strict with their own process ensuring that they follow a one piece flow mindset, taking on one task at a time, and, until it’s completed, focusing solely on that, ensuring that they only ever have one work item active.

I am a huge advocate of pair programming and using the mob programming techniques, but instead, leaving it in my engineers’ capable hands to choose and decide when’s best to use it as a team.

My job is to push best practices on the team, challenge fixed mindsets and provide a path to achieve a better cycle and lead time, not dictate ways of working to my team that are masters of their craft.