A DIFFERENT DRUMMER

An Idea Whose Timebox Has Come

By Doug DeCarlo


Once upon a time in La La Land there was a project team that did everything right. They had a wonderful kickoff meeting with the business owner and other stakeholders. They even achieved consensus on the top priority requirements. Shortly after the kickoff meeting, the project team was able to put together a thoughtful project plan that would deliver what the client wanted. All parties were comfortable with the five-month project schedule. Sufficient resources -- people, technology and funding -- were allocated to get the job done right. Feelin' goooood.

Yes, the project did hit a few potholes along the way, but the La La team and the La La stakeholders were able to make adjustments. About 4.5 months into the project with 2 weeks left, the team claimed they were 90% home and couldn't wait to unveil the new La La system. That was when they hit a few technical glitches and one of Murphy's Laws came in to play, "The first 90% of the project takes 90% of the time. The remaining 10% takes the other 90% of the time."

The Timebox: Putting Brackets Around Chaos
Turns out that the La La team did not realize it, but they were practicing Ta Dah! project management. The danger with Ta Dah! project management is that too much time can go by before you discover that the project is in technical trouble, or you learn that you have produced a technically elegant and functioning masterpiece that's headed for the Smithsonian.

Timeboxing goes a long way in helping to avoid Smithsonian Syndrome (unplanned obsolescence) or insurmountable technical surprises before it's too late. This is accomplished by putting into practice four of the 9 Shared Values that underpin eXtreme project management:
  • Clarity of purpose: Knowing the "do or die" requirements and what's not
  • Quick Feel: do a little, show a little
  • Fast failures: fail early, fail often
  • Client collaboration: timely feedback
A timebox is a results-driven, set-in-stone period of short duration during which the producers focus on delivering a pre-agreed upon set of "do or die" requirements. By "short" I mean anywhere from a week to 6 weeks. Beyond that, danger lurks. You can think of a timebox as a micro project within a project.

The Timebox Cycle: Plan, Do, Review
Planning starts out with understanding the requirements as expressed by the business owner and client stakeholders. On extreme projects, this takes days and not months of requirements planning typical of traditional, waterfall project management.

Requirements can be functional (e.g., features), technical, operational and/or supportive in nature. "Do or die" requirements answer the question: "What is the very least, rock bottom, nothing-else-matters stuff that must be produced to be considered a successful result." For example, if you were to develop an improved model 3.0 of the firm's Pro Climber Backpack, "do or die" functional requirements compared to the previous Model 2.0 might be:
  1. Equal capacity
  2. Material weight must be 50% or less
  3. Final cost not to exceed 10% more than Model 2.0
  4. Equal or greater durability with minimum strength rated at 70 lbs. per square inch
  5. No increase in current manufacturing costs of $10.25 per unit
The ability of the backpack material to accept color dies of brown, green and orange would be great, but these would be nice-to-have according to the client.

Put Some SCAMO In Your Timebox
You'll notice in the above example that success criteria are established along with the requirements for the Model 3.0 backpack project. In extreme project management, I refer to such measures as SCAMO: Success Criteria Against Measurable Outcomes.

Sometimes the business owner and team might decide to split the requirements into several timeboxes:
  • Timebox 1: Meet the first 3 requirements
  • Timebox 2: Requirements 4 and 5.
Do and Review Constantly
"Do" means to prototype and learn what works and doesn't work by getting rapid feedback. You can tell when people are in the middle of prototyping when you hear group expletives like: "Yes!" Or, more often, "Ah _ _ _ _ !"

In some software development projects, a client stakeholder actually works hand in hand with the programmer to provide on-the-spot feedback. So "the doing" and a lot of "the reviewing" happen simultaneously. (You tell when the client and developer have truly bonded when both blurt out the exact same explicative at the same time.)

Daily meetings during the timebox are a must. Meetings are 10 to 20 minutes to report on accomplishments and identify changes and any barriers to progress. Problem solving is done after the meeting.

At the end of the timebox, a more formal review and assessment are typically made with the business owner. Adjustments are then made to the project and business case and the next timebox is quickly planned and implemented.

Sounds simple enough. However in practice, it takes a project manager with courage to make this happen. (Actually, courage is fundamental to being a project manager these days. Without courage, nothing much else matters anyway.) I encourage you to apply these guidelines. They will help get you the most out of timeboxing:
  • "Quality of Life" is one of the 9 core values of eXtreme Project management. Translation: a timebox is planned based on 40-hour weeks. Frequent heroic efforts are a bad sign and signal that the project is at great risk.


  • During the timebox, staffing is not increased. Remember Brook's famous law, which applies not only to software development projects? I paraphrase: adding more people to a late project makes it later.


  • The end date of the timebox is not changed. You do what you can in the time available, then re-group.


  • The timebox is not a penalty box. Extreme projects deal with many unknowns. If after giving it your best shot, you couldn't meet the timeboxed set of requirements for the Model 3.0 Pro Climber Backpack, you regroup and make new decisions about how to best move forward, if at all. Dispensing blame puts the project in a bad mood.


  • If the business owner needs to add requirements in the middle of the timebox, a trade off is made: Something else comes off the table or is moved into the next timebox. If a change to an existing requirement is made - make it 30% the weight of Model 2.0 -- a tradeoff is made, if necessary, to accommodate the change. At times a significant change will take place. Then the timebox is aborted and goes into re-plan.
Benefits of Timeboxing
  • It puts brackets around chaos enabling people to focus sharply on the minimum requirements for success
  • Greater control: timeboxes are short-term adventures marked with decision points at the end of the timebox. Risks have a better chance of being nipped before the project goes off the deep end and cannot be reigned in.
  • Since timeboxes are short, there's not a lot of room for creeping elegance or gold plating: adding features that were not explicitly called for, or going overboard on quality that is not needed for the intended purpose.
May SCAMO be with you.

Extremely yours,

Doug




©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy