Skip to content

Latest commit

 

History

History
49 lines (31 loc) · 3.65 KB

Pattern 02 - Create a collaborative environment.md

File metadata and controls

49 lines (31 loc) · 3.65 KB
Raw

Pattern 2 - Create a collaborative environment

Title

Create a collaborative environment (S2)

Patlet

Organizational policies and politics create a culture of local optimization which inhibits collaboration. This is resolved by the creation of stakeholder boards, guilds, developer exchanges, cross-team pairing, collaborative decision making via RFCs, and knowledge sharing forums.

Problem

Organizational policies (KPI's and incentive structures) and politics create a culture of local optimization where mid-level managers and teams focus primarily on achieving their own objectives; this means that information sharing and collaboration are not a priority for these organizational units, or this could even be perceived as being at conflict with the team's objectives.

Context

  • Large organizations with multiple autonomous Business Units (BU's) lead to the formation of "baronies" in middle and lower management.
  • The incentive and KPI measures in place do not consider InnerSource contributions by teams and this leads to silo-thinking which in turn prevents widespread adoption of IS across organization.
  • A highly politicized and top-down environment could also discourage people from taking the initiative to explore InnerSource.

Forces

  • Another key cause that hinders collaboration and sharing of code is a sense of "didn't build it here" amongst teams.
  • Lack of trust between teams over the maintenance of a shared solution which can be critical to one team while non-critical to another (P07).
  • Middle managers (Technical owners and Project managers) face pressure to keep their teams happy while simultaneously meet deadlines (P04).
  • Ignorance of costs associated with a bespoke solution such as licensing, onboarding, training, and maintaining can cause teams to favor local optimization (P10).
  • Hours spent on development needed to be booked with existing projects under different BU's. This led to ambiguity around booking hours spent on IS projects (P11).

Solutions

  • The creation of an ISPO/OSPO/Technical Committee (P01, P04, P08, P11, P23) which acts as a support mechanism and provides representation to stakeholders such as developers, agile coaches, engineers, and senior management. The ISPO/OSPO can work in a decentralized fashion by providing company-wide guidance but allowing teams to lead the InnerSource implementation in their area (P04). The ISPO/OSPO has specialized InnerSource roles such as advocates, community managers to enhance collaboration (P11).
  • Modifying and consolidating code management tools (e.g., GitHub) to facilitate collaboration between teams (P08, P23).
  • Creating dedicated communication channels such as in MS Teams channels, digital events, webpages in intranet where people can get support and exchange knowledge (P14).
  • Face-to-face conference of stakeholder representatives to plan InnerSource implementation and sustenance (P10).

Resulting Context

  • The combination of the above solutions will result in increased collaboration and a shared understanding of InnerSource across the organization.
  • Praise and encouragement by the ISPO/OSPO/Committee will motivate contributors.
  • Collaborative code management tools will enable developers to InnerSource their code and contribute with ease.

Limitation/Blockers

  • Extensive communication must be done with senior management to bring different parts of the organization, such as the developers and technical committee, on board (P08, P11).
  • Lack of a specialized role who can train developers in InnerSource (P11).

Known Instances

  • This pattern has been identified by seven (P01,P04,P08,P10,P14,P20,and P23) panelists to have been implemented in their organizations.