The Tyranny of the Ever Decreasing Timebox

Agile software development methods, with the exception of Feature-Driven Development, adopt the use of fixed time increments, often wrongly called “iterations”. In Scrum, these are known as Sprints. A Sprint is a fixed period of time with a defined scope and a commitment to complete that scope within that time window. Originally, Scrum defined 4 week sprints. This was changed later, circa 2004, to a recommendation for 2 weeks to be the default length for a sprint. In general it is recognized that agility is related to the frequency of interaction with the customers or business owners, and the frequency of deliveries. Hence, smaller timeboxes are more desirable. Software quality is often related to batch size and time to complete work in a non-linear fashion, hence, smaller batches, completed in short periods of time leads to dramatically fewer defects.

As a result of all these advantages, organizations adopting Agile software development methods, have been under pressure to adopt the use of shorter and shorter timeboxes for their sprints or iterations. On the face of it, smaller timeboxes and hence smaller batch sizes for the sprint backlog, are a good thing. However, smaller timeboxes create two types of pressure that are often difficult to cope with and adjust to: firstly, smaller batches require an ever more detailed approach to requirements analysis and development – the need to write every more fine-grained stories which can be completed within the smaller time window; and the need for an ever more accurate approach to estimation, so that a realistic commitment can made.

I first mentioned this “tyranny of the fixed timebox iteration” in my after dinner key note at Lean UK in London in 2009, the full text of which is available from our resources section. Kanban frees us from this tyranny by decoupling the cadence of commitment (and system replenishment), from the lead time to complete work, from the cadence of delivering completed work. In order to understand the advantages of switching to a kanban system to enable better agility, first we understand the problem with simply taking a discrete, reductionist approach to improving existing Agile methods by simply reducing the size of the time window for an iteration.

Developing capability with a new requirements analysis technique is hard even when you know which technique to adopt. The challenge with very small time window Agile sprints is that there is little or no solid guidance on writing fine-grained, consistently small user stories. So the first challenge of the ever-decreasing timebox is often leads to anxiety and to undesirable effects such as breaking stories up into functional units based on activity such as “architecture story”, “design story”, “development story,” “test story” where the real customer value may now span across multiple sprints and dependencies between stories across sprints is now a tracking requirement. This type of breakdown defeats the purpose of the ever-smaller timeboxes and creates a false sense of agility when in fact, customer value and quality are not improving, perhaps the opposite may even be true.

The need to develop an ever more elaborate and accurate approach to estimation becomes counter-productive. As we make the timebox smaller, we increase the time and effort spent planning and estimating in order to make believable commitments that we are confident of meeting. As we shrink the timebox, we increase the economic costs of these timeboxes and decrease their efficiency.

Kanban avoids this, “tyranny of the ever-decreasing timebox” by decoupling replenishment candence, from lead time to complete stories, from delivery cadence. Meetings to decide what to start next run on a regular schedule, as do planned deliveries, however the time to complete a story is not limited by any timebox. The advantage is that we do not need to develop capability in ever more detailed and consistent analysis, nor any capability at ever more elaborated and precise estimation. The counter to this is that we must have a configuration management and version control capability to avoid releasing unfinished work while we plan and execute a delivery of finished work.

In order to decide whether Kanban is a better choice to meet your agility needs rather than reducing the time windows for your sprints, you should ask yourself, which capability is easier to acquire? Is developing new and better ways of writing user stories and new and more precise ways of estimating them easier to acquire? Or would it be easier to develop a more sophisticated configuration management strategy using branching and labeling or relabeling in order to enable Kanban’s approach of decoupled cadences?

The truth for most software development organizations is that the Kanban approach and improving configuration management and version control capability is far easier and far less risky than continuing to shrink the length of a sprint in order to respond to greater market demand for responsiveness and agility. Kanban breaks the “tyranny of the timebox.” Instead of trying to do Agile better and struggling, it is often easier to choose to be Agile in a different way – to adopt the use of kanban systems and abandon the use of fixed time window iterations or sprints.