The Objective of Time-Boxing

This article continues my series on “Values, Practices and Principles Are Not Enough.”

Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. In Agile, these time boxes are known as “iterations” (XP and generic Agile) or “sprints” (Scrum). The deliverables of each time-box is working and tested software. If the amount of work planned for a particular time-box cannot be met, then it is considered to be better to complete as much code as possible while minimizing the amount of incomplete code at the end of the time-box.

The purpose of time-boxing has often been described as a method to get quick feedback on:

·       The quality of the work being done

·       If the right work is being done

·       How well the team is meeting their projected schedule

Time-boxing also provides a cadence for:

·       Planning

·       When things are started

·       When things should be brought to completion

·       When things are demonstrated

·       When to do a retrospection

·       Calculating the velocity of the team

These are all good things. But there are other reasons to use time-boxes. These include:

·       Forcing teams to work on small batches of work (stories must be able to be completed within the time-box)

·       Encouraging people to work together in order to get work completed within the timebox

However, one thing that is often not mentioned is that using time-boxing provides a certain level of discipline to the team. In other words, when time-boxing is actually used, one can clearly see what has been completed. It also encourages against bad practices that are common in Agile. These include having one time-box be for design, another for code, another for testing (sometimes called “Scrumerfall”). It does this by clarifying the objective is completed code at the end of every iteration. It is also facilitates getting accurate information on where the team is because you only get credit for work actually completed. This encourages a focus on completion not on starting.

The discipline provided by iterations is one reason that many new Agile teams should start with Scrum. However, the practice of time-boxing is not necessary to achieve all of the aforementioned objectives. The key is that if the practice of time-boxing is abandoned, it is critical that the objectives mentioned above still need to be met.

This is why many teams that merely abandon time-boxing and say they are doing Kanban (without taking on the practices of Kanban) are doing neither Scrum nor Kanban. It is fine not to use iterations, but the objectives of the iteration must still be accomplished in one way or another. Kanban's practices of managing work in process, focus on finishing, working on small pieces of work, managing queues, amongst others, provides these objectives.

In the next blog I’ll talk about the laws of software development that make the aforementioned objectives so important. People will follow practices as well as they can. If one says “do shu ha ri” until you get it right they may just abandon the practice. Not considering this and making people wrong for doing it merely demonstrates a lack of understanding of people and ignores the fact that a framework must include how people will react to it.