Sunday, March 9, 2014

Timeboxing

Most people in the agile world agree that it's good to timebox meetings. Interestingly, many in this group don't like the idea of having a time-boxed sprint. Instead, they prefer some sort of continuous delivery, such as Kanban.

So how can we explain this divide? The argument for timeboxing meetings is pretty simple: it helps keep the meeting focused and prevents it from lasting too long. Wouldn't this be good for the development process as well? Why do we see the value in timeboxing meetings, but not the development process?

I wonder if this group of people just have a sour taste in their mouths from their experience with scrum. Sprints in scrum often bring back horrible memories of day-long planning meetings and terrible estimates.

I don't want to go back to that, either, but couldn't our development work benefit from some sort of soft date or at least an overriding goal to work towards? This does not need to be a firm commitment, it simply helps in setting priorities. If we explicitly state that our goal for the next few weeks is to add feature X, we'll set aside other tasks that don't help with the stated goal.

Let me be clear — this does not set anything in stone. It is much more lightweight than a scrum sprint and does not carry the same level of commitment or predictability. It's also important to note that this would not rule out continuous delivery — code could still be released in the middle of the time box as soon as a logical chunk of work was finished.

Just as timeboxing meetings helps us make sure we discuss the most important topics, doing the same thing with our development process helps the highest priority items surface to the top and ensures the team is on the same page.