Are you working in a feature factory?
You come in, you sit at your desk, and you work on developing features for your company’s software product. There’s no view of the impact your work has on the solution as a whole. There’s little interaction with other teams. You haven’t given the end customer much thought in a while. When you finish one feature, you’re on to the next one.
Repeat ad infinitum.
If this sounds familiar, your dev office might have become a feature factory. But what does this mean, how can you tell, and what should you do about it?
Working in a feature factory
Working in a long-standing feature factory can quickly get monotonous for developers. It’s always the same — churning out feature after feature, but without the sense of what good their work is doing.
Beyond the monotony, more troubles brew. Feature factories feature a lack of communication between teams. Features are handed to the next team, and then the next, without any sort of feedback.
Developers, as a result, find themselves disconnected from customers. Customer service isn’t sure what the developers were thinking, and so on.
It’s not just the team that suffers either. The software product suffers too. With no view of value or impact, solutions fall prey to feature creep. Users get crowded with bells and whistles they don’t necessarily want. And, often, important product maintenance and UX fine-tuning fall to the wayside.
Long-standing feature factories are bad for morale, bad for the software, and bad for business.
Why it happens
There are many reasons why a dev office might slip into feature factory territory from time to time.
A common reason simply is inexperience or lack of practice. Starting out, it’s tricky to balance creating your software, shipping it, adapting to new technology, and adapting to changing customer needs. Focusing on making features is more natural — and if that method becomes the norm, offices are on the way to becoming a feature factory.
Technical communication clarity is another common cause of the feature factory. Using terms like ‘customers’ and ‘users’ is to oversimplify the view of the people the software — and features — are for. As a result, developers end up making features without a clear view of just who they’re making them for (or why).
A final example of something that might cause the development office to become a factory of features is shiny object syndrome. This is where project managers, team leads or decision-makers get caught up in the excitement of the new. New tech means new features. Shiny object syndrome means chasing those new features — even when they aren’t needed.
How to tell?
So, what are the signs that the dev office has turned into a feature factory?
- No clear measurement or metrics
In a feature factory, developers don’t know how effective (or ineffective) their work has been. In other words, it’s unclear if the feature is useful for end-users. If there were any late-stage problems with it, and so on.
Deeper, developers may not even feel aware of who they’re targeting with their features. The desired customers aren’t outlined or discussed.
- Non-collaborative team dynamics
The way teams interact can also indicate a business with a feature factory. Feature factories have teams working in siloes. That is, there’s little to no communication across teams and departments. Everybody works on their one part, and send their work down the factory line to the next person.
- Big release practices
Big batch releases focused on releasing lots of features may also indicate a shift to a feature factory mindset. This is where, rather than releasing improvements incrementally, everything gets launched at once.
As such, the emphasis is on making lots of features for one big launch. There’s no (or little) tweaking or fine-tuning.
- Skewed priorities
In a feature factory, the focus tends to lie on what you can do, rather than what you should do to best provide value to the customer. This often takes the form of chasing the newest tech without analysing its fit, and of valuing quantity of features and code over quality.
How to improve
When you think you’re working in a feature factory, the natural question is what you can do to improve.
The answer lies in addressing the signs and causes. For example, you could:
- Boost communication between teams and departments. This allows developers to find out what’s popular and what isn’t.
- Make sure you’re writing effective user stories. These help dev teams relate back to the customer and think about the value of each feature.
- Set time aside to clear technical debt. When you aren’t squashing bugs and fighting bad code, you can spend more time focusing on the customer.
These are a few ideas to start you off. But there are plenty of different ways to promote a bigger view of your software. The idea is to avoid churning out features with no rhyme or reason.
More than features
There’s more to software engineering than churning out features. But at times, it can feel that these elements fall by the wayside.
So, remember to take stock now and then. What value and impact does your work have? Are you chasing shiny objects? Do you communicate with sales and customer service?
Sticking your head up and looking at the bigger picture helps you create more cohesive software solutions, with your user at the core.
Useful links
Feature creep: everything but the kitchen sink. Is your software guilty?
Customers, users, and the technical communication clarity problem
