Why Short Iterations Work
Software developers are infamous for not being good estimators. They say programmers have three timelines they work with: “done”, “not started” and “nearly finished”. It is easy to get caught up in the implementation details and not know exactly how long it will take to wrap up the task.
Time boxing can be very helpful when developing software. Our customer can assign a relative priority to a particular piece of functionality and we can stay focused on implementing just that piece for a period of time. If we do little bits of work towards that goal and review and validate our progress at the end of time slice, it is more likely to keep us focused on building what the customer wants.
Short iterations help us manage the complexity of tasks by forcing us to break tasks down into smaller and smaller steps. These smaller steps help us estimate more accurately and validate more frequently. Short iterations keep us from staying stuck on something for too long and give us frequent checkpoints to validate our work to make sure we are producing the most value for our customers.
When we work in short iterations we often don’t have time to figure things out everything up front so we have to figure them out as we go. We get good at identifying risks early on a project and find ways to encapsulate them so we can defer on implementing parts without paying a big price later.
When a task seems so complex that it is overwhelming it can be helpful to break it down into smaller tasks. This exactly what we do when we work in short iterations.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)