Skip to content

outline.md

Latest commit

 

History

History
79 lines (56 loc) · 4.73 KB

outline.md

File metadata and controls

79 lines (56 loc) · 4.73 KB

Audience

While the content of this segment can be interesting 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 organization 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.

Based learnings and best practices of successful, global Open Source projects this training shows you ways to increase collaboration and reduce waste by consolidating work on the shared technological basis.

Takeaways

After going through this segment, you will:

  • understand how Agile software development relates to InnerSource:
    • Which problems does InnerSource address that cause issues in typical agile teams?
      • "wait it out", "build workarounds", "escalation" vs. "help with the solution"
      • cross-team collaboration
      • remote first teams
    • 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").
  • 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.
  • understand additional negotiation possibilities that InnerSource brings - keeping the balance of Give and Take with InnerSource

Outline

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.

  • Issues InnerSource solves

    • avoid lengthy roadmap synchronization discussions: "help with solution" instead of "wait it out" or "build workarounds"
    • resolve cross dependencies without compromising autonomy, code ownership and quality
    • better support for remote first by higher focus on written communication

  • 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.

Challenges with InnerSource and agile (these challenges form the basis for the remaining segments in this section).

  • Common mis-understandings
    • 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 direct messages or long winded email threads

InnerSource and capacity planning

  • Small vs. large changes
  • Planning for mentoring
  • Contributions as long term investments in your upstream InnerSource project Representing in roadmap.

The need for negotiation skills in InnerSource projects

  • Small vs. large changes - why smaller changes are easier to integrate ad-hoc than large refactorings
  • Best practices for integrating large changesets
    • Coordinate a common understanding of the InnerSource project roadmap
    • Up-front product and engineering design review
    • Coordinate the timing of larger contributions
  • Unconventional solutions to priority conflicts
  • Communicate the need to think in contributions instead of building workarounds.

Options for shared ownership

  • Introduce InnerSource governance levels
    • Governance levels pattern
    • Implications of each level on product management
  • Common hurdles (line management, performance review setups)
  • Advantages
  • Commons issues with respect to operations and solutions

Relation to open source

  • Governance levels in open source and their impact on your adoption decision
  • Parallel of upstream participation to InnerSource
  • Gaining by sharing aspect of open source