The point of the talk was more about flow than time-boxes. When you don’t have a defined flow and one overall goal for a sprint, there is no way your going to effectively do that with Kanban as well as you can with Scrum. David admitted that in the class we were at the week before.

This is where many product development research efforts lie at some point of their development. We want a multi-disciplined team to “swarm” on a problem, creating knowledge daily with chaotic iterative loops (i.e. conversations) that can’t be wedged into a Kanban board with buffers.

Kanban has its place, especially in the complicated, but not the complex. As David says it’s not meant to solve every problem.

Clint
http://www.ClintonKeith.com

Also, I agree with you that you can get to creativity without iterations. Naked planning is an example of this.

I certainly agree with the notion that creative activities can benefit from a timebox, or more specifically from being managed against the investment vs. value graph you show in your post.

I don’t think, however, that because we have creative stories that we want to manage with timeboxes, it means we need to use Scrum instead of Kanban.

In a Kanban system, the typical exit criteria for a story (or task) from a work cell (activity) is when it meets its done criteria. There’s nothing that says we can’t make the exit criteria done OR timer expires. If we make the timer part of our visible tracking, that reminder of the time ticking down still produces the same “motivation” as a timeboxed iteration in my experience.

Scrum (and other agile methods) batches stories into the same timebox. In Kanban, each story can still have a timebox, but the timeboxes do not need to be synchronized. I find this flexibility very useful.

I’ve had a situation in a Kanban process where we did want to synchronize the start of a couple of stories because of an external specialist that we could only get for one week. What we did was to hold on the pull of a story into a work cell until the second story was ready to start (we actually pulled a very small defect fix to keep the first work cell utilized during that short wait). I’ve never had the need to synchronize stories other than this occasion, and never more that two at a time, and I’ve never seen two stories that had to be synchronized on exactly the same start and end of a timebox.

So, I’m not convinced the need for controlling stories within a timebox is an argument for using Scrum instead of Kanban. What I’d ask is this: What are the situations where we must batch multiple stories into a single synchronized timebox? How often does that occur? Would that make Kanban an impractical choice and why?

[Also cross-posted to the XP LinkedIn group]

Paul
—–
Paul Hodgetts — Coach, Trainer, Consultant
Agile Logic — http://www.agilelogic.com
Training, Coaching, Consulting — Kanban/Lean/Agile/XP/Scrum
Deliver Better Software Faster — We Can Help!