How setting the right goals and focusing on the user can help you break free from the feature factory.
Unfortunately, we keep hearing very critical voices regarding agile methodology and Scrum. Software developers or managers question why agile software development should be better than the previous way of working, which delivered steady results and brought them to the goal. But, too often, agile methods such as OKR or Scrum are implemented incorrectly or are operated in organizations and environments that prevent an agile way of working. The result is often mistrust against those methodologies, meeting overhead and uncontrollable feature factories.
But what are feature factories and how can we break out of them? Is Scrum the most efficient way to work in a team? Should we really all rely on Scrum and agility?
What is the feature factory?
Feature factory is a term that describes how a team works. In a feature factory, the team has little influence on what is implemented. The team is only used by the organization to implement tickets, but not for the actual exploration of the product vision. This leads to a lot of knowledge being lost or not being available in the team at all.
Marty Cagan once said, “… if you’re just using your engineers to code, you’re only getting about half their value.” And that’s exactly what the Feature Factory does. But that is not the only disadvantage of a feature factory. The lack of knowledge about the product and the lack of participation in the discovery of new product features also makes products visibly worse in the feature factory. Because feature factories are often an “agile” part of an otherwise plan-driven organization, the market risk also increases, because there is a risk that development will not be exploratory and thus the product-market fit will not be achieved.
For me, the biggest negative suitability of the feature factories is that the team only does pseudo-Scrum and thus does not get to know the actual advantages of the agile way of working. The developers are quickly disappointed by the pseudo-agile way of working and condemn Scrum.
However, most of them do not know that the whole thing is based on the “garbage in garbage out” principle. In this case, it must also be said that working with Scrum brings in very little positive benefit, which is offset by the additional meetings and ceremonies. That is why I often understand the frustration of those who sit in the feature factory very well.
The Waterscrum-Anti-Pattern
The Waterscrum Anti-Pattern is a very common agile anti-pattern. It describes how an agile method, e.g. Scrum, is used in a plan-driven organization. This very often results in a feature factory. In this case, Scrum is most likely not the best and most efficient way to conduct the work.
How can this anti-pattern be prevented and how can we break out of the feature factory?
There are several approaches to break free from this feature factory, which can also be combined.
Often the Waterscrum Anti-Pattern is a step in the agile transformation of a company. If the agile transformation has not yet been completed or has just been started in development, then this anti-pattern can exist. In this case, it is important to drive the agile transformation forward. Strengthen the product owner in his position and, above all, involve him and the team in all process steps before and after development.
To address the lack of focus on discovery and the lack of exploratory approach of the team, Scrum Master and Product Owner should think about introducing a dual track.
If a full dual track cannot be introduced, at least the discovery of new features needs to be done regularly with the whole team. The team should be actively involved in the discovery and implementation of new features. For this purpose, the refinement of the tickets should not only be a pure checking of the Definition of Ready (DoR) and the acceptance criteria, no, the team itself should explore the features and work out the acceptance criteria together with the product owner = “discovery”.
Agile methods such as OKR are also a suitable method to take the other internal and external stakeholders into account and include them in the agile product development. OKR breaks down barriers and interfaces between departments. When OKR is used correctly, teams set goals along the value stream and not per department. This brings the teams closer together and they work together on the value stream. This in turn eliminates the feature factory and the waterscrum antipattern.
Read more here.
But not only setting the right goals: is important to break out of the feature factory. It is at least as important that the product has a good product vision, and that this product vision is well communicated by the product owner to the team and the whole company. The team and the product owner need to know why the product or the product feature is important and shape this why together. Only if every team member knows the vision, a product development strategy can be derived from this vision. Based on this strategy, good sprint goals can be created, outcome-oriented work can be done and the feature factory can be left behind.
Conclusion
Several methods and steps can and should be considered in order to leave the feature factory. It is important to enable the team to work independently on the product vision and strategy as a product team. Software engineers should do much more than just program, they should be fully involved in product strategy and discovery.
