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.
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
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.
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.
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.