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:
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! |




