Skip to content

Latest commit

 

History

History
52 lines (30 loc) · 3.2 KB

Pattern 03 - Involve Teams in IS Implementation.md

File metadata and controls

52 lines (30 loc) · 3.2 KB
Raw

Pattern 3 - Involve Teams in IS Implementation

Title

Involve teams in IS implementation (S3)

Patlet

Organizational policies (KPI's and incentive structures) disincentivize people from contributing to InnerSource. Involving key teams such as security, engineering, and architecture in the early phase of implementation can prevent blockers appearing at a later stage and mitigate the problem of local optimization.

Problem

Organizational policies (KPI's and incentive structures) and politics create a culture of local optimization where mid-level managers and teams are disincentivized from information sharing and collaboration.

Context

  • Large organization's 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 a silo-thinking which in turn prevents widespread adoption of IS across organization.

Forces

  • The existence of multiple BU's complicates creation of collaborative networks across organization.
  • 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

  • Involvement of diverse stakeholders can be ensured by the InnerSource team working closely with security, HR, compliance, engineering, and internal customers (such as R&D) to influence the general approach and create an additional avenue for InnerSource (P01, P04, P08, P14, P18, and P23).

Resulting Context

  • InnerSource becomes a natural part of the development process and empowers teams to use InnerSource as a tool where it is beneficial.

  • In P04's organization this led the central engineering system team to extensively leverage InnerSource for all tooling and made them consider InnerSource as a scenario in the processes as well (P04).

  • Helps to find common solutions to common problems from the teams instead of having fragmented ad-hoc solutions (P23).

Limitation/Blockers

  • Steep learning curve leading to build-up of frustration in the early phases and a mismatch between expectations and reality (P04).

  • Strategy will work for a small organization not a large one with multiple business units (P11).

  • Extra communication efforts needed to organize people from different teams (P08).

  • If adoption is bottom-up IS will not scale beyond the first one or two layers of the organisational structure (P20).

Known Instances

  • This pattern has been identified by eleven (P01, P03,P04,P08,P09,P10,P14,P18,P20,P23, and P25) panellists to have been implemented in their organisations.