My latest blog post was about the costs and challenges of iterations, as well as what to do to overcome them.
One of the other things I’m working on is Kanban. I believe Kanban is a great fit to many teams and situations. Specifically doing Scrumban is a great way to get the benefits of Agile project management together with the Lean Flow Kanban provides. If you strive to achieve a stream/flow of value, you face the same challenges of getting to the minimal batch of work you can live with, and the challenges are quite similar to what I described above.
One difference is that if you DO have bigger features/stories from time to time, with Kanban you do them as fast as you can, but you don’t have the challenge of fitting them into iterations.
This is an advantage and a problem. The advantage is that it feels more natural.
The problem is that teams can fall into the “comfort zone” of keeping the features big, and doing mini-waterfalls on them.
Both with Agile as well as with Lean/Kanban the best solution is on the business/product owner side. If HE breaks the requirements/features into smaller stories/Minimally-marketable-Features(MMFs), the team will execute and deliver faster.
I haven’t thought this through, but my gut tells me that on the engineering practices side, Kanban requires about the same approach as Agile/Scrum in order to reach a high ROI.
What are your thoughts?