Even before I started using agile approaches, I used timeboxes. I actually started to timebox my work when I got my first review as a developer and my boss said, "You don't finish anything. You get 98% of the way done and then you stop." Well, that's because I hate those little details at the end of a task.
Details are not my friend. I can manage them. I can do them. But I hate them. I would much rather eave my hands and say it's done when it's close enough. Well, close enough for the rest of the world appears to much closer than it is for me, so I started using timeboxes when I got that feedback.
I sometimes use timeboxes of no more than 10 minutes when I need to get started on something and I have no idea where to start (such as cleaning my office). I use timeboxes of an hour when I need to see how long something might take and I don't know how to estimate the task. That's enough time to do something useful but not so much time that I get bored and go do something else.
In projects, I frequently use timeboxes of 1-4 weeks, just as the agile lifecycles do. But even if I'm not using an agile lifecycle, there's something quite powerful when I tell the product managers, "You have 2 weeks to define the requirements. We're starting on the architecture after that, so get the good stuff in first." Then, when I tell the architects, "You have 2 weeks to fight about the architecture, and then we're starting on coding." Sometimes, if I think a feature is risky and maybe not so valuable, I'll timebox the coding of it.
One technique I started using back in the '80's was to timebox building and integrating and testing a feature. (This is incremental development, if you weren't sure of what to call it.) I started this when one of my talented developers got lost in the code. He fell in love with a feature, and was adding to it, expanding it, make it fabulous, but he hadn't integrated or tested it. I gave him a week to check the code in, making sure he didn't break the build.
I suspect he called me a variety of names, none of which were particularly nice. On the other hand, he finished the work because he didn't let anything get in the way of this task.
That's the value of the timebox; it focuses you on a particular task. It makes you promise yourself that you will finish this task before the end of the timebox. That focus and urgency help me finish my tasks on time. And, if a task takes longer than the timebox I've allotted, I have learned a lot about that task.
So, if you, like me, have a difficult time with the details, or if you have a tendency to go off on tangents, or if you would like to know how long things actually take, consider using timeboxes. Your project manager will love you :-), and you'll be a lot more productive.
