One Piece Flow -- Transitioning from Scrum to Kanban Part II

If you have been doing Scrum for a while, and doing it well, it is 99% certain that you are frequently practicing something called “one piece flow”. One piece flow is a concept from Lean and is the key to succeeding with Scrum. Doing it well also happens to be one of the requirements for successfully transitioning from Scrum to Kanban.

There are four main concepts in “one piece flow.” Each story is done as if it was the only thing in the release, each aspect of developing a user story happens in rapid succession, there is as much done in parallel as possible, and each team member focuses on a single user story at a time. The result of one piece flow is that the time between when the team first starts working on a user story and when they can ship it fully developed, tested, and documented is very short. The timeframe is generally on the order of a week at most and usually days.

In one piece flow, when development starts on a story, QA should be creating test cases for that story (story testing) at the same time. When development is done, QA should then automate the test cases and make sure they all pass. At the same time, the user documentation is written. One last step that must be completed prior to considering the story done is that all of the artifacts connected to that story such as source code changes, documentation updates, new test cases, etc must be integrated into the source code mainline as part of continuous integration.

In the following diagram, there are 20 stories done over the course of three iterations. There are three developers on the team and each takes on one story at a time. In the diagram, the whole team is doing one piece flow well and you can see how the specifying (S), designing (D), coding (C), writing of tests (W), integrating (I), and testing (T) is evenly spread out but also clumped into stories.

So, from the perspective of a story, it is started, and completely finished in a short period of time. QA should not be waiting until all stories are done. Conversely, developers should not have lots of stories in progress that all finish together which keeps QA from getting involved.

You will know that you are succeeding at one piece flow when stories are being started and then are completely ready to go on an individual basis within days with all documentation written and all unit and story tests written, automated, and passing.

Once every QA person is actively engaged in a story that is part of an iteration, you are “in the flow.” Everybody is now flowing smoothly from story to story. Unfortunately, Scrum has a bad habit of disrupting one piece flow on a regular basis. As soon as one of the developers finishes their work for the last story assigned to them for the iteration you are no longer “in the flow.”

For more about how Scrum disrupts one piece flow, read about Bumping Into Scrum’s Iteration Boundaries.

Next: Scrum and Kanban -- Like Chocolate and Peanut Butter