Following up on my previous post, here are the benefits that I see in applying a continuous flow instead of iterations.
There are 2 cases in which I prefer a continuous flow:
1. The team is responsible for developing new software AND doing production support.
2. The team is inexperienced with iterative development.
If your team is developing new software and providing production support at the same time, working in iterations is hard. Trying to plan an iteration and handling unforeseen issues at the same time is very frustrating. You could use a buffer in your iteration, but even then, the planning will always be incorrect. When you think about it, planning is pure Muda (waste) in this case. Priorities are clear, urgent issues need to be solved immediately and deployed asap to production. All remaining time can be spent on the prioritized list of new features. So working in a kanban style, where we limit our work in process, works pretty well. By lowering WIP, we are much more responsive in case an urgent issue arrives. After it’s solved, we just pick up the remaining work, or a new feature from the list.
In the 2nd case, with an inexperienced team, we often see these issues:
- A lot of work in progress during most of the iteration
- The planned work never gets fully completed
- Features need to be transferred into the next iteration
- A lot of bugs due to quality and scope misunderstandings
While a good coach can help a team like this to get their act together, I believe that he will get better results when switching to a continuous flow for a while. Why is this?
WIP limits helps them focus on getting work through the chain, instead of taking on too many tasks at once. It also forces them to help others throughout the rest of the chain. If a tester is falling behind, it can cause them to being unable to start a new feature due to the WIP limit, so they better help ‘m out.
By applying JIT planning, scope misunderstandings will be avoided and focus will be much higher.
While iterative development has a strong focus on completing a committed scope, continuous flow focuses more on getting stuff through the system as fast as possible without any backcycles. As soon as the team is able to get features through the system fast and reliably, you can consider moving back to iterations (if it has value to you). You might want to hold on to the WIP limits in the beginning.
Continuous flow: Think OUTSIDE the project team…
- Bob (@FlowChainSensei)
Bob, thanks for the comment.
You’re absolutely right, continuous flow should start by letting the customer pull value from the supplier(s).
However, as in many transitions you have to start somewhere. Many lean transformations started with a focus on operations. Creating product families and optimizing flow within them. Gradually expanding towards sales, marketing, suppliers, … until the entire chain is able to flow continuously based on customer pull.
I’m not even saying that a software manufacturer should think about going lean all the way. But I believe that the ideas of flow can help a team in these 2 specific cases. If the company wants to take things further, then they should definitely think OUTSIDE the project team.
Pingback: Tweets that mention 2 ideal cases for continuous flow « Nick Oostvogels’s Weblog -- Topsy.com
Pingback: Market Technical Analysis – Tips To Understand This Science | Currency Trading Exchange Guide
Pingback: Hydroponic Gardening-Intro hydroponics and hydroponic supplies | garden plants
Pingback: A Guide to Web Hosting | Web Traffic Siphon