The cost of iterations applied to Kanban as well…
The overhead of iterations does not disappear with Kanban — but it does shift from fixed-cadence overhead to on-demand transaction cost that can be optimized differently.
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?
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →