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 :
