Show all posts
6 years ago

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.

  • helga

    Any idea when this will be released?

  • Michael Dubakov

    @helga First release with Kanban Board and Cumulative Flow diagram will be next week. In august there will be second release with an option to turn off iterations, some additional metrics and improved Kanban Board (based on initial feedback :)

  • Jim Benson

    Hi Michael,

    Did you use Corey Ladas’ Scrumban techniques as a weening-off process? For many teams, the processes of Agile become familiar and newer ways of working can be threatening.

    It sounds like you are weening now. What’s the feeling of the team? Are they psyched? Dubious?


  • Michael Dubakov

    @Jim Benson People have different feelings. One developer and one tester liked iterations very much and want to bring them back. I, as a product owner, like Kanban more (Scrum Master likes Kanban as well :). Other people in the team do not see much difference (or maybe don’t want to express opinion so far). Initially there were some problems with many branches, that was the reason why we switched from Subversion to Git. It is not a huge problem anymore, but still conflicts are happen and it take time to resolve them.

    We have more smaller meetings now in PO+Tester+Developer format for each user story. We have 2 weeks retrospectives. We’ve removed planning/estimations meetings, but from time to time have large release planning meetings where we discuss goals for the next ~2 months.

    I think the team is still in Storming phase with close transition to Norming. I hope it will be in Performing phase in 1-2 months :)

  • Sceptic

    How are the images related to this article?

  • Michael Dubakov

    @Sceptic Just beautiful pictures 😉 Well, does anybody see the idea behind?

  • Kirk Bryde

    Sometimes artwork is best left unexplained, as its beauty is in the eye of the beholder. :) However, since you asked, what I see is that the density of the brush strokes imply the amount of work effort expended (or planned to be expended) on a series of stories.

    In the first rendition, it’s somewhat linear (like a product backlog ranked by business priority). This work effort is easily snipped into “natural” iterations – as easily as you can snip a rope. This is Scrum (or other Agile methodology that uses iterations).

    In the second rendition, the brush strokes are much more chaotic – indicating a multitude of dependencies and priorities – and it would be much more challenging to know where to snip it. If snipped, it would be cut into arbitrary, unnatural iterations. Instead, it might be better to work on the backlog of stories a few at a time, in a constant flow – without regard to the concept of an iteration. This is Kanban.

    It is also notable that the first rendition implies the curve of a typical burndown chart – with a clear (but somewhat arbitrary because the rope is still quite thick) end-of-release point when the curve hits zero on the y-axis, whereas the second rendition does not resemble a burndown chart – it flows continually in parallel to the horizontal (time) axis.

    Some of you might think that the first rendition looks waterfall-ish, whereas the second rendition looks more like the eddies and currents of a steadily-flowing river, but I don’t. It’s all in the eye of the beholder. :)

  • Michael Dubakov

    @Kirk Bryde Thank you for the awesome explanation! I can’t do any better for sure.

  • Roman Korchagin

    Well done, exactly what I was looking for. These pictures are to go on the wall in front of me as they clearly show what’s been going on with my project.

    On a side note, it will be interesting to hear where did Michael find them. Did you have those pictures in mind and got someone to draw them? They actually look like some smoke. If they are pictures of smoke – maybe in our quest of workin on the edge of chaous we have to look more into the nature. As usual…

  • Michael Dubakov

    @Roman Korchagin
    I just looked for 2 abstract pictures, one more ordered and one more chaotic :)

Request a demo
Our product specialists will show you the beauty
and power of Targetprocess 3 and help you to customize
it for your process and business requirements