GROWS logo

Timebox

Timebox all the things. A “timebox” is just 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 iterations, meetings, the amount of time to be stuck on a bug before asking for help, and more.

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 is called an iteration. An iteration should be long enough to accomplish a small set of tasks/features, but short enough to comprise easily disposable work to minimize risk.

Iterative development leads teams to break down their work into more manageable tasks. The traditional, and very risky, approach of allocating months for a single task can’t hold up if the team is working in two-week iterations. 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 have repeatedly shown that development efforts have higher success rates when tackling smaller amounts of work. The iteration idea takes advantage of that.

The iteration also provides a mechanism to flag problem teams earlier. If a team can’t complete most of their task in a two week iteration, maybe it’s just a random issue (yes, problems like that do still crop up).

But if a team can’t make significant progress after multiple iterations, 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 has an issue, you’ll know in a few weeks, and can help fix it now.

The iteration is also a morale boost. 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.

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment (Timeboxed Meeting)

Steps to first adopt this practice:

Setup

  1. When scheduling a meeting over a contentious issue, instead of specifying an agenda, 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 (Timeboxed Development)

Steps to first adopt this practice:

Setup

  1. Establish an iteration length: two weeks is good first choice, possibly three.
  2. Have the team choose what they will deliver in shippable, working condition at the end of the iteration.
  3. Ensure this iteration is the only thing the team is working on at this time.

Trial

  1. The team works on the items they’ve selected
  2. The team delivers the fully completed items at the end of the iteration. Items that weren’t completed are moved into the next iteration.
  3. Tend to any other work that needs doing that isn’t part of the iteration yet, then begin the next iteration.
  4. Continue for 2-3 iterations at least

Evaluate Feedback

  1. How much of the work accepted was actually delivered? Adjust the amount of work assigned for the next iteration to better match the work actually completed.
  2. Have an informal look at the completed items. Are they really completed? At the next stage, you’ll be demoing these items to the customer. Take this opportunity to verify for yourself that the team is doing it right. If not, then tackle that in the next iteration. Once you’re ready for customer input, you can move up to the next stage.

What Does it Look like?

At this stage, you just doing work in increments. At the next stage, we’ll expand on this idea and add practices to set up for the demo and get better feedback at the end.

The length of time allocated to a timebox is important: it needs to be as short as it can be and still work. Here are some guidelines, stick to these limits for now:

  • Team iteration: 1-4 weeks. 2 weeks is a good starting point. Stick to a consistent length at first.
  • Scheduled tasks: 1/2-3 days of work. Larger tasks should be broken down; smaller tasks should be pooled together.
  • Meeting: 45 minutes is a good maximum meeting length. Do not exceed 90 minutes, and include a break at 45.
  • Stuck: 1/2 day maximum to get stuck on a bug or problem, after that, you are required to enlist help.

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 cold to respond to an issue, you will ruin productivity. If you never let the team address unplanned issues, you’ll ruin responsiveness. What you need is a compromise: buffer the unplanned work to some degree.

Defer unplanned work to be later the same day, later the same week, or in the next iteration, 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 will have confidence that you’ll address the issues within some known period without becoming completely interruptible.

Iterations can be one to four weeks. Most teams use a two week iteration. A one week iteration forces you to ruthlessly automate tasks like testing, deployment, and database adjustments. Trying one week iterations for a few months can be an eye opening endeavor.

Start your first iteration with a group StoryRefinementMeeting.

Warning Signs

A bad technical lead or TeamLead will tell the team what work they’ll be taking on during an iteration. 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; that’s no way to run a growing organization.

If the team is getting 10% to 20% of their committed work done, then the team is being given too much work. Enabling the team to consistently over-commit is simply 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

Combine your testing work with your development work. Don’t create separate stories, and then blame testing for not finishing “their” work. It’s the team’s work and the stories aren’t done until they’re shippable. Not tested? Not accepted. Next iteration, finish on time and help out the QA team! Help them verify another team member’s work, or help automate the acceptance tests.

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 a prisoner exchange. This is where you trade a team member for a few days or a few weeks (maybe a few months?) and they can work alongside your team, explaining how they run this meeting, or deal with that problem. Your team member, the one sent to the other team, is immersed in that team’s practices. Each team has something to share with the other. This side-by-side immersion shares everything the team does in a variety of contexts.

Another approach is to bring in a coach or mentor for a few months. This isn’t a permanent addition, but someone to guide and teach while your team learns the ropes. Coaches are often external to the company and mentors are from within, but in both cases we’re introducing expertise in a position of authority.

Whether you introduce peer expertise, with a prisoner exchange, or hire a coach, it’s important to introduce experience to the team. 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

Anti-patterns from the Hall of Shame

  • Extending the timebox until the all the work is complete
  • Restating your commitments at the end of the iteration to make it appear that you hit all your commitments
  • Vary every timebox’s length… 1 week. Then 2 weeks. Now 1 week. Let’s try 3 weeks…
  • Vary the team members for every timebox

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