Edge of Chaos

Agile Development Blog

Scrum, Lean, Kanban, Visualization, User Experience

Agile Product Development: Iterate, then Flow

There are several known areas where Kanban software development works fine: maintenance projects, game development, multi-media projects. There is no clear data whether it is good to use Kanban for product development or not.

I have my own vision of Kanban role in software development projects.  I think that

When you start a new product, you should use iterations first, but then may switch to pure flow development using Kanban.

Reasons are quite simple. Initially you do not have any burden. You have quite a large set of features that you want to push into Release #1. Definitely it’s better to have a small backlog, but it depends, you know. Sometimes  a “minimal marketable product” still has quite many features. So you have many user stories to implement, you do not have any bugs from production release, you do not have change requests, etc. It means you have a pretty stable environment with a quiet and stable backlog. And it means you don’t need to branch features and be able to release anytime. You may define clear goals for your iterations, estimate stories, use velocity and predict Release #1 date with acceptable accuracy.


However, things change with time. Suddenly you have large customers base, you have many enhancements, you have urgent bugs to fix and release. Now the environment is not so stable, you have unexpected events in the development process. Then I think it’s a good time to switch to Kanban. Urgent bugs may be fixed and released in 1-2 days, enhancements may be planned just in time with good release date prediction, velocity is no longer critical, since you do not need to predict large release dates, cycle time works fine for small features.


We’ve had this experience at TargetProcess. We’ve iterated for over 3 years, but several months ago switched to Kanban. Normally we do small releases each week, but are able to release anytime if required. We do not estimate stories anymore (maybe we will get back to story estimates, but doing without it so far). We are using Git and we’ve got a branch for each feature or bug.

Ironically, we stopped using some features in TargetProcess like release/iteration planning and progress tracking ourselves. It was a clear sign that Kanban support should be added to the tool. And it is on the way.


Visual Management Software

for Scrum, Kanban or your process

Take a tour