Flow or Iterations – What Do You Try First?

There was an interesting discussion on the LeanAgileScrum Yahoo Group early in December regarding the difference between flow (lean) and iterations (agile) that caught my eye. I only just now have had the time to write about it.

Here is a bit of the discussion:

Hello, Max. Trimming your posts might help with context. Thanks. On
Tuesday, December 11, 2007, at 12:05:45 PM, you wrote:

> For one thing, cadence provides a default timebox which limits cycle-
> time. (best Freud voice) I think that the desire to break down
> cadence is often an expression of the subconscious urge to
> suboptimize by focusing on utilization rather than cycle time.

It might be. I’m not sure of that. From both the heavy-theory side
and the practical side (Anderson and Belshee), we are seeing an
interesting variation of Agile that relies on a single queue with a
sort of “current time to next feature” sign, a take the next story
off the top of the stack scheduler, and no regular cadence clock at
all. It seems to be working well.

I’m interested in whether that’s actually a highly advanced
approach, or whether it is actually simpler and perhaps a better
place to start.

Right now, my experience is that a short regular cadence seems to be
a good way to learn to “git ‘er done”, and I’d not drop it lightly.
But I do wonder how fundamental it really is. Whatever “really”
means.

Ron Jeffries
www.XProgramming.com
Adapt, improvise, overcome.
–Gunnery Sergeant Tom Highway (Heartbreak Ridge)

So, the basic question: start with lots of small pieces of valuable work and do them based on priority without grouping a bunch of work into a timebox, or, take a bunch of work that fits into an (arbitrary) short timebox and get them all done in a bunch.

I strongly prefer the timeboxed iterations. Agile methods allow teams to clearly measure their velocity and make commitments on that basis. This is possible, but more difficult with a flow based approach. The timeboxes keep our measurement of effort even and allow a team to find out how much work they can get done for that level of effort. The timebox also allows us to measure at the level of the team rather than getting confused about who is doing what inside the team. Finally, a timebox also give the team the morale boosting satisfaction of everything being done at a regular interval rather than always having WIP (work in process).


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

One thought on “Flow or Iterations – What Do You Try First?”

  1. I agree. I like the clear boundaries a timebox provides. Constraints, in fact support creativity.

    In general though in a healthy agile implementation I believe it is not an either/or situation. It is not flow OR Iterations, but actually both. We need to commit to a set of work in the timebox, but within that there is priority, and given that a commitment is a guess sometimes we overcommit and sometimes we undercommit. In the latter case we bring things in to the iteration using a pull model (of course). In the former case we ensure we get the essential things done first. The timebox helps frame our work and gives us regular rhythm, which I find enormously helpful. It gives us regular breathing room.

Leave a Reply

Your email address will not be published. Required fields are marked *