GROWS logo

Timebox

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.

Pain Points

  • Product deadlines that never end
  • “Death March” projects
  • Lack of product quality, lack of innovation
  • High-risk long term, multi-month or multi-year deadlines
  • Finding out too late that you built the wrong thing

Benefits

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.

Assessment

  • Any timebox shortened over time (200pts)
  • Working, tested, features shipped and development timebox length not changed (100pts)
  • Any timebox consistently padded with too much time (-50pts)
  • No one requests help when stuck (-100pts)
  • Any timebox lengthened or canceled (-200pts)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment (Meeting Timebox)

Steps to first adopt this practice:

Setup

  1. When scheduling a meeting, specify the result: the decision or the desired outcome, and the absolute maximum length of the meeting

Trial

  1. Run the meeting at the scheduled time, and at the end of the timebox, conclude the meeting with the best alternative reached so far. It may not be the best answer—but it’s the best answer at the moment

Evaluate Feedback

  1. Did a firm deadline force the discussion to the essential points?
  2. Was the team able to proceed faster with a decision in place?

Adoption Experiment (Development Timebox)

Steps to first adopt this practice:

Setup

  1. Set the timebox length to two weeks. Note this is the beginner value, over time the length will shrink to become continuous
  2. Based on business priorities, the team chooses which working, tested features they will ship during this timebox. The development timebox includes all activities that the team needs to perform. These activities will address ThreeTrackAttack items as well as any maintenance, bug fixes, infrastructure setup, etc.
  3. The team works only on these items during the timebox

Trial

  1. The team works on the items they’ve selected
  2. The team delivers the working, tested, features and items during the timebox. Items that weren’t completed are put back for prioritization, which often means is will move into the next development timebox
  3. Continue for 2-3 timeboxes at least

Evaluate Feedback

  1. 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

  2. Are the working, tested, features actually working, and tested, and in a shippable state? If not, fix that for the next timebox

Adoption Experiment (Stuck Timebox)

Setup

  1. Set a time limit for anyone to be “stuck” on an issue (a bug, design decision, requirements question, priority) of two hours.
  2. At the end of two hours, if you are still stuck, ask for help. At the end of another hour (three hours total), if the issue persists, call a timeboxed team meeting to discuss.

Trial

  1. Make sure everyone knows the rules for getting unstuck (note, this idea is not for developers only).
  2. At the TeamSync, discuss any stucks and things discovered or learned

Evaluate Feedback

  1. Did the team request help when stuck during the timebox? Reinforce the need to follow the rules for getting unstuck
  2. Did the team evaluate a course of action for stucks? Are stucks discussed and resolved?

What Does it Look like?

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.

Warning Signs

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.

Growth Path

What else could you apply a timebox to? What else has a lot of unknowns, a lot of risk, and no end in sight?

Exercises to Get Better

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.

How to Teach This Practice

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.

How To Fail Spectacularly

  • Meeting timeboxes that are so frequent and recurring that no time is left for actual work
  • Meeting timeboxes with no goal or outcome specified
  • Meeting timeboxes dominated by one or two people
  • Extending the development timebox until the all the work is complete
  • Restating your work at the end of the development timebox to make it appear that you completed all your work
  • Vary every development timebox’s length… 1 week. Then 2 weeks. Now 1 week. Let’s try 3 weeks…
  • People stuck in a development timebox, not requesting help

←Prev (Continuous Integration)(Set Team-wide Interruption Protocols) Next→

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method™. We will not use your email for any other purpose.