Chapter 6
Teams Deliver Features

In the past, you might have worked on a team that received a gigantic product-requirements document from a product manager. You worked on that project for months—maybe longer—and invited the product manager in to see the work you finished. That product manager might have had any of these reactions:

• You gave me what I asked for. It’s not what I need.
• The market changed. I don’t want this now. I want something else, yesterday.
• This isn’t what I wanted. You read what I wrote, but that’s not what I meant.

Or your team was working on all the features, and halfway through the project a product manager or a Very Important Manager came to your team and said, “We need to ship tomorrow. What do you have?” Since the team worked across the architecture rather than through the layers of the architecture, the team had nothing to release. The team had many features in progress, but nothing was done.

Maybe you had a different experience, and it still wasn’t good. You needed more collaboration with the business, or to deliver something more often, or to finish some work to release early.

Agile approaches address all those problems. That’s because agile teams deliver finished features on a regular basis. Agile teams use feature-driven development (FDD), regardless of whether they use an FDD approach (see Java Modeling in Color with UML: Enterprise Components and Process [CdL99]) or some other plan-and-implement-by-feature approach.

When a team delivers features, everyone can see the shape of the product from the beginning as it evolves. That’s what we’ll discuss in this chapter: what features are, how to think about planning features, how to plan and replan, and how to understand the difference between features and waste.

First, let’s talk about what we can plan.