rare

AGILE ANTIPATTERN: “UNBOUNDED TIMEBOXING” [#Agile #AgileAntiPattern #Timeboxing]

Timeboxing is a core discipline that Agile practitioners ought to master.

Scrum has 5 events — each of which can take no more than a maximum amount of time.

Assuming a one-month Sprint — which is itself a timeboxed container for the other events:

Sprint Planning can take no longer than 8 hours
Sprint Review can take no longer than 4 hours
Sprint Retrospective can take no longer than 3 hours
Daily Scrum is timeboxed to a maximum of 15 minutes, regardless of the length of a Sprint.

Every one of these events is an opportunity to inspect and adapt something – a plan of work or an increment of functionality lined up for delivery.

Teams that operate on the basis of continuous flow, and do not “Sprint” at all, generally still find it useful to timebox. For example, few Kanban teams would accept a daily huddle that dragged on without limit.

The essential constraint is that meetings of any sort tend to be subject to the law of diminishing returns.

If a daily huddle were to last 30 minutes rather than 15, it is unlikely to be twice as effective. Breaking timebox limits does not usually improve the quality of an activity. It is typically better to get on with the work, deliver value in a timely manner, and learn from actual experience.

When the bounds of a timebox are not observed, the focus one might expect from a time-limited activity becomes dissipated. The goal of the activity is no longer kept to the forefront of the minds of the people and the effort becomes subject to drift and delay.

Moreover, the ability to compare certain activities can become harder if the time spent on them varies. This is why Sprints ought to be of the same length if their effectiveness is to be compared and contrasted.

Yet, while it can sound as though respecting timeboxes ought to be a “no-brainer” and violations are a rare occurrence, in fact the pressure is often on for teams to break the limits. The antipattern of “unbounded timebox” is rather more common.

For example, teams may be tempted to extend a Sprint if they think it will increase the chances of their Sprint Goal being met. Doing so will create the illusion of having had a successful Sprint even though the forecast of work was not provided in a timely fashion.

The antipattern of “unbounded timeboxing” tends to arise when product ownership is inadequate, and the pull exerted for delivery is too weak to make disciplined timeboxing seem worthwhile.

ADAPTED FROM:
How Not to Do Timeboxing in Agile:
Any project in which timeboxes have become unbounded is not being run in an agile manner.
DZone