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
9 comments:
Scrum, done well --done effectively-- does no recognize "QA" or any other function. It is all one. Nothing about Scrum tells you NOT to swarm on single stories, in fact quite the opposite.
Kanban is nothing, except a word for "doing Scrum well". Stop making it into some magical thing.
Please.
@Tobias Maybe scrum implementations can be bent to 'one piece flow', but I see lots of other differences in our scrum and kanban implementations.
http://huitale.blogspot.com/2009/04/huitale-kanban.html
For instance..
.. we do not have any iterations (fixed length or not)
.. we have WIP limits (not saying scrum could not have those)
.. we do planning on demand
.. we release feature by feature instead "end of iteration"
If that is "doing scrum well", then we have plenty of confusing books, seminars, certification programs etc for the public consumption. :/
I have thought that scrum and kanban are just different tools that you can mix and match based on your context.
Tobias,
Thanks for visiting! Missed bumping into you at Agile 2009 this year.
I realize that some teams have in fact gotten to nearly cross-functional people, but most teams (in my experience) have not. In retrospect, I think I've probably named this series poorly. I'm not suggesting that Kanban replaces Scrum or that Scrum is a bad thing. I'm a big fan of Scrum. But it does have its warts.
As Marko points out, there are in fact quite a few differences between textbook Scrum and textbook Kanban.
Some of the best resources for comparing and contrasting Scrum and Kanban are the following by Henrik Kniberg. While he uses the phrase "Kanban vs Scrum" he doesn't mean it in a competitive way.
Here's Henrik's cartoon intro to Kanban a short blog post on Kanban vs Scrum, and a 40 page pdf on Kanban vs Scrum. They are all excellent with lots of great illustrations throughout.
I must admit, this seems mostly like window dressing and hyping problems that 1) are pretty limited in scrum and 2) are just essential problems in good QA.
You can't test until a feature is done or enough of it is done to start testing. That's just life. You can write test plans and have 1-on-1's with developers to make sure QA understands and has good coverage.
In any company I've been in that's done scrum, QA runs on a separate scrum cycle, typically one iteration back from current development. Whatever QA finds gets bumped to the top of Dev's current iteration. If QA finds a ton of problems, then you cancel the iteration and replan, just like scrum says, or continue so you get a feel for how much bug-fixing is likely to suck up from future iterations.
Kanban seems like an awfully fancy word for more or less common sense handling of the fact you can't finish QA'ing something until it's written.
Hi Chris,
Thanks for commenting.
It pains me to point this out, but QA offset from development by an iteration is an extreme example of exactly what I'm talking about. It is a classic no-no. If the QA folks can't test until the end of the iteration, then you are not doing one piece flow, you don't have a whole team, you don't have a shippable increment of work at the end of the iteration, and you are not getting the full value of Scrum.
I agree that you can't test until a feature is done, but the whole idea here is that you break things down into small user stories, get that small story implemented and then immediately test it, not test it in the next iteration.
Happy to discuss this further,
Damon
Hi, and thank you for this blog. I find this series interesting, but I get a little confused about this one piece flow description. As far as I can read the figure above, you have a "three piece flow", because the team is always working on three user stories. My immediate interpretation of the term "one piece flow" would be that the whole team works on only one user story until it is done, then starts on the next. With this three piece flow, I fear that responsibility will be scattered. What do you think about this?
Hi Otto,
Thanks for your kind words.
Good point on the apparent discrepancy between the "one" in one piece flow and the diagram which shows three stories flowing at a time. The one in one piece flow is the target of the concept, but doesn't actually mean that you only do one thing at a time. The idea is that you think of everything you do in terms of the concept, but then translate that thinking to how it would work for your team.
The primary idea of one piece flow is that instead of doing all of the development for all of the work you need to do for a release, then write all of the tests, then do all of the testing as in waterfall, you do each story in rapid succession.
If you have a small team and the whole team can in fact work effectively on a single largish story, then you would end up doing one story at a time. If you have a larger team and small stories, it might be impossible to have the whole team work on just one story at a time.
The result of combining one piece flow with a team that can work on more than one story at a time is that you get as close to one story as you can, but don't limit yourself to one story. For instance, if you have 9 equal sized stories for an iteration and the team can take on 3 stories at the same time without multi-tasking, then you would do 3 stories at a time, but not 4.
From the perspective of any one story, it would rapidly progress from initiation to "ready to ship" without any interruptions. That is, the people working on it would not be working on other stories at the same time. An example of not following one-piece-flow in this example would be having 4 or more stories in progress at a time with an extreme example being that all 9 stories end up being in-progress at the same time.
If by "responsibility would be scattered" you are referring to multi-tasking, I agree that you should not multi-task. Do only as many stories at a time that you can do without team members working on multiple stories at a time. If you meant something else, could you elaborate?
Thanks again for the question!
Damon
Hi Damon, and thank you for elaborating. No, that is not what I meant about the responsibility. What I mean is that if one developer gets a user story that is a bit more complicated than what the developer is capable of handling, and the developer is of the passive type that wants to try to solve it himselv, or wait to see if something happens, the user story will not be done for a long time. The other developers are busy solving their own stories and don't care about the developer that is stuck in problems.
I have seen this happen some times, and I am wondering if one reason may be that we allow too many pieces to be in flow at the same time, or that we allow this one developer to work alone for so long time.
Hi Otto,
I see. Ok, here are my thoughts on that:
1) Perhaps the user stories are too large. IMHO, if a user story is bigger than 2 story points and it can be broken down into multiple stories of 1 point or larger that each have customer value by themselves, then it should be broken down.
2) For an individual developer, perhaps there is a collaboration or motivation issue that needs to be addressed which is independent of the process you are using.
3) Pair programming may be appropriate.
4) Are people choosing for themselves which stories they are working on? If not, that might be a root cause. If they are self-assigning, are folks taking on issues that they don't feel they can do or that they believe they can do but actually they can't?
In any case, the lower your work in progress, the simpler everything becomes and the less that can hide. Even though Scrum is wonderful for uncovering problems that traditional development would hide, problems can still hide out within the iteration. One piece flow and limiting work and progress go a long way to turning up the volume on the "there's no place for problems to hide" aspect of Scrum.
Post a Comment