The Time-Boxing Rule

In a recent entry on the Managing Product Development blog, Johanna Rothman wrote about time-boxing and just how strict teams should be about adhering to the prescribed duration of an iteration. Her inclination, which I share, is that a team should generally adhere strictly to iteration time-boxes.

I wrote the following comment:

In my opinion, an organization that can't handle this sort of problem doesn't really know agile. Agile is all about discipline and constant adjustments. One of the main reasons for time-boxes is to force us to think creatively, on the fly, about how to meet them.

We should expect to fail to meet our original objectives in some iterations. When we can't meet those objectives, we change the objectives such that they are (1) achievable within the time-box and (2) yield something "releasable". Inability to make this sort of adjustment indicates a failure of imagination.

That said, I think a healthy, experienced agile team can adjust time-boxes slightly. But the scenario you describe sounds much more like a failure of discipline and creativity than a candidate for slipping the time-box.

But my comment wasted a lot of words to state what Asher Sterkin crystallized in a later comment:

In my experience timeboxing (as any other good practices: sport, diet, etc.) follows the simple rule: "who wants to do it finds a way, who doesn't want finds an excuse."

Thank you, Asher.