Feature Devotion

3 11 2006

Martin Fowler has a blog (bliki) entry that addresses how agile teams can fall into waterfall practices if they allow their projects to become about the Features, and not the Outcomes. This happens on 100% of my projects at work. I think it’s because upper-management decided that they wanted more visibility into development projects, and so introduced an inflexible tool into the process. Now, I know that agilists get mocked for carrying around their 3 x 5 cards, but 3 x 5 cards have two great features: they are easy to reorder, and they are easy to throw away. If, after getting into the code, a previously unimportant feature becomes a core dependency, then put that card on top. If a feature, becomes unnecessary, throw that card away.

The problem with “tools” and “visibility” is that features are harder to throw away because they are carrying around more weight. We end up keeping features, even though we know the CEO doesn’t remember his password for logging into the Tool, just because the project manager doesn’t want to explain why features disappeared (you know, just in case some one actually looked). And since we don’t delete it, we end up implementing it. We’re not creating the best possible outcome for the customer anymore. We’re just trying to keep the Suits out of our hair. Very annoying.

I wish I had a good solution for this. The best I’ve come up with is to be as agile as I can in my own work. So my part of the project alway ends up on note cards. That’s how I’m comfortable working. It’s how I organize my personal projects. Heck, this is how I organize my life. I don’t even have a PDA.


Actions

Information

Leave a comment