Dirk Riehle's Industry and Research Publications

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.



  1. allan kelly Avatar

    Thanks Dirk,
    I didn’t know the term Inner Source but I did recommend an “Internal open source model” to clients earlier this year, and I’m glad to say they have gone someway towards its adoption.

    I’ll jeep my eyes open for more on Inner Source.

    1. Dirk Riehle Avatar

      Sweet! Yes, I think (obviously ;-)) that this is an important step in software development. Keep us posted!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Posted on

Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use