Feature Driven or Date Driven?

A False Dichotomy
I’ve been just as guilty as anyone of drawing the apparent distinction between “feature drive” and “date driven” projects. It’s almost not worth stating that all projects have features, and without at least some of those features, the product has no value. True, a project can have a list of required features and no deadline, but it would be really weird if it had a deadline and no required features. Still, the distinction can be useful.

What we really mean is that some projects can ship whenever they reach the point of practical utility–in plain English, when they do something useful for the primary stakeholder. In Agile language, this would be the Minimum Viable Product, or MVP. Other projects, however, must ship by a specific date to be useful, and therefore, the feature set, whether extensive or an MVP, must be planned so the project fits within the schedule.

Managing Deadlines
Tensions escalate between engineers and business owners when they can’t agree on how many features can be completed by the deadline. Engineers feel that business owners refuse to acknowledge that the quantity of effort is almost always greater than either of them assume at the outset, and business owners frankly hold the semiconscious belief that anything can be done if only everyone were willing to work a little harder. They’re both losing positions. For one thing, the visible functionality, the buttons, boxes, and lists displayed to users are just the tip of a complex iceberg. In the case of Web applications, such as enterprise software delivered via the Web, engineers need to build infrastructure to support scalability, stability, security, maintainability, performance, and extensibility. These are not salient business functions, but they make it possible for the business functions to work reliably. This stuff can easily add up to more than half the effort.

To break the deadlock, engineers need to do their homework. Draw up their plans. Estimate effort. Report their findings. Argue if you must, but back yourself up with data, even if it’s based on semi-subjective estimates. After you succeed once or twice by doing what you say you can do, you’ll control your own destiny. And don’t think this is a one-sided win for engineering. Business stakeholders gain predictability. If they know they can count on engineering to deliver what they promise, they can plan the side of the business that actually pays us all, the part where we provide products or services to paying customers.

Feature Fantasy
Many mass market consumer products are feature driven. With the exception of seasonal products or products that are forced into seasonal cycles, such as consumer electronics and toys, most on-line services grow organically over time. For Web applications like Dropbox, Facebook, Evernote (which I’m using to compose this post), and Google Docs, features roll out as they’re completed and tested. These companies rarely promise specific features to their customers by specific dates. In fact, they usually don’t disclose any forthcoming enhancements until they ship, both to avoid tipping off the competition, and because deep inside, we’re all kids and love surprises. New features feel like gifts.

Does this mean projects without deadlines are easier? First let me say, no project truly has no deadline. Early stage startups often crank out features at their leisure, and in the process, frequently pivot from their original concepts to cobble together entirely new products and business models from the fallout of early failures. But someone’s paying the bills. Time is money, and when the money’s gone, game over. But that’s another semantic game. An established on-line business, like Facebook, can afford to be purely feature-driven, as can any company with self-sustaining revenue, within reasonable financial constraints and competitive pressure.

Why it Matters
Where am I going with all this? I hope I’m transparent. I believe that feature driven projects are often better off with Scrum, while deadline driven projects are often better off with a hybrid GANTT/Agile process.

Before you flame me, at least notice I said “often.” I’ll repeat, I don’t believe in absolutes. Know your options. Know what you’re doing. Know why you’re doing it. I’ll explain my reasoning in forthcoming posts.

If you plan to follow along, think about where your current or most recent project falls on this spectrum.