Add introduction to product focused learning path. (#508)

* Add introduction to product focused learning path.

* Add segment about the relationship of agile and InnerSource

* Correct formatting to put each sentence on a separate line

* Apply suggestions from code review

Co-authored-by: rrrutledge <rrrutledge@users.noreply.github.com>

* Add more detailed outline for remaining chapters.

* Add discussion of moving maintenance to the host team

* Update product/02-innersource-and-agile.md

Co-authored-by: rrrutledge <rrrutledge@users.noreply.github.com>

Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
Co-authored-by: rrrutledge <rrrutledge@users.noreply.github.com>

Author: 3 people

product/01-introduction.md

@@ -0,0 +1,12 @@
+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.
+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.
+
+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 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.
+We will also look at the additional negotiation possibilities that InnerSource brings - keeping the balance of Give and Take.  

product/02-innersource-and-agile.md

@@ -0,0 +1,81 @@
+# InnerSource and Agile
+
+You want to improve your product and deliver those improvements faster to customers.
+You want to make stakeholders happy.
+InnerSource helps your team deliver value and maintain autonomy especially 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.
+
+
+## Does InnerSource replace Agile?
+
+* short answer: No, not at all.
+* Instead they complement each other:
+
+
+- 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.
+Issues in InnerSource become much more lengthy and wordy than in your average organisation.
+
+  - 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.
+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.
+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.
+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.
+
+
+* Impact on trust: 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.
+
+

product/03-capacity-planning.md

@@ -0,0 +1,24 @@
+# InnerSource and capacity planning
+
+
+## Setting expectations
+
+* write down when contributors can expect to hear back from you
+* hearing back does not equal merge of pr
+* write down which path you prefer for getting a ping if contributors don't hear back from you
+
+
+## Small vs. large changes
+
+* smaller changes easier to handle, but for small changes that belong together there should be a place where that context is communicated
+* "patches welcome" is a nice way out of the "feature request" mental model - but it does still have a cost which is called time to mentor contributors
+
+
+## Increasing the team around your InnerSource project
+
+* contribtors can become team members and thus increase the time and number of people helping you
+* needs a long term vision
+* host team needs to have that in mind when mentoring contribtors.
+
+
+

product/04-negotiation.md

@@ -0,0 +1,43 @@
+# InnerSource and negotiation skills
+
+## small vs. large changes
+
+* smaller changes tend to be accepted faster
+   * easier to review
+   * less impact - both, positive and negative
+   * faster to integrate
+   * ad-hoc for those often works
+   * sweet spot for drive-by contributions without much coordination
+   * typically don't cause a lot of friction, typically don't cause escalation
+
+* but sometimes large changes are needed
+   * learned ad hoc working model breaks
+   * escalation quickly happens
+   * needs coordination:
+     * when does the host team have time for mentoring?
+     * when does the contributor have time for being mentored?
+     * does the change fit into the host team vision of the project?
+     * avoid sending large patches - frustration if they are declined is high on both sides
+   * coordination not at tech and business level separately but preferably with everyone at the same table - think of one async communication platform for the InnerSource project.
+
+## Coordination
+
+* in particular larger changes need coordination
+   * make sure host team has time for mentoring
+   * anticipate longer waiting time otherwise
+
+* coordinate common understanding of the roadmap and vision of the InnerSource project
+* make sure that design, architecture and performance requirements are clear to everyone
+   * essentially everything that is clear implicitly when working in a local team
+   * make time for automated quality checks
+
+* When coordinating think out of the box:
+   * contributors can make all of the tedious but smaller and easier fixes, while the host team thus has more time for the more complicated changes that the contributors need
+
+* As a host team product owner you need to understand overall business priority in particular at times where more contributions are flowing in than your team can handle
+
+* Needs an understanding where contributions make sense
+   * time invest for contributors worthy?
+   * mentoring invest for host team compared to "simply do it yourself quickly"
+   * is there a chance the contributor stays active long term?
+

product/05-shared-ownership.md

@@ -0,0 +1,65 @@
+# Options for shared ownership
+
+* if everyone owns it, nobody takes care anymore
+* if everyone can make changes, surely the result will be a mess
+* I don't want to be forced to accept all sorts of changes from contributors.
+
+## Ownership mis-conceptions
+* just because you receive a contribution does not mean your team has to accept it
+   * Support your team in communicating project vision, help them in situations that are tricky - think turning down contributions
+   * Support your team by helping them come up with a clear vision for the InnerSource project
+   * Understand that when receiving contributions the review and menoring cycle is important, needs time and capacity but improves quality of the project
+   * when contributing code understand that the review cycle is not a last stage quality gate but a way to guide the engineers of your team to results faster
+* when in a host team and flooded with contributions
+   * help your team understand that contributions may come with different priorities depending on overal company strategy
+   * help your team by taking on tasks like initial contribution triage: Time to first response for contributors is crucial.
+You can help your team by communicating to contributors if integration of the change takes a bit longer.
+   * When faced with multiple larger contribution requests help your team by negotiating with other teams when the best time to work on these contributions is.
+Often that is still way faster than your team doing all the work on their own.
+But in particular first time contributors may need some hand holding - in particular for larger changes.
+Coordinating the timing around that mentoring can be a big help for your team.
+* "But I could simply fork" ... a misconception where potential guest teams believe that simply copying the code would be faster.
+In the short term that is true.
+In the long run it means added maintenance.
+As a product person you can help your team understand why contributing changes to the project you depend on is in the best interest of the business: Less work overall.
+Maintenance for the long term is taken on by the host team.
+
+## InnerSource governance levels
+
+* InnerSource comes with different best practices.
+Governance for InnerSource projects - much like in Open Source may vary substantially though.
+
+* Best practice: Make all your assumption explicit:
+   * Which response time should contributors expect, so they know when to ping you?
+   * Which communication channels should contributors use to get in touch with the project?
+   * Which communication channels should contributors follow to learn what's going on in the project?
+   * But also: Which governance level should contributors expect from your project?
+
+* Governance level? There's at least three, sometimes four:
+   * Source code is visible to everyone, but we don't have time to mentor contributors.
+Send us changes as feature requests or bug reports only.
+   * Source code is visible to everyone, plus we have set aside some time for mentoring contributors.
+Feel free to send us changes as pull requests. We appreciate getting those early, even as drafts so we can help you avoid taking the wrong turn early.
+   * As above, but we are open to the idea of sharing write access.
+This is particularly helpful for cases where there is a long term relationship with contributors.
+Collaborating over longer periods of time the host team will develop trust in contributors understanding the goals of the InnerSource project.
+Sharing write access can then be a way to remove the review bottleneck.
+   * As above, but also share control over who gets write access next.
+Result from that increased trust will often be more committment from those that received the trust.
+
+* Each governance level needs different approaches to collaboration and coordination that may have an impact on how fast the project moves forward:
+   * More sharing means an increased need for communication and co-ordination.
+   * Sharing accountability can slow down decisions.
+   * Sharing more accountability also has an impact if your performance reviews still happen in a traditional hierarchical way.
+Impact on performance reviews: InnerSource moves some of the energy you spend developing outside of your own team.
+That means you are losing some level of control.
+You are also losing direct oversight. As a result performance feedback for InnerSource contributors needs to take the perspective of the host team into account.
+
+## "You build it, you run it" in settings with high sharing levels
+
+* Collaborate on and share only the parts that are the same accross teams - keep operations local.
+Essentially work towards modularization of your code.
+* Alternatively work with contract tests to avoid API breakages.
+* Work with internal service level agreements, make contributors sign up to warranty periods.
+
+

product/06-relation-to-open-source.md

@@ -0,0 +1,14 @@
+# Relation to open source
+
+* So you're now an export on InnerSource - where's the line to when to switch to Open Source?
+
+* The practices are very similar
+* Visibility and who can participate is limited in InnerSource
+* There are tax implications for InnerSource collaboration that do not exist for Open Source
+
+* The concept of building a common platform together and competing on top of that is core to Open Source as well.
+* What's more important though: InnerSource gets you into a habit of thinking about moving changes and thus maintenance one level up into your dependencies.
+That same habit can help you move changes upstream into Open Source projects that you depend on.
+* Thinking through the governance levels for InnerSource also helps you understand that not all Open Source projects are born the same.
+As a result you may want to take governance levels of Open Source projects which offer similar functionality into account when deciding which one to adopt in your tech stack.
+

product/outline.md

@@ -43,7 +43,7 @@ Challenges with InnerSource and agile (these challenges form the basis for the r
    - Common fears (like losing control) and counter measures
    - Same phrase - different meaning: How issue trackers and code reviews are used differently in InnerSource projects than is common in the industry.
    - The impact of transparency: How InnerSource depends on trust, what to avoid to keep trust alive.
-   
+   - written first is not to avoid verbal communication or to move everything into DMs or long winded email threads
 
 InnerSource and capacity planning