Can a "feature factory" be "Agile"?

You may have heard the term “feature factory” thrown around in certain circles. It’s usually a derrogatory term meant to convey a team, or company, that focuses on building as many features as possible, as quickly as possible, rather than focusing on business outcomes or customer demands.

It is probably assumed that those concerns (business outcomes and customer demands) are handled at a different level of the organization.

To some degree or another, it’s likely that many of you have worked on a team that could be described this way. Maybe you worked on a Scrum team, where the backlog was defined by a BA outside the team, and the team was only measured on metrics such as story point velocity.

So can such a team, a “feature factory”, be “agile?” If you find yourself on such a team or in such a company, and you want to be more agile, is there any hope for you?

My simple answer: Yes and no.

Let’s start with the “no” part because that’s pretty straight forward. The Manifesto for Agile Software Development contains four values, one of which is:

Customer collaboration over contract negotiation

If your team never interacts with customers (as is typical among “feature factories”), it is impossible to engage in customer collaboration.

A second likely casualty in such factories is “Responding to change over following a plan”, as the feedback cycles are often so large (months in length) that often all you, as the implementation team, has access to is a (possibly outdated) plan in the form of a backlog.

So if that’s the bad news, is there good news?

There’s still room for local optimization of agile processes. Even if you don’t have direct access to customers, and even if you’re required to build features out of context, you can still strive for technical excellence, and technical agility.

You should still be able to retrospect, and pursue technical excellence, design software according to SOLID principles, WET/DRY, use TDD, trunk-based development and Continuous Deployment.

The sad part is that: even if you achieve technical excellence in all of these areas, you may still be efficiently shipping technically excellent, but utterly meaningless features. At the very least, it will be good experience, and may help land a better job, at a more holistically agile organization in the future.

If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.