Timebox all the things. A “timebox” is a strict deadline, a finite amount of time to accomplish some task. The idea is that you stick to the timebox and go with the results you have, whatever they may be at the time. Although you might usually think of iterations as timeboxed development, the concept of a timebox extends to meetings, the amount of time to be stuck on a bug before asking for help, and more.
A development timebox is a starting point, aimed at helping the team transition from a 6-12 month (or longer) release cycle to continuous integration and deployment.
The chief benefit of using a timebox is to reduce risk and reduce wasted time and effort
A timebox for a meeting ensures that you reach a decision, instead of languishing in (often paralyzing) indecision. Knowing that the meeting, or even this topic, only has 10 minutes remaining can help push you out of the debate and into something more productive.
A timebox for team members who are stuck ensures that they‘ll seek help, and not remain stuck indefinitely, wasting more valuable time.
A timebox for development should be long enough to accomplish a small set of tasks/features, but short enough such that all the work is easily replaceable (to minimize risk).
How much of your work are you willing to throw away?
How much of your work are you willing to throw away? Make that the length of your development timebox. Clearly, the popular notion of a two to four week “iteration” is too long—it’s really just a small waterfall.
But in the beginning you might want to stick with the common approach that dictates “no requirements changes” within the timebox, and “one big release at the end.” However, those are not very agile concepts, and not very responsive either. If you’re transitioning from much longer release cycles (months or years), however, start with a two week timebox with release at the end.
This short, artificial boundary forces the team to do just enough analysis to understand what the larger task looks like, and how to decompose that work into smaller units. Studies show that development efforts have higher success rates when tackling smaller amounts of work. We can take advantage of that.
The timebox also provides a mechanism to identify teams with problems early. If a team struggles to complete working, tested, features within the timebox, perhaps it’s a random, one-time issue (yes, problems like that do still crop up). But if a team consistently can’t make significant progress after multiple timeboxes, while other teams can, that’s good feedback to indicate which team needs help. Instead of waiting six months or a year to discover that a team is struggling, you’ll know in a few weeks, and can work with the team right now.
The timebox also boosts morale. There’s something inside of us that likes to succeed. We love to cross finish lines. We can harness that desire to win and provide a finish line every two weeks. It’ll help everyone learn more quickly when we fall short, and build momentum quickly when we succeed.
But after developing this way for a while, you want to begin to “shorten the timebox” by relaxing the big ceremony at the end. Instead of one release at the end, release several times within the timebox period. Address changes as they occur rather than waiting, if it makes sense to do so.
Remember that the goal is to deliver value and user abilities continuously.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
Steps to first adopt this practice:
Did the team ship all the working, tested, features that they chose to work on? If not, adjust the amount of work pulled into the next timebox to compensate
Are the working, tested, features actually working, and tested, and in a shippable state? If not, fix that for the next timebox
What about unplanned work? How best to handle emergency bug fixes, maintenance tasks, and so on that come up?
There’s a trade-off between responsiveness vs. productivity. If you insist on stopping the team to respond to an issue, you ruin productivity. If you never let the team address unplanned issues, you ruin responsiveness. What you need is a compromise: buffer the unplanned work to some degree. (see TeamWideInteruption)
Defer unplanned work to later the same day, later the same week, or in the next development timebox, depending on the severity and priority. Don’t drop everything every time an issue comes up, and don’t ignore critical issues for weeks either: time box your response to emergencies, so that other parties have confidence that you’ll address the issues within some known period without becoming completely interruptible.
Shorter development timeboxes force you to ruthlessly automate tasks such as build, test, deploy, and database adjustments. One week iterations can be eye opening.
A bad technical lead or manager will tell the team what work they must take on during a development timebox. This is a very “command and control” approach, and removes the team’s ownership of the work. It also means the team has no reason to scrutinize the work description, acceptance criteria, etc. That violates our concept of bi-directional transparency and accountability.
If the team is consistently getting 10% to 20% of their work done, the team is over-committing. Enabling the team to consistently over-commit is enabling dysfunctional behavior. A good team averages between 90% and 110% of their commitments.
What else could you apply a timebox to? What else has a lot of unknowns, a lot of risk, and no end in sight?
Find ways to shorten your timeboxes. Look for ways to work together to ensure you can achieve goals set within a timebox. As mentioned above, try one week development timeboxes for 2 to 3 cycles.
Timeboxing is best taught by someone who’s experienced the practice. If you have another team in your company that’s already timeboxing, ask for mentorship from them.
Another approach is to bring in an external coach or mentor. This isn’t a permanent addition, but someone to guide and teach while your team learns.
It’s valuable to expose the team to experience. Lessons can be learned the hard way, through trial and error, but you’ll advance much more quickly by learning from other’s mistakes.