The only f-word I won't say

Why 'feature' should be removed from the lexicon of software development. Agile swear words part 1.

This is the first of a semi-serious series of words that should be removed from the agile lexicon.

Language is important. Semantics matter.

If we accept words have power, then it’s important that we choose the right words. Words can wound. Words can inspire. Words can limit your field of vision. A word that regularly limits teams is ‘feature.’ It’s a word that I try to avoid saying. It feels like swearing.

What’s wrong with f*atures?

Output over outcomes

It values output over outcomes. If a team is incentivised to deliver features, then typically, there are no measures in place for them to understand the impact of what they have delivered. Once the software is deployed, the team is done. Whether it solves a problem for the user, or is even used at all, is not discussed.

In many cases, a team may be moved on to the next project, and the delivered software is not even supported. Ownership is ignored, and technical debt builds up, unwatched and unaccounted for. This can result in nasty surprises for future development teams who find themselves tasked with an update in a related area some time, even years, later.

A team can think they’re high-performing but a consistent focus on features is not the same thing as a team dedicated to solving user problems. The focus often comes from outside the team. Examples of how teams can become feature-focused include:

• Sales-led organisations, where sales complain about the current application and say things like ‘if only we had feature X, I would be able to sell it.’ I worked in such a company, and we still had salespeople saying this long after we built feature X.

• Executives prize delivery above all else. The unspoken assumption is that more features = better product. Since evidence of actual user impact is not valued by the organisation, it’s difficult to get out from under these assumptions.

To solve a user problem, the team needs to care about it, developing empathy for the user through research and experimentation. They need to consider the utility of what they’re building - how usable is it? Will it create value for the user? These valuable questions are lost when the team is only asked to work on the next feature request, without context. These requests for features and pre-cooked solutions become learned behaviour, and if it doesn’t start with the customers, it quickly spreads to them.

Semantic damage

This is where the real damage happens, as customers identify or demand solutions, rather than incentivising collaboration on discovering and solving problems. In a feature-driven world, there is no time allocated to discovery or experimentation. Delivery wins every time. The team doesn’t really learn anything. The software is not maintained, creating the risk of outages, and increased support costs over time. In many cases, the team’s technical skills go stale over time as curiosity is undervalued. Why keep up to date with the latest thinking, when solutions are routinely handed down or imposed from above?

This is why so many teams and organisations struggle with prioritisation - if you don’t care about the user or their problems, what do you have to guide you as to what to do next?

So, what should I call you?

If the f-word is disallowed, what should replace it and why? I pretty much always use the term ‘user value’ when having product conversations. When discussing the technicalities of how to deliver, or when in the weeds with engineers, I’ll refer to product capabilities. Capabilities reminds us that the software is there to be used and interacted with. Features are passive - the very word reminds me of a landscape - something to be looked at and admired. I might sometimes take the scenic route while travelling so I can look out at the features of the countryside. I’ll be using the capabilities of the paths and roads that have been put there to help me do so.

Features don’t have owners. Creating a capability suggests a contract with the user that this will be owned and maintained.

In defence of feature factories

As with all good rules, there are exceptions. You might expect me to rail against feature factories, but I actually don’t have a problem with them as long as they’re honest about what they are.

The hardest place to be is in a company where the executives talk about autonomy, but in reality, hand down solutions to the team and value developer utilisation over the utility of the software for their customers. This cognitive dissonance is damaging to team morale and to trust.

Shipping product is hard. Successfully delivering software to production should be celebrated. If the executives are happy to celebrate that and reward the teams for execution, then it’s not a bad place to be.

I just think that you can do better. Using the PandA framework (or similar), you can learn to assess the impact of the changes you’re making. Semantics are important. Culture can be changed by words and actions. Becoming more data-driven can save you. It may be a journey of a thousand steps through the landscape of feature-development, but I’m sure you can build the path of capabilities.