PM Clinic: Week 15 Summary
Topic: Preventing Feature creep
Compiled: 2/21/2005
The Situation:
We're a version 3.0 software product for business accounting. The product is at a point
where many of the common and important features already exist, and the design is becoming
mature. But what's happening is that the waves of features that the entire team (business/marketing,
as well as engineering) are pushing for are all minor things: things that sound cool
but that most people probably will never use, or never use more than once or twice.
I've seen feature creep and bloat happen before on other projects, and all the warning
signs are there now: we're becoming a feature farm, not a product development organization.
And everyone seems gung ho at the prospect.
How can I make sure version 3.0 and 4.0 doesn't bury all the good work we did in earlier
versions with tons of pet features, marketing features, and other stuff? How can engineering
continue to help the core business, but not turn the product into a coding and usability
disaster area?
- Feature creeped, Seattle, WA
Background
Product management is vaguely-standard industry term for whomever makes decisions about
features and product strategy. Sometimes there is a person with clear responsibility for
this (the product manager), sometimes it's just a pile of decisions different people are
involved with.
Often feature lists are a primary battleground for engineering, marketing and senior
management. Without a clear set of overall project goals, or clear delineations of power,
it's common to see all kinds of tactics and guerilla warfare take place around what
things will actually be in any release of anything.
Advice
Quality is a feature. One of the things that made earlier versions of any project successful
enough to justify the version your working on was probably some kind of simplicity (which
is often a contributor to quality). Everyone should acknowledge early on that some feature
additions will truly add quality while others ones diminish quality, or screw up other
innocent features, and that this can not be determined by looking at the new feature idea
in isolation.
There should always be a per release budget for wholesome non-sexy kinds of quality
improvements: performance, refactoring/infrastructure, top support requests, security
improvements, etc. Having this on the table from day one will serve as a baseline for
what "quality" means, and put any new wacky feature ideas in a the context
of some obvious hard hitting, clearly valuable and feasible development work.
Change control is any system for managing changes. If the team is partying on the
code, and no one knows what anyone is doing, the team desperately needs some kind of
change control process. This usually involves three things: a way to propose changes,
a structure for leaders to approve changes, and a way to notify the entire team of change
approvals/rejections. The ultra no frills approach to this is email (or perhaps yelling
down the hallway), but generally some kind of simple webform, a daily or weekly meeting,
and a website for documenting decisions is required. (The big brother of change control
is some kind of requirement/spec process, so that the change control process comes in
to play after specifications reach a certain point).
One example of change control came from Trena: her team uses a bi-weekly development
team review to discuss proposed changes. They also have daily contact with clients to
discuss business cases *behind* the requests, which helps to separate a specific feature
idea, from the need or problem that needs to be solved (but may very well have better
solutions than the feature requested). Stellman described a more detailed system for
change control, called a Change control board (CCB).
The budget and the schedule are often natural forcing functions to feature addiction.
If you can wield it, use the budget or the schedule as the way to funnel the energy
of endless feature debates into more worthwhile causes. The canonical example of this
is when the schedule says there are only 5 weeks, there are 10 weeks worth of good features
already listed, and the team is discussing even more new ideas for work.
Drive discussion away from specific features, and towards the solving of customer
problems. As Neil wrote "Guide them away from 'we need a button that does this'
to 'in order for this release to be successful we need address the difficulty accountants
have in keeping up with regulation changes'". Agreeing about problems to be solved
keeps people focused on the real goal of the project, and can help prevent people from
sliding into aimless feature designing, or from inappropriately crossing the line between
business/marketing strategy into user interface design strategy.
If you are on the engineering side, avoid the slippery slope of fudging estimates
for things you don't think should be in the release. Eventually you'll get caught with
this, or will work with someone who suspects you of doing it, and will be all to happy
to prove themselves right.
Contributors
Faisal N. Jawdat, Chris Beiter, Neil Enns, Trena Roush, Andrew Stellman, Scott Berkun
(editor dude)
|