Iterations

[Jared Richardson]

There is another thread talking about iterations. I'm starting a new topic as this one is a little different, but just to stir the discussion a bit, here is a quote from Ship It!

Feature-Boxed Iterations Instead of Time-Boxed Iterations

The problem with time-boxing is that we ship product features, not calendar days, to our customers.

When your team is using The List, and all the items are ordered by their priority, your releases become feature boxed, not time boxed. Management can look at the The List and draw a line beneath the features that they need in the next release. You then add up the time estimates for those features and calculate the release date. Your individual product and industry will dictate how long to schedule for your internal testing and beta programs, but you can concretely schedule your development code freeze.

When your sales team decides that a given feature must be included, that feature�s priority on The List can change, and it can migrate into the shipping features. However, the time associated with the feature must be added to the ship date.

This way of working gives your sales force and management team a clear and defined way to understand the trade-off between specific features and time. They are no longer trying to make decisions about ship dates and features in a vacuum. Instead of trying to abstractly weigh features that take more time, they are weighing two specific features, with specific time frames.

We feel that this approach gives you the product when it�s ready, as soon as it can be ready, instead of letting your company dictate an arbitrary release date that you miss. Our industry is famous for missing deadlines, and no wonder given the way we write software. Instead of trying to push an arbitrary
feature set into an arbitrary deadline, companies should let their development team tell them what they can do! If the developers can�t hit the mark that sales wants, is it better to find out now and adjust your plans or find out later, when you miss the deadline? And if the development team can hit the
mark early, wouldn�t it be nice to know so that the company can add features to the release or get it out the door to customers sooner?

The first time you release a product this way, management will be nervous. The second time, they�ll be relaxed. The third time, management will have learned to trust their software teams to deliver what they promised!

[Jason Menard]

We feel that this approach gives you the product when it�s ready, as soon as it can be ready, instead of letting your company dictate an arbitrary release date that you miss.

I certainly agree with this statement, but I think we can give all the data we want to management and they are still going to do what they can to dictate the schedule. So how do you convince the decision makers not to let their often arbitrary factors be the keys in dictating the schedule?

[Will Gwaltney]

Originally posted by Jason Menard:
[b]So how do you convince the decision makers not to let their often arbitrary factors be the keys in dictating the schedule?

This is from the section of the book called "We're on a Death March Project". We're talking about how to tame a current project, but I think it applies to your question, too.

First, create a new project schedule. Use The List (Practice 10, Work
from The List, on page 57), and put time estimates on each item. Be
sure these are realistic time estimates, not Death March estimates.
Work with your tech lead to get the priorities correct and in line with
management.
Second, with the time estimates on The List, put together a time line for
the project. (This works whether it is your personal version of The List
or the group�s.) Publicize this schedule. Put it on your white board or
your web site. Often schedule makers create time lines simply because
they don�t understand the work involved. Help them understand.
Your new schedule probably blows right past the existing deadlines;
that�s okay. You want to get an accurate idea of where the project will
actually be on a given date, not fabricate a time line to support an
artificial end game.
Once you have a better idea of how much work you can reasonably
accomplish, show the time line to your manager. Tell them you think
the project is in trouble. Management may not be happy with your
predictions, but happiness isn�t the goal. Try to show them that if the
schedule doesn�t match reality, the schedule can�t be met (although in
some situations, it may be decided to keep the bad schedule for other
reasons).
Now at this point, you�ve got two choices: move the date or drop the
features. (Or quit. Make that three choices.) The choice your team
makes will depend on what�s more important: the ship date or the
features. If you decide to move the date, keep an active copy of The List
so that nobody can add features without adjusting the time line again.

[Rudy Harianto]

Will,
From the description about The List that you gave, I think that it is like a MS Project kind of thing..
Isn't it better if we use it right from the start of the projects? I mean not only if our project is in trouble.

[Ilja Preuss]

Originally posted by Rudy Harianto:
From the description about The List that you gave, I think that it is like a MS Project kind of thing..

Sounds more like Scrum Product Backlog to me: http://www.mountaingoatsoftware.com/scrum/productbacklog.php

Isn't it better if we use it right from the start of the projects? I mean not only if our project is in trouble.

Certainly!

[Ilja Preuss]

A very expressive way of showing current progress and the likely end date is to use a big visible Burn Down Chart: http://www.mountaingoatsoftware.com/scrum/burndown.php

[Jared Richardson]

Agreed, use The List from day one and get things moving smoothly from the beginning.

Ship It! has a FAQ (Frequently Asked Questions) section as the last chapter. It talks about situations you might find yourself in and how to solve those problems. That's where Will's quote came from and why it has the focus of fixing a problem, but we certainly think you ought to be using The List (or something equivalent) from the beginning of your project.

[Jared Richardson]

Originally posted by Jason Menard:
We feel that this approach gives you the product when it�s ready, as soon as it can be ready, instead of letting your company dictate an arbitrary release date that you miss.

I certainly agree with this statement, but I think we can give all the data we want to management and they are still going to do what they can to dictate the schedule. So how do you convince the decision makers not to let their often arbitrary factors be the keys in dictating the schedule?

I want to step back and address this comment.

You think that you management folks are setting arbitrary deadlines, but (in my experience) they aren't. They just aren't sharing their decision inputs with you, so you don't understand their decision. They are usually driven by market forces, competitor's product releases, revenue cycles, etc. I've found that managers ~usually~ (not always) have very good reasons for asking for product within a certain time line.

I've also found that management tends to think that the developer resistance to schedules is also arbitrary. They don't understand your reasons any more than you understand theirs.

The key to solving these problems is communication, which isn't always an easy problem to solve.

One of the big reasons we say that The List must be publicly available is so that management can see The List. If you provide a simple, clear representation of what you are doing and the times associated with it you have a starting point for dialog with your management.

If you can educate your management about what you are doing and why task X takes N days, they are more likely to sit down with you and adjust the feature list for the release (or the release date). Otherwise the situation ends up being a power struggle, with management trying to force you to work harder and you trying to delay the product so you can build a quality product. But neither side understands why the other is pushing so hard.

The goal here is to educate your management about how long it takes to implement an item on The List, and then which items are required for a given feature. Then the management can choose features that fit their timeline. If they need to have a release in July to ensure a launch for a tradeshow, they can look over the potential features and prioritize them for you.

Over time this release scheule becomes a regular dialog. Sales and marketing provides a list of features they need in the next release, development does their analysis (decomposing features into List items) and presents management with a copy of The List with estimated an timeline for each entry. Then sales critters tell you which features they need, which ones they are willing to wait for, and which ones (given huge time estimates) they don't want anymore.

I've been through this once or twice... it's not always easy to get started but it works really well after people start to trust each other and it's amazing how easy releases become.