Timebox or Kanban: A False Dichotomy

“I want to move to agile. Or lean. I don’t know which. I just know I have to show progress more often. I want to be able to adapt to changing conditions. That means I have to choose between timeboxes or Kanban, right?”– a confused project manager, on the verge of adopting a more agile approach.

Some project teams are devoted to their timeboxes. Some teams are devoted to their Kanban boards. But you don’t have to exclusively choose one or the other. Timeboxes and Kanban boards are tools to ensure that you limit the work in progress and that you limit the size of the work. You can use either or both, and find value in both.

For those of you who aren’t sure what a timebox or a Kanban board is, here’s the quick explanation: A timebox is a specific amount of time in which you decide to achieve some result. I use five-minute timeboxes to clean my office, since I hate that work. Teams that use stand-ups timebox their meetings to 15 minutes to define the end of their meetings. No matter what, their meetings finish at the end of their 15-minute timebox.

A project team may use a one- or two-week timebox for an iteration. The key is that once you commit to a timebox, you never extend it. By definition, the team stops working when the timebox is done. If the team was unable to complete the work and meet the acceptance criteria, that’s information. The work is re-prioritized and may be continued in the next timebox.

With a timebox, you finish the work by definition. When the timebox is over, the work is over. You can then clear your mind of the work. I like small timeboxes to start something and then see the progress I make, especially when I’m not sure of the outcome. That’s why design spikes are so helpful.

When you use Kanban, you track the flow of work from its initial state through the intermediate states until the work is done–and then it moves off the board. You have a limited number of items in each state. So if you have up to four chunks of work in design, you then might have only three in coding, two in testing and one in staging because your staging people only want one change at a time. I really like Kanban for work where there are many interrupts or work that is feature-driven.

Kanban allows people to see clearly when they have work piling up in a place (or for a person) that cannot take more work. Kanban forces a team to reduce handoff work because of the limits of the work in each state. Timeboxes force people to reduce the amount of work they plan for a given time period.

Both of these approaches are good for people who want to transition to a more agile way of working. I often recommend people start with timeboxes, because in my experience too many people have trouble with small chunks of work (which is needed for both Kanban and timeboxes). Timeboxes force people to make decisions about how to create smaller chunks of work that are still valuable.

I worked with a group once who had what they called a Kanban board. It was really a Waterfall board, because each of their features took a month to do, they had no limits on the work in progress and the work piled up on the poor lonely tester. When I suggested their Kanban wasn’t working and that they move to timeboxes, they could no longer ignore their process–the timebox made it obvious.

Another group had trouble committing to any work in an iteration because about half of it was interrupt-driven, forcing them to fix problems and update current systems. Once they stopped using timeboxes and moved to a Kanban approach, everyone (including their managers) realized they had to limit their total amount of work in progress (and the amount of work in progress for each step). Their Kanban board made their work transparent to the organization. Once they realized they had too much work in development, their work flowed through the rest of testing and staging into production. Instead of feeling backed up with work, they had a feeling of flow.

I also worked with a hardware/software program that used timeboxes for most of the features (except for some of the architecturally difficult problems). Those were on a Kanban queue, so the architecture was developed just in time for the features that needed them.

You don’t have to choose exclusively. Take a look at what’s going on in your project. Are you having trouble breaking your work down into small enough chunks? Maybe try to estimate what you can do in a one-day timebox and see what happens. Are you totally interrupt-driven? Try a Kanban board, and make sure you put limits on each column. Maybe your team can try to estimate the work for a two-week timebox and use a Kanban approach; make sure you take a team approach to limiting work in progress by swarming around features as you proceed through the iteration.

Both timeboxes and Kanban work. They work better or worse depending on the kinds of work you have and the kind of people you have. Don’t assume that you can only use one kind of approach to limit work in progress and get to done. Finishing valuable work is the goal. Don’t assume you can only use one approach to chunking your work and finishing it quickly. Choose your approach (or approaches) based on the people, your environment and your work. Then watch your work flow through your team!

© 2011 Johanna Rothman. This column was originally published on Gantthead.com

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: