After completing this segment, you will have a better understanding of how InnerSource speeds up product development. We will also cover how it relates to Agile development best practices.
To achieve agility, organizations strive for autonomous teams. However, in a complex, interconnected world, some dependencies cannot be avoided. InnerSource provides an alternative to "wait it out", "build workarounds" and "escalate": Teams that need modifications in their dependencies can offer a helping hand. InnerSource facilitates cross team collaboration. Through its focus on written communication, it is well suited even for remote-first mode.
In this section, you will learn where Agile development and InnerSource use similar terminology and even technology - but differ substantially in the details. Instead of running into common misunderstandings, you will benefit from knowing the differences in culture but also in purpose of tools used.
You will understand the impact of InnerSource on capacity planning. Also with InnerSource there is no free lunch - host teams need time for mentoring contributors. We will also look at the additional negotiation possibilities that InnerSource brings - keeping the balance of Give and Take.
But let us start with a brief example. Imagine you are building a lovely new music app. In order to understand how your users are interacting with the app you start collecting some interaction logs. Over time, you dig deeper when analyzing those, feeding your learnings back into development. Now, imagine another team bringing content into your application also has a few needs - they may want to reward content creators based on how many users they reached. So them, too they start using your collected logs. But they need some additional analysis steps that you hadn’t thought of at first. They are now faced with a challenge: Build a workaround, or go through your backlog to get their request prioritized. With InnerSource they will have a third option: Make the changes themselves - with your help. Sure, that may be slower than if you had made the changes. But it will still be faster than waiting for you to get around to making the modifications.
In an ideal InnerSource organization you can scale that up even further: Remember the last time you had to make cross cutting concern modifications across your entire platform? When going the "put it into the backlog of each team" this often feels like it’s dragging on forever. On the other hand, it speeds things up substantially to provide those teams with a patch that implements the modification. The complexity of modifications in that approach depends on the maturity of the organization and the maintainability/modularity of the code produced.