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)
PM Clinic discussion group