Scrum Timeboxing is an illusion. Lunchtime doubly so. Another argument in favor of Kanban.

Scrum Timeboxing is an illusion. Lunchtime doubly so. Another argument in favor of Kanban.

I've been thinking on the role of timeboxing in Scrum and Agile and come to a realization: I hate it.

Timeboxes are arbitrary constraints entirely disconnected from the work or decision making that needs to be done.

The constraints of the timebox arbitrarily drive and shape what we can fit within the box.

The purpose of a timebox is not to constrain time, it is to constrain the work.

Timeboxing is like filling your shoes with rocks so you don't walk too fast.

Alternatively, you could simply choose to walk slower or faster depending on what speed is needed. I believe this method is called Kanban.

Shaping the size and scope of an effort is too important to leave to some arbitrary time constraint like a two week sprint. It's a distraction that takes significant overhead to split-up effort and move things around to fit into these arbitrary timeboxes. Planning around timeboxes is also incredibly fragile, when unexpected blockers or defects arise even plan for a two week sprint can fall apart requiring re-planning and more effort focused on meeting entirely arbitrary time constraints instead of focusing on delivery outcomes and the planned effort.

Software development holds enough real constraints and challenges without needing to pile on the arbitrary self-inflected constraints of timeboxing.

Continuous flow strategies like Kanban that focus on the delivery effort (WIP) rather than timeboxing are in my opinion a much better option for Agile development.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics