Agile methodology builds on the concept of iterations – time boxes – in which you create a piece of working software. Each iteration starts with a planning meeting where the team takes stories from the backlog and commits to the sprint goal. If you use a tool like Pivotal Tracker, you even get emergent iterations – the tool automatically cuts your backlog into iterations based on your team’s velocity.
In my post Agile on steroids I described how our team slowly dropped most of the agile estimation and planning practices in favor of optimizing cycle time of stories. Now we’re running a true hybrid of iterative development and kanban. So, what makes the difference?
Iterations Tell You When a Story Will be Finished
With time boxes and a known Velocity all stakeholders can easily find out, when a given story at a certain position in the backlog will be delivered. There will be variation in the velocity, but overall the estimation will be quite good.
Kanban Tells You, How Long a Story Will Take
In Kanban, you don’t measure how much you can do within a certain period of time, but how long a story needs from idea to roll out. You can’t really plan big feature packages, but you can optimize the time to market of any story. This is usually a good thing.
Iterations Provide Integration Points
As every iteration should result in working software, all stories need to be integrated by the end of the iteration. The iteration end acts as a reminder for the developers to integrate regularly (at least once an iteration, which isn’t often enough in my opinion).
Kanban Creates Continuous Flow
When you use a Kanban style, lean development process, there are no artificial iteration borders. Each and every story leads to working software and, optimally, to a release. This requires a higher degree of self discipline within the team.
Decision Criteria
If you need big synchronization points, e.g. for big marketing campaigns, you might be better off using an iterative development approach. If you want to ensure a continuous flow of features, which are optimized for time to market (cycle time), Kanban might work better for you. What are your experiences with the one or the other? Let us know in the comments or send me a tweet.
Agile Web Operations 
Once a project goes into production, our clients often need to reprioritize stories on very short notice in order to react to the events of the day. Timeboxing our work into iterations would not work well here. We rather have short cycle times for our stories so we’re free to react to changes in priorities while still delivering a constant flow of value to the project.
This only works well when costs to take an integration point are low. Good test coverage and readily available acceptance testers can make that possible.
LikeLike
What you’re describing as “iterative” is more accurately described as “timeboxed”. Iterative development refers to successive refinement which is orthogonal to whether one uses timeboxes.
See http://jpattonassociates.com/dont_know_what_i_want/
LikeLike
Jason, I absolutely agree with you.
Iterative development IS NOT equal to iterations. Iteration is simply a timebox.
There are many articles on Alistair Cockburn’s blog where he explains the difference between incremental and iterative development.
Iterative development itself implies a “change”. So, the problem is that you can be a bad Scrum team and do only incremental changes (PO wants more and more features, the team does not have time for changes).
On the other hand the Waterfall team may suffer from axcessive iterative development – changes, changes, changes…. no time for building new featues.
I have written an article about this and it will be published on ScrumAlliance’s site by the 1st of March.
LikeLike
@Henning Yes, seems like a time boxed approach works better when building version 1.0. For maintaining and evolving the product after it is live, a Kanban base process seems to work better.
@Jason Thanks for the comment. You’re right with your remark. Thanks for the link – was a very interesting read!
LikeLike