Skip to content

Generalize the maturity model pattern #536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
55 changes: 30 additions & 25 deletions patterns/2-structured/maturity-model.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,11 +4,8 @@ Maturity Model

## Patlet

Teams have started adopting InnerSource. The practice is spreading to multiple
departments. However, the understanding of what constitutes an InnerSource
project varies. The solution is to provide a maturity model to allow for teams
to go through a self check and discover patterns and practices that they are not
yet aware of.
The InnerSource practices are spreading to multiple teams and departments, however the understanding of what constitutes an InnerSource project varies.
Defining a maturity model enables teams to do a self-assessment and discover patterns and practices that they are not yet aware of.

## Problem

Expand All @@ -22,26 +19,37 @@ pain points that they are dealing with.

## Context

Several teams have started adopting InnerSource practices. The exact level of
understanding of the practice diverges between teams. The exact problems teams
run into diverge depending on the context and working environment of each team.
As a result the definition of what are important best practices in an
InnerSource project differs depending on each team.
* Several teams have started adopting InnerSource practices.
* The exact level of understanding of the practice diverges between teams.
* The exact problems teams run into diverge depending on the context and working environment of each team.
* As a result the definition of what are important best practices in an InnerSource project differs depending on each team.

## Forces

Teams sharing InnerSource learnings run into misunderstandings as they are not
aware of their respective level of InnerSource adoption.
* Teams sharing InnerSource learnings run into misunderstandings as they are not aware of their respective level of InnerSource adoption.
* Teams believe that "it's all about migrating to a shared software development [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just remove this line. It's too specific.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean just the line 30, right?

Interestingly the fits the discussion around what qualifies "ThinnerSource" in slack :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, line 30 🙂

* Teams are not aware of best practices that would help them solve issues that they run into in their daily doing.

Teams believe that "it's all about migrating to a shared software development
[forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges).
## Solution

Teams are not aware of best practices that would help them solve issues that
they run into in their daily doing.
For this pattern in particular it is important to note that adopters of this pattern will likely not use the maturity modal proposed here as is!
The context of most organization will differ to greatly to do that.
Hence you may take the proposed maturity model as a starting point if you like, but it is key that you adapt it to the needs and goals of your orgnization!

## Solution
Steps to implement:

1. **maturity mode definition**: Create a maturity model that fits the needs of your organization. Also consider the [Guiding Principles](../2-structured/document-your-guiding-principles.md) if you have defined those for your InnerSource program.
2. **team self-assessment**: Then ask teams to self-assess against that maturity model. You may even do a couple of these sessions together with a view teams, to observe and learn if the maturity model is easy enough to understand.
3. ... <what happens now? e.g. any re-assessments after some time, or suggested actions after the assessment, or anything else?>

Note that the path is part of the goal in multiple ways here:

Ask teams to self assess against the proposed maturity model.
* Defining your own maturity model allows you, the organizers of the InnerSource program, to increase your own clarity. e.g. you will realize what matters to you, what training capabilities you have internally, what material is available externally, etc
* You increase the trust in your initiative by allowing teams to go through the self-assessment at their own pace, and by opening up to feedback from them.
* The teams going through the self-assessment will likely have discussions, possibly even disagreements about some of the points in the Maturity Model. That is fantastic as it offers a great starting point for relevant discussions to increase their shared understanding of InnerSource.

Below we have defined a sample maturity model around 4 categories (Transparency, Collaboration, Community, Governance).
Make sure you adapt this model to fit your organization!

### Transparency

Expand Down Expand Up @@ -200,13 +208,9 @@ InnerSource comes with explicit roles. While in early stages some patterns may b

## Resulting Context

All teams are aware of available best practices.

Teams understand their level of InnerSource adoption.

Prior to adopting InnerSource as a working model, teams are aware of the
practices that are expected of them - both in the short term and in the
long term.
* All teams are aware of available best practices.
* Teams understand their level of InnerSource adoption.
* Prior to adopting InnerSource as a working model, teams are aware of the practices that are expected of them - both in the short term and in the long term.

## Known Instances

Expand All @@ -220,6 +224,7 @@ long term.
* Isabel Drost-Fromm
* Jorge
* Nerea
* Sebastian Spier

## Acknowledgements

Expand Down