Wed 5 Nov 2008
Posted by Scott Westfall under Dev Management
Comments Off on The Politics of Features
The election season puts me in mind of the many ways I have seen teams decide on which features to implement. Like all human endeavors this process is political, meaning that it is shaped by the relationships and power structure of the organization. Consequently, you can use various systems of government as metaphors for different approaches.
For the sake of this discussion, we’ll treat defects the same as features. This isn’t totally accurate since some defects simply must be fixed as soon as possible. However, most defects are subject to the same decision process as features.
With this system, a single, all-powerful voice decides what gets done when. This is a common approach on smaller projects, where these decisions are made by the project manager. That’s not to say that this person doesn’t listen to advice from others. But when it comes time to decide they, alone, make the call.
Ultimately, the other systems typically have a single person who has to make the final decision. In my opinion, this is an essential characteristic of an effective organization. Everything should funnel up to a single person authorized to make decisions. People at different levels should be empowered to make various decisions, but in the end a single person should have the final authority. Otherwise, you flounder endlessly when a consensus cannot be achieved. It becomes a dictatorship when the leader ignores the advice and guidance of others and acts strictly on their own belief.
This approach only appeals to me if I can be the dictator, using my sagely wisdom to guide the product direction. In truth, this system can work well if the person in charge has a keen sense of what it takes to succeed. From accounts I’ve read, this is not unlike Steve Jobs’ approach to new product development. Though you can argue with his approach, it’s hard to question the results.
In an oligarchy , power is shared by small, elite group. This approach is often used on larger projects where various constituencies are represented. You might have representatives from project management, sales, development, quality assurance, and product support. In some cases, actual customer representatives might be involved.
The group meets regularly to discuss what is needed and when. Tradeoffs are weighed between features needed to spur new sales and fixes needed to appease existing customers. Typically, the group is lead by someone with final decision authority, but most decisions have a strong consensus.
This approach is certainly more representative, but it is also much more time-consuming. I’ve worked on projects that used this method, but they were very large with complex interactions between subsystems. Still, a light-weight version of this can be helpful to make sure all factors are weighed effectively.
In its purest form, this approach relies on votes from the masses to make the selection. Sometimes, members of the development team do the voting. In other systems, the customers are allowed to vote.
Though I cannot find a reference to it anymore, I recall that Sun used Duke Dollars as a way for developers to vote for specific fixes in the early days of Java. I’ve worked on teams where each developer was given some number of votes that they could apply to the bugs or features of their choosing.
I’m not a big fan of this approach. When the developers do the voting, this tends to favor the interesting, glamorous features over those that are more mundane. Often, these mundane features make a bigger difference to the customers. When the customers vote, they are typically guided by their own way of working. An effective product has to balance the different ways customers will use it.
You could use a hybrid approach, where the developers or customers submit votes but the decisions is ultimately made by a small group or individual. The problem with this is that it can be demotivating to the voters. If a feature with a high number of votes is rejected, they will ask why they even bothered. So, if you use a voting system, you should be willing to act on the results.
In the meritocracy , the best idea wins. Instead of suggesting a feature or voting for it, each feature is submitted with a business case. The business case is used to decide which changes make the biggest difference to the product.
This is my preferred approach to prioritizing features. It allows for input from all stakeholders and provides a means to assess priorities. With this system, anyone can challenge a feature and have it replaced in the schedule by demonstrating that another feature has a better business case.
Unfortunately, it is not always evident which idea has the greatest merit. So, this system relies on approaches from the others to make that call. A team or individual weighs the various proposals and picks the ones that best meet the business needs.
This approach also avoids the “squeaky wheel gets the grease” syndrome. Often, it is the customer or developer who is most vocal that gets their way. Great ideas languish because the proponent is not willing or able to be heard above the din of the highly vocal.
Truthfully, there are very few pure examples of any form of government. Most are a combination of these approaches. The most important characteristics of a feature planning system are:
• The ability to gather ideas from all stakeholders.
• The willingness to listen to these ideas.
• A system to evaluate ideas on their true merit.
• A clear vision of the product that helps to determine which ideas truly enhance the product and which just muddy the waters.
Of course, it wouldn’t hurt if we could somehow take humans out of the equation and have features selected by a race of benevolent and powerful robots. But that’s a post for another time.