Skip to content

Iterationless…

After working in week-long iterations for 2 and a half years, going iterationless left me a little confused on my recent project. Of course when I say iterationless, I mean using extremely small iterations to bring in a flow to stories. Lean? Distributed Lean, maybe?

Firstly, I like the idea of trying something new. The team being small and the project being developed in ruby helps this experiment a lot. There are, however, somethings missing in this way of working. I’ll list them down and give my view on each of them in this post.

To realize what we missed, let’s look at what we get from iterations. The following are the main motives behind iterations.

  1. Celebrate small successes
  2. Get regular feedback from clients (showcases)
  3. Let the whole team know what we will be focusing on in the next iteration, including the business context around it (Iteration Planning Meeting)
  4. Re-estimate stories based on additional information gathered during the earlier development (Iteration Planning Meeting)
So let’s see how we are trying to handle each of these situations.

1. Celebrate small successes.
This is very important. To look back and realize that we actually celebrated achieving a story-point targets each iteration, however, now sounds really lame. The moment you move your focus away from finishing a set of stories in a given time TO finishing a set of features and going to production, the world starts making more sense.

I think in this aspect chucking iterations totally makes sense. What this means is you should have a very strong release plan, with frequent (less than a month long) releases.

2. Getting regular feedback from clients
Showcases have nothing to do with iterations. Iterations only provide regularity to showcases. To say that we will do showcases once a week (and do it) is I think good enough.

One thing to beware of is that showcases-bound-to-timelines (once a week) and development-bound-to-releases (of irregular time intervals) can be quite tricky to handle.

3. Let the whole team know what the focus of the next iteration is
Ours being a small (ideal?) team, I don’t see too many problems in this area.

4. Re-estimate stories based on new knowledge
This, I thought, was the most important aspect we were missing out. But once you realize that your story point sizing is only relative to any other story you estimated, the world seems much better. This means that as long as your triangulation is correct, you are ok.

One thing that IPMs give us though, is an opportunity for the whole team to estimate together. Right now I am unsure of how important this method is. I am posting a few questions related to this at the end of this post. It’ll be great to get some feedback on these.

All in all I think going iterationless is beneficial in terms of:

  • Shifting the team’s focus from story points to features / business value.
  • Letting the team focus on estimating complexity of stories much more clearly.

What I am unclear about is estimation.

  • If we spend 2 hours every week to estimate together, are we going against lean philosophy?
  • On the contrary, if we estimate just-in-time, in smaller groups (pair to work on the story) are we losing the “group touch” to estimation?
  • Also if we estimate just-in-time (when we decide to play a story), the business doesn’t get an opportunity to re-prioritize based on sizing.

2 thoughts on “Iterationless…”

  1. Shaun.jayaraj@gmail.com

    Nice article. The other thing an iteration does, is that it imposes an artificial deadline. Developers scramble to get work done for the IPM. Not having iterations can take away this false sense of urgency.

  2. I have actually run projects in much this way. We still have “iterations” to provide regularity to showcases and retrospectives, but you are correct – this is a very superficial usage.

    As for estimation, I would question your assumption that relative estimation means you don’t need to re-estimate. I think regular re-estimation is critical, because over time your understanding changes. This can effect the estimate of stories regardless of them being specified relatively. (note: even with iterations I often see projects failing to re-estimate regularly).

    One of the “problems” of re-estimation that is often suggested is that it is time consuming. I respond to that claim by suggesting that it is time consuming because the “inventory” of stories is too high – stories have been broken down to development ready too soon rather than being kept high level.

    I’ve also heard the argument that having an iteration is good for setting a deadline which motivates the team. I would content that this is questionable – and could even be detrimental as a team might either leave things until the deadline, or might work too much to meet the deadline (resulting in a later drop in efficiency due to burn out). I think velocity is a good enough target to motivate the team.

Leave a Reply to Chris Cancel reply

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