If you have a long term goal to gradually increase the productivity of you software development process you may want to dedicate your people to separated work streams and use more than one Class of Service. This will maximize your learning and makes process improvements easier.
Using a kanban system for your software development system is a very effective way to balance your demand to flow. Limiting your Work-In-Process(WIP) will help you understand and learn your process capabilities. The lower the WIP, the faster you will find where in the process your need to make improvements.
Context
Do you have a reasonably stable process over time? Do you have a process that has two strongly separated steps following each other? The second step has more than one person working in it? It is very hard to eliminate the separate steps and create a process without hand-offs?
Then you may want to consider going from a single shared work stream to separate work streams in your process.
Shared work stream
|
Separate work streams
|
Shared work stream
A shared work stream is were you load balance between two or more people in the same step. Tester 1 can pull work from both Developer 1 and 2. Tester 2 can pull work from both Developer 1 and 2 as well.
The benefits are quite obvious, when Tester 1 or 2 are ready to pull work they can pull from whatever work is available. You can probably lower your WIP as you will share a common work queue and this will bring down your lead times. This is a flexible solution that will allow you to work around potential problems in the process and you will have higher productivity in the shorter term.
But.
Load balancing in this way will make it harder to detect your process problems as variation in your process will rise and the problems may get hidden in the load balancing in the shared work stream.
Separate work streams
When using separate work streams you will not load balance between people. Tester 1 can only pull work from Developer 1. Tester 2 can only pull work from Developer 2.
It sound very inflexible. If the work doesn’t flow people will get idle. People don’t like to be idle. What can possibly be the benefits of this approach?
Using separate work streams will have a similar effect as WIP limits. When you lower WIP problems in your process will be visible faster. Separate streams will also show your process problems much faster. It will be much easier to see where the cause of a problem occurs. You will be able to understand faster what to improve in your process. As you improve over time the process will stabilize and the process will be more productive.
Using Classes of Service
But what will the people do when they get idle due to the variability in the process?
One option is to have your over capacity, people that’s idle, work on process improvement work or lower priority work. Use a set of different Classes of Service for your work. When people gets idle in their work streams have them work on the lower priority work and process improvements. When the standard work is yet available move back to the standard work as fast as possible. This will give people something to do as they wait for work.
Conclusion
If you have a long term goal to gradually improve your software process capability, understanding what works and what’s not, is essential. Using a pull system like a kanban system is a great start. Lowering your WIP is the first step and then creating separate work streams may be your next step if you want to maximize your understanding and learning.
Use different Classes of Service when people gets idle instead of load balancing.
Much of this is inspired by Mike Rother’s book Toyota Kata and chapter 5 in particular.
Hakan Forss's Blog 
Hi Håkan,
This is an interesting post and a perspective. Definitely got me thinking, and I look forward to thinking more deeply about it and hearing what others think too. That said, here are some of the initial thoughts that popped into my head as I read your post. It made me think about specialists vs generalists vs generalizing specialists; about context switching vs task switching; about properly partitioning, as in separation of concerns; and lastly, how a beginning developer uses no abstraction, an intermediate one use too much abstraction, and an experienced advanced one uses only the level of abstraction needed to solve his problem.
I’m not sure this is comparable to the context you illustrate (if I missed the point completely, my apologies up front), but in the early years of applying lean-agile principles and practices (including limiting WIP), we went from fixed work streams and fixed cross-functional teams (no load balancing, no cross work stream knowledge pollination), to fixed work streams and frequent total dynamic cross-functional teams creation (a maximum load balancing approach I’d say, but no knowledge transfer consistency), to fixed work streams and mostly stable teams (which allowed for load balancing when it was beneficial, provided knowledge transfer consistency within a work stream, provided some beneficial knowledge transfer between work streams, and provided some capacity, dare I say “slack”, to work on overall system process improvement).
Reminds me of the three bears story, the first bed was too hard, the second was too soft, and the third was just right :>)
Take care,
Frank
Hi Frank,
Great that I got you thinking, that is exactly what Mike Rother’s book Toyota Kata did for me!
I’m not sure if I understand what you are saying but is it your opinion that fixed work streams and mostly stable teams that do load balancing is just the right way?
Are you also saying that too much abstraction are used in the proposed way organizing the work and process improvement?
/ Håkan
Good post! Love the thoughts coming from the Toyota Kata book. It’s a pleasure to have Tweeted back and forth knocking out some of these great ideas, and figuring where they fit. Thanks for putting this together.
Thank you Steven for you conversations on Twitter and your own post on the subjec, Do Teams of Cross Functional Individuals Hide Dysfunctions? http://blog.nwcadence.com/2011/09/do-teams-of-cross-functional-individuals-hide-dysfunctions/
Hi Håkan,
Sorry about the confusion, I shouldn’t try to comment so early in the morning my time :>)
Re: Q1, and Q2 in your reply, I think (hope) I did a better job of my example on the comment I left on Steven’s post, I was a bit more awake (thanks for the link BTW). Definitely not implying my example is “the right way” but one that worked for me in one context at a time of process maturity that we were at (acknowledging over time, improvements occur).
In short, Rother’s point should make one think about how they utilize cross-functionally trained individuals or teams. That said, for the contexts I’ve worked in, I think the “sweet spot” has been more often somewhere in between, not at the extremes, but now I’ll be thinking about how much either way a bit more because of your post and Steven’s post :>)
Take care,
Frank