In successful software development is it widely accepted that the best outcome is produced by autonomous development teams having their own product and a clear target. This means that a successful software development team can find out and to decide about how to change the product to deliver real value. The team’s product might be part of a bigger solution, but the team does not need to share the product with another team to reduce dependencies. They also have a clear product goal (could be addressed using OKR). This way a team feels responsible for their work and will deliver high quality features that meet the need of their products customers.
In contrast a lot of software development team are primarily feature factories. As a feature factory the team has little to no influence on the product as the product decisions are made by managers outside of the team. For a feature factory team, the output is more important than the outcome. Managers do not really ask the team to deliver features the team thinks the customer needs. Instead, they ask the team to implement the feature in the pace the manager estimated.
…
Less quality
One of the main difficulties of software development is delivering software of high quality. You can deliver cheap software with a high pace. Customer might buy it, but they will not stay if your product lack of quality. If you want a team to deliver quality, you need to get the team feel accountable for what they produce. In a feature factory where the team merely does what they have been told to do and not what they are convinced to be the right thing, the team will hardly deliver quality. The work produced will just be the output of the requirement. It will not be an outcome of high quality.
Less innovation
If a company uses its development teams solely for coding, they drop a big part of the possibility to innovate. Today, technology is at a point where customers can hardly imagine what is possible within the product. Therefore, engineers are a big source of innovation as they know what can possibly be done. In a feature factory environment, the development team has little influence on how the product evolves. The product change will be decided outside of the product team. In this case a company will not use the innovative potential a development team can deliver.
Less efficiency
The highest cost in product development is the work on production ready code. The more you can make sure that what you are going to build really is what will be needed afterwards the more time and money you save. A feature factory leaves out the part where the team is going to focus on what really will match the needs of a customer and will deliver a real value to the product. A feature factory team focuses on the forecasted output instead of the outcome. They need to deliver something fast instead of delivering the real thing a bit slower. Hence you do need more iterations to match customer needs, or you need to live with unhappy customers.
Less responsibility
We need teams of missionaries, not teams of mercenaries.[1]
Developing a product which fits the market you need teams of missionaries, not teams of mercenaries. If you give the decision about the product to the team, they will feel responsible for the product. A team that feels responsible for what they deliver will deliver a high-quality product. They will deliver you the innovation that is needed to stay ahead of your competitors and they will work efficiently as they focus on coding what is really needed and what really creates value.
Mercenaries will leave the team as soon as there will be any problem. Missionaries will stay with you through thick and thin times.
A feature factory team will maybe follow the directions given by managers, but they will not feel the pain of customers as well as colleagues. They just do what they’ve been told. No more, no less.
[1] https://www.svpg.com/missionaries-vs-mercenaries/