Timeboxing For Top Team Performance

What's your definition of a successful software project? How about this:

A successful software project delivers a quality product on time, within budget.

Time is always a factor in software development, and developers are always complaining about it.

“They didn't give us enough time.”

“They didn't let us estimate; they just told us when it was due.”

“We had to skip most of the system testing in order to deliver on time.”

Timeboxing grabs that problem by the horns and wrestles it to the ground. (Forgive me -- I'm from Colorado!) We set an end time -- that is, a timebox -- and then adjust our scope so that we deliver what we can within the time allotted. This presumes that the schedule is the most important aspect of the project, and frequently it is. Now there are other aspects, including resources, development skill, scope and quality. Let's look at these aspects realistically, with an eye to managing them so that we look good!

The “Iron Triangle”

On a given project, resources are usually fixed; and unless you believe in the Mongolian Horde Approach (hire a hundred people and hope some of them are good) the best team is a small one. Once you've put that team together, you've established their capability, at least in the short run. Now you have three aspects to manage, as shown in Figure 1.

Schedule: The time when the software product is due.

Scope: The functions and features delivered in the software product.

Quality: The absence of defects in the product.

I call these three “The Iron Triangle” because they have an immutable relationship. For example:

1. If we increase the scope, the schedule must grow, or the quality must decline.

2. If we shorten the schedule, we must decrease the scope or deliver with more defects.

The best timeboxing strategy holds quality constant and reduces scope to meet a schedule. Reducing scope flies in the face of what I call “The World's Greatest Program” syndrome -- the tendency on the part of developers to put every great feature into the first release, even if it causes us to be late. (Roland Racko calls this creeping or galloping elegance.) The customer always wants those features; they just don't understand how much it will cost them. I'd like to acquaint you with the facts, so you can feel good about leaving some features out when you're approaching the end of your timebox.

The last features

Those latest and greatest features cost more than you expect, and here's why. Remember the 90:90 rule:

The first 90% of a system takes 90% of the time:

The last 10% takes the other 90% of the time!

That sounds like a joke, but Figure 2 shows why it's true. As we approach 100% complete, our progress slows down drastically. This is because we're making tough decisions in the face of uncertainty. Moreover, they're not very good decisions. We will probably have to make many of them over again, when we have more information. This last 10% also accounts for much of the arguing and fighting that goes on in a project. Timeboxing forces us to forgo these last features, but it also lets us avoid most of the conflict that goes with them.

Pareto's Law -- the old “80:20 rule” -- gives us another justification for procrastinating on those last features. In the systems world, it predicts that:

20% of the system will give us 80% of the payback.

Now, in reality, this 20% only applies to a particular set of users. If we have a diverse set of users, we will have to give each group a different 20%, but it's reasonable to expect that we can please the vast majority of our users with 80-90% of the features. Sooner or later, we're going to deliver those last features, but not right now!

The right features

Making Pareto's Law work for you may sound like magic, but there actually is a systematic way of finding out what features you should deliver first. Ask your customers to rank the features they want. You can do this most easily in a group meeting of customers and developers.

Write each feature on a Post-itò, put these on a whiteboard, and have the group rank them (1 is high, 10 is low.). Then ask your developers to estimate how difficult each feature will be to implement (1 is easy, 10 is hard) and multiply these two to give you a priority weight for each feature. On the whiteboard, build a matrix like the one I've shown in Figure 3. It will show you, the team and the customers which features you should implement first and which you might postpone. (Quality practitioners will recognize this process as a part of QFD or “Quality Function Deployment.”)

Incremental Releases

This whole process of managing features is the best way to stage incremental releases of a software product. Jim McCarthy, Program Manager for Microsoft C++ products, asserts that you can build customer confidence through a series of timely releases, which delivers a steady stream of new features. To do this, he says you have to get into a stable state, and be ready to ship at any time.

Here's a strategy for delivering that first release:

1. Define your features.

2. Prioritize them.

3. Define three subsets:

· Gotta have

· Should have

· Nice to have

3. Build the ‘gotta have' subset as a prototype. Define a timebox, start prototyping, and deliver what you have when you run out of time. (Since it's a prototype, you won't have trouble explaining why it looks incomplete.)

4. Use this early experience with the prototype to define timeboxes for your first incremental release.

5. Stay within your timeboxes, delivering the features you have ready, on time.

Maintaining Quality

If you're in a stable state, you have a much better chance of controlling quality. A couple of basic metrics will demonstrate stability and dramatically improve your ability to deliver a quality product as you reach the end of a timebox. You need Defects Discovered, and Defects Corrected for each time period (days or weeks.) Figure 4 is a graph of these two measures; you can also derive (and graph) other important measures such as Defects Remaining and Mean Time to Repair.

Who does this defect tracking and graphing? According to McCarthy, Microsoft has a ratio of one Quality Assurance (QA) person for every two developers on the team. This graph is a great way for QA to highlight the coordination between these two factions on your team.

You can timebox anything

So far, we've been talking about timeboxing for product delivery. As I began studying the literature on timeboxing (see sidebar) I realized that I had been doing a form of timeboxing for over a decade. Training companies frequently have a set format for their courses; for example, all of their courses may be four days long. To build a course, you start with an overall four-day timebox, and break that down into smaller timeboxes to fit within breaks and lunches. That realization led me to try timeboxing in our methodology experiments at CASELab. We put every activity into a one-to two-hour timebox and gave the participants an opportunity to expand the box “a little” but not more than 20%.

We found that you can timebox any development activity, from requirements definition, to system design, to paper prototyping your screens. You define a time interval, and work within it. When you run out of time, you stop, and move on. Of course, you have to be reasonable; you can't do ten days of coding in a two-day timebox; but you actually might able to build a prototype in three days. You won't know until you try.

Sto