Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Iterations are High Ceremony

Myth: If you do iterations or sprints, you are Agile!

Few companies like Industrial Logic, Yahoo,etc and Individuals like David Anderson, Arlo Belshee, Fred George and many more have paved the way for iteration less agile. The Poppendiecks and the Lean community have been a big influence. So its perfectly fine if you think iterations or sprint are high ceremony.

Back in 2003-2004 when I was working on an offshore maintenance project, we got rid of iterations and it helped us great deal. Since then I’ve been on multiple projects where we’ve done Iterations/Sprints and I’ve always felt that we were wasting a lot of time. On some projects I’ve been able to influence the team to get rid of iterations and start focusing on our throughput. And those teams have not looked back since.

But then the question is:

Why does XP and Scrum have the whole iteration/sprint business?

As defined by original Scrum, Sprint is a fixed time box (1 month) at the end of which you deliver working software to the customers. What this really means is you deploy working software that the customer can use. So this is as good as a release. In some cases it might be internal release instead of a public release. Irrespective, I believe that Sprint == Release (some form) as originally intended.

While XP has the concept of iterations and releases. Which means at the end of the iteration you don’t necessarily release software to your customers. But you have a demo at to the customer at end of the iteration. Sometimes a demo is also a working session.

Never the less, as I understand the advantage of having a fixed time box (iteration/sprint) is to take x amount of time when the team is not really disturbed and in return the team commits to deliver x features (belonging to one or more goal). To be able to commit, the team needs to do some form of analysis and estimation to be comfortable with their commitment.

If you talk to Jeff Sutherland about why he decided to have Sprints as fixed time boxes, he will tell you that at that point the developers were constantly being interrupted by their customers/managers, leading to a context switch. This was yielding very poor productivity and lack of focus. The time box addressed this issue by keeping the customers and managers “out of the room” for the time box duration and also helped the developers to set a clear focus on what needs to be achieved.

Makes sense?

So if you don’t really have these 2 fundamental issues (or if you can educate people about them), why would you want to go thru all this ceremony of planning and estimating the time boxes? Esp. when you are not even using these Sprints as actual releases.

The time boxed way of doing things, forces you towards push scheduling. While this model is successful, it has some drawbacks and hence more and more people (esp. the lean software community) is moving towards pull scheduling. Where there are no artificial time boxes. As and when the features are ready (fully tested), they are deployed. We don’t batch a bunch of features (user stories) together as we do in Sprints. Instead we focus on the smooth flow of the features from inception to deployment. Basically trying to avoid waiting time and thus reducing inventory. Also simply applying queuing theory, you’ll understand that smaller the batch size, better the throughput.

In my case the batch size is couple of thin-sliced features. This really helps us keep the focus and we are not unnecessarily spending time context switching. Its important to note that the time it takes to build these features vary hence we don’t try to put an artificial sprint boundary around them. Whenever they are ready (ideally a couple of days), they are deployed. Zero waiting time. In some cases deployment could be internal and in some cases it could be public releases.

I strongly recommend :

  • Indeed, Naresh — I recently stumbled into this realization myself, and blogged about it.

    My thoughts on this solidified during CodeMash this week, where I attended a couple sessions on Lean and Kanban.

    We really need to be focusing on Throughput and not traditional Velocity per iteration.

  • Indeed, Naresh — I recently stumbled into this realization myself, and blogged about it.

    My thoughts on this solidified during CodeMash this week, where I attended a couple sessions on Lean and Kanban.

    We really need to be focusing on Throughput and not traditional Velocity per iteration.

  • Mark Collins

    I don’t believe that iterations qualify as “high” ceremony (as I’ve seen them applied in multiple teams), but they certainly are not a core requirement of agile methods.  I think commonly used agile methods persist in using iterations because it’s easier to get non-agile (traditional?) teams to understand how iterations change the way that they currently work. 

    Once you’ve internalized the rules and practices of agile, you can see how some of them are essential (expecting and accepting change, frequent delivery of functioning software) and how some of them are non-essential.

    I think that iterations are non-essential and to the extent that organizations get too formal about planning, estimating and tracking iterations, they can create waste in the process, but I have also found with my teams that having a cadence and having intermediate milestones provides early feedback on whether the team is on track a sense of urgency that prevents the last month or two of a six to twelve month project from becoming a death march.  Overall, I believe that for most teams, particularly those that are less mature in agile adoption, the benefits of iterations outweigh the costs.

  • Mark Collins

    I don’t believe that iterations qualify as “high” ceremony (as I’ve seen them applied in multiple teams), but they certainly are not a core requirement of agile methods.  I think commonly used agile methods persist in using iterations because it’s easier to get non-agile (traditional?) teams to understand how iterations change the way that they currently work. 

    Once you’ve internalized the rules and practices of agile, you can see how some of them are essential (expecting and accepting change, frequent delivery of functioning software) and how some of them are non-essential.

    I think that iterations are non-essential and to the extent that organizations get too formal about planning, estimating and tracking iterations, they can create waste in the process, but I have also found with my teams that having a cadence and having intermediate milestones provides early feedback on whether the team is on track a sense of urgency that prevents the last month or two of a six to twelve month project from becoming a death march.  Overall, I believe that for most teams, particularly those that are less mature in agile adoption, the benefits of iterations outweigh the costs.


    Licensed under
Creative Commons License