Why We All Use Timeboxes

 

I've been a project manager/program manager and have taught project management and program management since 1992. I have the gray hair to prove it.

One of my secret tools was timeboxing. Oh, it wasn't such a secret, because I asked people to timebox their work. I timeboxed my work. I taught about timeboxing. I found that limiting the time that people worked on a task helped them focus. 

I am not talking about hacking 20% off a schedule for people to feel "pressure." I've never found that to be useful. But using timeboxes? Wow, so useful for me. 

Here's how I have used timeboxes:

1. When I have work I don't know how to start. Have you ever wondered about a specific task you need to do? You sit there and say, "I have no idea how to start this. Maybe I should check email." I use a 10-minute timebox to gather myself and write down how I could start this work. I limit this timebox to 10 minutes because I want a long-enough period of time to make progress and short enough period that I can see where I am at the end.
2. I find it helpful to reflect on my work every so often. I like to think about how I can work better. I happen to use a one-week timebox to reflect back on the previous week and plan my next week's work.
3. When I have deliverables at a certain time. I have clients, books, and teaching deliverables. Yes, I have more than one project underway at all times. That's because I'm a consultant. I create small timeboxes to make progress on all my work. I work on one thing for an hour, get that piece to done, and decide what to do next. While I am in that timebox, I concentrate on just that work.

You'll notice I haven't said anything about "agile" here. Agile uses timeboxes for many things, including my examples. 

When a team doesn't know how to start, they do a spike. The entire team learns together, for anywhere from an hour to a day. The team decides on their timebox and understands what the rest of the deliverables are by the end of the timebox.

Many teams use two-week iterations as their team cadence. They have a rhythm for demonstrations and retrospectives. They do exactly what I do: reflect and use their current data for planning the next chunk of work.

I prefer that teams work on only one project during an iteration. For many teams, this is impossible. In that case, I ask the Product Owner to make sure the features are small, so the team can see the flow of work (that they make progress all the time) and that they manage the interruptions. 

Timeboxes are not new to agile. They are an old project management "trick" or tip. 

If you find yourself under pressure, consider your deliverables. What can you focus on now--and not interrupt yourself for a short time--to then deliver? You have found the secret: deliverables in short timeboxes. 

Regardless of your project approach, consider timeboxes in some way. You don't have to be agile to use them. And, if you are agile, maybe explain how you use timeboxes. Maybe I can learn from you!​