Skip to content

Commit f16ca29

Browse files
authored
Merge pull request #473 from InnerSourceCommons/product-segment
Create outline for product focused learning segment
2 parents f39994c + 869060b commit f16ca29

1 file changed

Lines changed: 79 additions & 0 deletions

File tree

product/outline.md

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
# Audience
2+
3+
While the content of this segment can be intersting to engineers in order to help their teams better navigate business decisions related to InnerSource the core audience are people in your team and across your organisation that deal with product development. The goal of this segment is to help you understand how InnerSource can help interdependent teams resolve requirements without syncing work to the point where both teams operate in lock-step.
4+
5+
Based learnings and best practices of successful, global Open Source projects this training shows you ways to increase collaboration and reduce waste by consollidating work on the shared technological basis.
6+
7+
# Takeaways
8+
9+
After going through this segment, you will:
10+
11+
* understand how Agile software development relates to InnerSource:
12+
* Which problems does InnerSource address that cause issues in typical agile teams?
13+
* "wait it out", "build workarounds", "escalation" vs. "help with the solution"
14+
* cross-team collaboration
15+
* remote first teams
16+
* In what aspects does InnerSource differ from agile or traditional software development - in particular when the same terminology and technology is used? (Think "Issue tracker for backlog/ board management vs. issue tracker for communication", "code review as quality gate vs. continuous code review as a conversation").
17+
* understand the impact of InnerSource on capacity planning when receiving features as pull requests as opposed to features requests: There is no free lunch - while InnerSource reduces the amount of work for the host team, mentoring contributors does cost time.
18+
* understand additional negotiation possibilities that InnerSource brings - keeping the balance of Give and Take with InnerSource
19+
20+
# Outline
21+
22+
InnerSource and Agile
23+
24+
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.
25+
26+
- Issues InnerSource solves
27+
- avoid lengthy roadmap syncronization discussions: "help with solution" instead of "wait it out" or "build workarounds"
28+
- resolve cross dependencies without compromising autonomy, code ownership and quality
29+
- better support for remote first by higher focus on written communication
30+
31+
32+
- How InnerSource and Agile complement each other
33+
- 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
34+
- A focus on working together and not assigning individual tasks allows for easier on-ramp of contributors.
35+
- Existing local pairing can make cross team pairing and sharing of work in progress easier.
36+
- Existing test driven development means that confidence in contributions is higher.
37+
- 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.
38+
39+
40+
Challenges with InnerSource and agile (these challenges form the basis for the remaining segments in this section).
41+
42+
- Common mis-understandings
43+
- Common fears (like losing control) and counter measures
44+
- Same phrase - different meaning: How issue trackers and code reviews are used differently in InnerSource projects than is common in the industry.
45+
- The impact of transparency: How InnerSource depends on trust, what to avoid to keep trust alive.
46+
47+
48+
InnerSource and capacity planning
49+
50+
- Small vs. large changes
51+
- Planning for mentoring
52+
- Contributions as long term investments in your upstream InnerSource project
53+
Representing in roadmap.
54+
55+
The need for negotiation skills in InnerSource projects
56+
57+
- Small vs. large changes - why smaller changes are easier to integrate ad-hoc than large refactorings
58+
- Best practices for integrating large changesets
59+
- Coordinate a common understanding of the InnerSource project roadmap
60+
- Up-front product and engineering design review
61+
- Coordinate the timing of larger contributions
62+
- Unconventional solutions to priority conflicts
63+
- Communicate the need to think in contributions instead of building workarounds.
64+
65+
66+
Options for shared ownership
67+
68+
- Introduce InnerSource governance levels
69+
- Governance levels pattern
70+
- Implications of each level on product management
71+
- Common hurdles (line management, performance review setups)
72+
- Advantages
73+
- Commons issues wrt. operations and solutions
74+
75+
76+
Relation to open source
77+
- Governance levels in open source and their impact on your adoption decision
78+
- Parallel of upstream participation to InnerSource
79+
- Gaining by sharing aspect of open source

0 commit comments

Comments
 (0)