Agile feature teams vs. inner source

Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.

The answer to such complaints is usually to set-up feature teams, which bring together different skills and knowledge about the current architecture. A feature team gets to implement a particular feature, with people on the team collaborating closely while focusing on a different technical aspect each, usually a different tier in the architecture. The idea is that by focusing on and feeling responsible for a particular tier or technical concern, developers will be able to implement a feature well without getting in the way of other features and without degrading architectural integrity and component quality.

Sadly, setting-up feature teams does not say anything yet on how to have and evolve an agile architecture, because feature teams don’t say anything about how the people on the different teams should collaborate to maintain architectural integrity. All it says is that in the implementation of a feature, there should be adequate knowledge to implement the feature well: A well-intentioned call to arms, but without the arms. Fortunately, there is an answer to this collaboration across silo boundaries, and it is called inner source.

Inner source (software development) is the use of open source best practices within a company to tear-down and collaborate across silo boundaries. The methods of inner source help you define communities of developers for important components, frameworks, and platforms, so that these developers can each achieve their goals, for example, implementing a feature well while maintaining the quality of the involved components. Fortunately, inner source is not a new method here to replace agile methods, but can be combined with about any other method, as long as that method is willing to let go of any overbearing control regime. So, fortunately, it can be agile methods and inner source rather than agile methods vs. inner source.

If you are curious about inner source software development, the inner source tag on this blog can give you a first idea about it.