InnerSourceCommons
diff --git a/‎product/01-introduction.md‎
Lines changed: 29 additions & 7 deletions b/‎product/01-introduction.md‎
Lines changed: 29 additions & 7 deletions
diff --git a/‎product/02-innersource-and-agile.md‎
Lines changed: 101 additions & 46 deletions b/‎product/02-innersource-and-agile.md‎
Lines changed: 101 additions & 46 deletions
@@ -1,12 +1,34 @@
 Welcome to the learning path section for product managers.
-After watching this segment, you will have a better understanding of how InnerSource relates to Agile development best practices.
-While we all strive for autonomous teams that can move in an independent way, it is clear that in an 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 themselves offer a helping hand.
+
+After watching 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 achive agility organizations strive for autonomous teams.
+However in a complex, interconnected world some dependencies cannot be avoided.
+InnerSource [provides an alternative](https://innersourcecommons.org/learn/learning-path/introduction/02/) 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 it's focus on written communication, InnerSource values are particularly helpful for teams moving to a remote first mode.
+Through its focus on written communication, it is well suited even for remote-first mode.
 
-In this Learning Path segment, 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 be better equipped to spot differences in culture but also in purpose of tools used.
+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.
 
-In the fourth part of the segment, you will learn more about the impact of InnerSource on capacity planning: Also with InnerSource there is no free lunch - host teams will have to be aware of mentoring efforts to get contributors up to speed and mentoring them through at least the first few of their contributions.
+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 analysing 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 organisation 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 having the option to provide teams that need the modification with a patch that suggests the modification can speed things up substantially.
+Typical complexity of modifications in that approach depends on the maturity of the organisation and the maintainability/ modularity of the code produced.
@@ -1,81 +1,136 @@
 # InnerSource and Agile
 
-You want to improve your product and deliver those improvements faster to customers.
+You want to improve your product and deliver faster to customers.
 You want to make stakeholders happy.
-InnerSource helps your team deliver value and maintain autonomy especially in a highly interconnected world.
+InnerSource helps your team deliver value and maintain autonomy in a highly interconnected world.
 
 
 ## Autonomous teams in an interconnected world
 
-* organisations try to deliver value to customers quickly
-* to do that lengthy roadmap synchronisation settings are to be avoided
-* often those discussions stem from team dependencies: Releases waiting for the testers, deployment waiting for time in the ops team.
-As a result, cross functional teams where testing happens close to development and those who build software own running the software have proven to be successful.
-* but there is another type of inter-team dependency:
-* however we live in an interconnected world: Software written today relies on many dependencies
-* Each source code dependency, each call to some service, each external dataset used boils down to a dependency between two teams.
-* What if you need changes made to such a dependency?
-   * Traditional options:
-      * submit a feature request and wait it out
-      * build a workaround
-      * if nothing else helps, escalate your issue
-   * added benefit of InnerSource:
-      * help with the solution
-
-* But team members working in each others repositories sounds like chaos?
-   * InnerSource comes with a set of roles and processes, contributions happen in a structured way
-   * each InnerSource project has a clear set of trusted committers with clear accountabilities that go beyond simply reviewing code.
-   * support for more autonomy by being able to fix upstream artifacts without sacrifycing quality due to a clear review process
-
-* Todays world moves towards a remote first culture - InnerSource has a focus on written communication and lends itself easily to remote first.
+Organisations try to deliver value to customers quickly.
+One common cause for delays are dependencies in the delivery process.
+As a result organisations prefer cross functional teams covering customer communication, design, implementation, testing and operations thus eliminating costly handovers.
+To achieve high performance, teams eliminate waste and re-use existing components.
+From a team perspective each reused component adds another dependency outside of the control of that team.
+The negative side of this optimisation is clear: The team depends on another team if they need changes in the component used.
+To be able to implement those often lengthy roadmap discussions are scheduled, sometimes leading to the need to optimize detailed priorities globally.
+In complex situations as much as in large organisations this leads to an increase in time needed to adjust to changing business needs.
+For very popular central components often there are so many requests coming in that one central component team runs out of capacity to implement all of the requested changes.
+
+In traditional organizations there are only two ways of making changes to dependencies:
+* Submit a feature request/ bug report and wait for the other team to prioritize that change and implement it.
+* Build a workaround to avoid the bug or locally provide the functionality needed.
+
+If none of those options is successful typically the issue is being escalated and decided at a higher hierarchy level.
+
+Neither solution is particularly satisfying.
+Looking at Open Source though there is an obvious solution: A team depending on a component becomes a contributing team and provides a helping hand to the host team.
+
+Now you may ask yourself: "Doesn't that lead to complete chaos where people randomly write into code repositories of teams they are not a member of?" 
+InnerSource comes with a set of roles and processes that bring clarity to what otherwise would indeed lead to chaos:
+* Each InnerSource project has a set of Trusted Committers with clear accountabilities that go beyond simply reviewing code.
+Trusted Committers set the rules for contributions.
+* Contributions happen in a structured way:
+   * Contribution intend is shared early to make sure the contribution fits within the Host projects' vision and scope.
+   * Progess is shared early so the host team has a chance to mentor the contributor and guide them on the path to a desired design and architecture.
+   That way frustration due to having to decline a contribution late in the process is avoided.
+   * Decisions and vital communication happens asynchronously to be able to work around differing meeting schedules of people in different teams.
+As a result contributing teams gain autonomy to fix upstream artifacts without sacrifycing the quality of the component that is being contributed to.
+
+As a side effect InnerSource provides teams with best practices that make working in a remote first culture easy.
+
+## Advantages of an InnerSource approach
+
+Instead of working in silos InnerSource fosters collaboration between teams.
+Much as in Open Source that means standing on the shoulders of giants: Instead of building every component locally InnerSource fosters reuse.
+It reduces the cost of reuse by providing a clear path to supporting the upstream team with the work of fixing bugs and implementing features.
+
+Much like in Open Source InnerSource fosters a thinking of combined forces: Components that all business units and product teams need as a foundation can be built together.
+As a result all the boats are rising together: Innovation created in one part of the organization can create benefits all over the entire corporation.
+With teams that are familiar with InnerSource the load to move this type of innovation forward can be shared by all teams that benefit from and depend on the resulting components and services.
+
+InnerSource gives your team the initiative and tooling to fix issues that block shipping features to customers.
+When done right maintenance of core components and services can be shared in a well structured way by a "virtual InnerSource team" that is larger than any specific product team.
+
+In advanced settings those involved understand the value of contributors working on simpler features that may not directly benefit their customers - under the condition that that frees the host team to work on more complex changes that contributors hava a business need for.
 
 
 ## Does InnerSource replace Agile?
 
-* short answer: No, not at all.
-* Instead they complement each other:
+Short answer: No, not at all. 
+Instead the two complement each other:
+
+Well factored and well tested code is one goal of any agile team. 
+In an InnerSource setting on-ramp times for team members but also for team-external contributors get shorter.
 
+Teams familiar with collaboration who avoid assigning tasks are in a good position to also deal with external contributions in a flexible manner.
+They also bring a mindset and communication style that works well for motivating contributors over whose priority they have no direct influence.
+Working with intrinsic motivation instead of directing work means that host teams have the tools to successfully collaborate with contributors.
+
+Teams pairing to work on problems are already comfortable with sharing progress early.
+There are two challenges moving to InnerSource from a pairing only culture: 
+The host team needs to make time for supporting contributors and schedule that into their planned work.
+In addition when crossing team boundaries it is often hard to find time slots for pairing - in those cases it should be complemented with asynchronous collaboration.
+To avoid frequent disruption, host team members often need to intentially plan their day more rigorously in InnerSource settings.
+Often it is simplest to set aside certain hours in the day or a day a week for mentoring contributions.
+Making that explicit at the team level takes a lot of pressure off the engineers trying to fulfil their own team goals but also helping out contributors.
+Another challenge with pairing is that it allows pairs to move very quickly together - often at the expense of writing important information down for the rest of the team.
+In an InnerSource setting it does take training to remember to bring all relevant decisions back to shared communication channels for both, host team and contributors.
+From a product perspective that does bring a lot more transparency to the development process.
+It also means that decisions that otherwise may have been taken at the engineering level only are now visible for everyone involved.
+
+Remember last time you insisted that your product be well tested, preferably with automated tests so deployments can happen frequently and without human intervention?
+This goal now helps with InnerSource as well: Contributions are much easier if contributors can check locally if their changes are safe.
+Tests also ensure that the host team remembers to keep the contributed functionality if they are reminded of the reason for it by a failing test.
+
+Remember last time you insisted on your team spending time to follow the goal of "leave code in a better shape than you found it"?
+That mindset helps in the InnerSource model: It makes sure that quality and co-hesion of code remains high even when there are multiple contributions from different sources.
 
-- How InnerSource and Agile complement each other
-   - Well factored and well tested code leads to faster on-ramp for agile teams, but also helps InnerSource allowing for faster on-ramp for contributors
-   - A focus on working together and not assigning individual tasks allows for easier on-ramp of contributors.
-   - Existing local pairing can make cross team pairing and sharing of work in progress easier.
-   - Existing test driven development means that confidence in contributions is higher.
-   - XP teams have a "leave the code in better shape than you found it" attitude - mitigates the risk of decline in quality or co-hesion of code when faced with multiple contributions from different sources.
 
 ## Common misunderstandings when coming from agile teams
 
-* Impact of language: InnerSource and Agile uses some of the same tooling - for different purposes.
-   - Product Owner needs to support and align on off-team contributions (rather than strictly work with the Host team).
-More to come on this in **InnerSource and Negotiation**.
-   - Issue trackers: In agile teams pure conversation with the customer.
-Only for planning purposes, essentially a replacement for sticky notes on a whiteboard.
-In InnerSource for a conversation with the customer, but also for communication between members of a team of trusted committers and contributors working on one common InnerSource component.
+InnerSource and Agile uses some of the same tooling - for different purposes.
+
+### Impact of overlapping language
+
+Issue trackers: In agile teams user stories are a conversation with the customer.
+Often the are put as sticky notes on a whiteboard.
+But also often they are stored in an issue tracker.
+As a result issue trackers are mainly perceived as planning tools, essentially a replacement for sticky notes on a whiteboard.
+In InnerSource, issue trackers serve for a conversation with the customer, but also for communication between members of a team of trusted committers and contributors working on one common InnerSource component.
 Issues in InnerSource become much more lengthy and wordy than in your average organisation.
+They also track the implementation history and detailed design decisions for a change.
+
+Code Reviews: In traditional organisations code reviews often serve auditing purposes.
 
-  - Code reviews: In traditional organisations those often serve auditing purposes and for quality control.
 They are done when development is finished.
 In InnerSource code changes are shared very early in the process, sometimes when nothing more than a rough sketch is done.
 The goal is to seek early feedback and mentoring.
 This is particularly helpful for teams that are on diverse schedules and cannot find any time for pair programming.
 Often teams have the aspiration that nobody walks alone - in reality though this often isn't much more than an aspiration never achieved.
 In particular where contributions cross team boundaries.
 
-  - Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow alogthe process of software creation.
+Tools used in InnerSource can formalize this ask for more than one human to be involved with any change.
+
+Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow alogthe process of software creation.
 As a result all communication needs to be in a place that everyone interested in the conversation can follow along: written, public, searchable and linkable.
-The goal is not to reduce disturbing others - the goal is to make all project conversations transparent.
+The goal is not to reduce distractions to others - the goal is to make all project conversations transparent.
+
 As a result direct messages and mails are to be avoided.
 In order to make following conversations easier for everyone, messages related to one InnerSource project should be tracked in one separate communication channel: The goal is not to reach every person in the team of the InnerSource project.
 The goal is to find a common shared room for everyone involved with the project where they can have discussions focused on that InnerSource project.
 
-
-* Focus on written communication does not mean verbal communication is disallowed.
+Focus on written communication does not mean verbal communication is disallowed.
 There still needs to be time for a shared cup of coffee.
-Make sure though that all project relevant decisions are kept in channels that everyone has access to.
-That also may mean to post-pone important project decisions until everyone is back from vacation or waiting for another day or two if those working in another country are now on holiday.
+Also solving problems together, pairing with others or in person hackathons are valuable to find solutions quickly.
+The team needs to make sure though that all project relevant decisions are kept in channels that everyone has access to.
+That also may mean to postpone important project decisions until everyone is back from vacation or waiting for another day or two if those working in another country are now on holiday.
+This is not only relevant for coding decisions, but also relates to general project mission, roadmap and direction.
+Without that information contributors will have a hard time understanding which contributions will have a good chance of getting accepted.
 
+### Impact of trust
 
-* Impact on trust: All discussions in InnerSource projects are visible to everyone in the company.
+All discussions in InnerSource projects are visible to everyone in the company.
 Blaming people for their errors, ridiculing them for their mistakes, talking behind their backs about what they did wrong is a sure fire way to kill that trust and leads to the failure of that InnerSource project.
-
+This is in particular important for anyone in a leadership or role model position.