Skip to content

Commit 9ea67cb

Browse files
NewMexicoKidErinMBspier
authored
Create include-product-owners.md (#71)
* Create include-product-owners.md pattern. This was created at the Spring Summit 2017 in Geneva, Switzerland. * In 2021 this was adapted to the format requirements for the Pattern Template etc Co-authored-by: ErinMB <[email protected]> Co-authored-by: Sebastian Spier <[email protected]>
1 parent 434d91e commit 9ea67cb

File tree

2 files changed

+73
-1
lines changed

2 files changed

+73
-1
lines changed

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,6 @@ The below lists all known patterns. They are grouped into three [maturity levels
5757
* [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
5858
* [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
5959
* [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
60-
* [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*
6160

6261
### Maturity Level 1: Initial
6362

@@ -77,6 +76,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
7776
* [Code Consumers](patterns/1-initial/code-consumers.md)
7877
* [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md)
7978
* [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.*
79+
* [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
8080

8181
#### Donuts (needing a solution)
8282

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
## Title
2+
3+
Include Product Owners
4+
5+
## Patlet
6+
7+
Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.
8+
9+
## Problem
10+
11+
Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with InnerSource projects.
12+
13+
## Forces
14+
15+
* KPIs discourage Developers from contributing to others via InnerSource.
16+
* Product Owners have different priorities that may not align directly with InnerSource priorities. Product Owners are focused on their ROI in alignment with Product Management.
17+
* Product Owners may not be as focused on the longer-term benefits of InnerSource because many of their own metrics and goals are shorter lived.
18+
* Product Owners may not be aware of the benefits of InnerSource
19+
* Employees desire to grow their own circle of influence, which leads them to limited sharing of their own resources.
20+
* Some people lack understanding of the up-front impact and cost of InnerSource in terms of resources, because they are more focused on the efficiencies that it can provide.
21+
* Product Owners might not use Development tools and may therefore lack the opportunity to find out about InnerSource offerings and opportunities for collaboration and reuse.
22+
* Fear of loss of control.
23+
* Resistance to allow people to join and contribute.
24+
* Motivation: For the receiving Product Owners, there are big benefits of external contributions.
25+
* Motivation: Some are motivated to contribute because it is the only way that their desired feature will make it into the codebase.
26+
* Lack of motivation: If Developers don't see what's in it for them to contribute, they might not be highly motivated to help.
27+
28+
## Context
29+
30+
* Teams and individuals are not rewarded for software component reuse.
31+
* Motivations of the product(s) are not aligned with the InnerSource initiative.
32+
* Every product area has their own limited resource/budget.
33+
* Delivery deadlines are not movable.
34+
* Product Owners rarely make compromises regarding technical items in their area.
35+
* InnerSource changes resource distribution and requires up-front discussions, which require time allocation.
36+
37+
## Solution
38+
39+
* Talk with the Product Owners to understand their priorities. Prepare for this discussion by understanding their user stories, backlog, and roadmap if possible.
40+
* Ensure that Product Owners are aware of the benefits of InnerSource that they might care about most, including:
41+
- Reuse. Teams can avoid writing new software from scratch because they can leverage and/or existing code.
42+
- Savings of time and money. It may cost more for a team other than the original team to write it, but it costs less than writing it from scratch.
43+
- Staff augmentation for the receiving team.
44+
* Change the collaboration model on the product side. Bring the impacted Product Owners together to discuss the InnerSource project and choices related to resource allocation. Technical collaboration will result in better quality decisions. Overall resources cost could be lowered for some areas. Having the conversation builds trust and may result in evolution of the software component.
45+
* If possible, implement effective enterprise search.
46+
* Adjust KPIs to motivate people to collaborate and reuse. Work with leadership to get support.
47+
* Internally advertise opportunities for reuse and collaboration. This can be done with blogs, success stories, providing a searchable list of projects to work with, and other methods.
48+
* Create a champions program and have them identify project opportunities.
49+
50+
## Resulting Context
51+
52+
* Initial time investment is rewarded by the outcomes.
53+
* Product managers are now collaborating with one another.
54+
* Resulting development costs less overall.
55+
* Product owner KPIs might not change but reuse collaboration still occurs (a faster way to achieve them).
56+
* Product owners factor in InnerSource so they reach their KPIs more efficiently.
57+
58+
## Known Instances
59+
60+
* PayPal is looking into finding a search solution for their project Agora. They are collaborating with other teams pursuing a similar mission, eliminating redundancy and inefficiency regarding effort and tools.
61+
62+
## Status
63+
64+
* Initial (still missing Patlet and at least one Known Instance)
65+
* Created at the Spring Summit 2017 in Geneva, Switzerland
66+
67+
## Authors
68+
69+
* Silona Bonewald
70+
* Alex Bozic, Bloomberg
71+
* Erin Bank
72+
* Tim Yao

0 commit comments

Comments
 (0)