Maximize learning using Separated Work Streams and Class of Service

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 Better for shorter term productivity More difficult to understand causes of problems Takes longer to find process constrain

Separate work streams Easier to understand causes of problems Better for longer term productivity Shows process constraint faster

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.

Advertisement

Tutorial day at LSSC11–Implementing Continuous Flow

Today, Tuesday the 3^rd of May 2011, was tutorial day at Lean Software and Systems Conference 2011. I had decided to attend the tutorial Implement Continuous Flow by Joshua Kerievsky and John Goodsen.

I was really looking forward to this tutorial and had high hopes for it. But I’m sorry to say that it did not live up to my expectations. It was way to focused on software practices for me. I was expecting much more on how to make an organization transition to a continuous flow approach. In hind sight this was my mistake as I didn’t look at the speakers backgrounds.

I actually left the tutorial right after lunch as I found out that the tools show case track had been moved to Wednesday and I needed some more preparations. I’m could have missed all the interesting stuff in the afternoon but it sounded like there was more software practices on the agenda.

But all was not lost. I had a great time at the welcome reception meeting lots of people I have followed on Twitter for a long time and others that I just met. Great conversations with lots of interesting people.

Yesterday, on the Monday afternoon, just after I arrived to Long Beach I meet up with a big crowed of speakers and other attendees for some beer and some great and relaxed conversations.

Here is a sneak peek at a screenshot from my presentation tomorrow on Visual WIP.