One-piece flow

lean
Posted by Xiao Li

24 September 2015

Recently, I started to imagine a one-piece flow in software delivery/development:

  1. The team should be small, maybe two to eight people.
  2. It starts with everyone working on looking for one story that has value-adding work.
    1. It can be value-adding work to end user.
    2. Or be value-adding work to our goal/vision.
  3. We analyze the story together:
    1. We can start with a group discussion about what we want to do or achieve.
    2. We draw our ideas.
    3. We have agreement about the following questions:
      1. Outcome: what we will build, what we can learn.
      2. How we measure the outcome.
    4. We work out how everyone can start work on the story immediately.
    5. We may validate our ideas by building various prototypes with different tools.
  4. We develop the story together.
    1. We can start user-testing to get early feedbacks.
    2. We write code and deliver changes.
    3. We have a regular standup meeting to revisit what we’re doing and what’s next.
    4. We start exploring test once we have changes delivered.
    5. We start marketing the new feature.
    6. We look for users to be early adopters.
    7. We may still carry on the analysis work to make sure we are on right track when we get new information.
  5. We test the story together during development.
  6. We don’t do anything that does not help deliver the story unless it’s not avoidable.
  7. There are no queues for work to be in ready status
    1. No ready for development
    2. No ready for test
    3. No ready for deployment/release
  8. There are backlogs or something similar, but we have it to help us focusing on the story we are working on.
  9. We have retrospective regularly.

It seems not really a one-piece flow: it actually is one piece in the flow. It seems hard to have everyone working on one piece of value-adding work. What if we have too many people in the team? What can we do when developers are still working on code? These are all hard questions and I don’t have right answers. The team needs to address these questions. Then why do I want to try this approach? It’s all about eliminating non-value-adding waste during software delivery/development process.

A one-piece flow needs to be designed to bring problems and waste to the surface. It is not designed to keep everyone busy or working. Instead, everyone in the team needs to look for work that needs to be done for delivering the story.

From what I understand, this is how The Toyota Way works.


comments powered by Disqus