InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
745 stars 183 forks source link

Starting discussion about a Maturity Model #116

Closed dicortazar closed 4 years ago

dicortazar commented 5 years ago

Hey, I'd like to share with all of you our previous work in Maturity Models.

Work done by Jorge from Entelgy, Nerea from Zylk, and Daniel from Bitergia.

Key process AREAS / Maturity LEVELS ACCIDENTAL (L0) EXPLORATION (L1) ADOPTION (L2) EFFICIENT (L3) SURVEY MAPPING
TRANSPARENCY
Plans & Products Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization. Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started.
Shared roadmap.
Stakeholders can contribute to some plans or products There is an standard process for collective product and plans definition
Development Process & Tools Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside development team. Siloed development teams. Development teams use shared code repositories, internally.

Some teams develop their own CI process, using non corporate or standard CI tools.

There is no code review process defined, although some projects teams do it internally.
The organization sponsors and promotes a shared repository for collective knowledge

Some teams develop their own CI process, using corporate CI tools. There are CI environments.

Code review process defined, and used by some projects. Code review is sometimes done by external team members.
Most teams develop their own CI process, using corporate CI tools. There are CI environments.

Code review process defined, and used by some projects. Code review is usually done by external team members.
Decisions Decision-makers often withhold data and resources without explanation Materials that are part of decision-making practices become available for review after decisions are finalized People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding.

Materials that are part of decision-making practices are available at defined project milestones
People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses

Materials that are part of decision-making practices are continuously accessible during work processes
Helpful Resources Individuals and teams neither contribute to nor draw upon a shared repository of knowledge Individuals and teams release project materials for review internally, after they've finished their work

Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories

Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others".
Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols

Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope
Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols

Individuals and teams who must withold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them
Stories Individuals and teams are comfortable sharing stories about successes, but not about failures Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols
COLLABORATION
Channels for Providing Feedback There are no processes nor stablished channels.
Some members of the organization share materials via private channels or discussions.
The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them

Some members of the organization share decision-making materials unformally using unofficially platforms

Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work
The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions

Members of the organization share decision-making materials on officially sanctioned platforms
Members of the organization share materials openly via multiple channels and methods for feedback

Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback
Leadership Command & control culture, within a highly hierarchical organization. Some leaders are open to receiving feedback and creating an environment where people feel safe providing it Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it

Leaders show passivity about understanding whether all members feel empowered and enabled to share

Organization encourages leaders to actively seek voices not present in dialog out for inclusion
Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate
Organizational and Functional Structure Working groups tend to be static in terms of membership and skill sets Cross-functional teams exist, but team roles are often unclear and governance structures are vague Cross-functional teams are common, and teams post their roles and goals publicly Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together
Contribution Completly siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams Members of the organization and teams collaborate but frequently say it's "too difficult"



Teams infrequently revisit the outcomes of their collaborations
Members of the organization and teams actively seek opportunities to collaborate

Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default
Members of the organization collaborate both internally and externally in ways that benefit all involved

Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default
COMMUNITY
Sharing Policies No sharing culture nor written policies. Some members of the organization unite to define values and principles, but are not clearly supported when they do Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often

Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions
Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats
Feel part of the Organization Low engagement, no collaboration and people do not feel comfortable sharing with others. Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains

People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment
Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution

Leaders demonstrate dedication to the organization's shared values
The organization is proactive in telling members that it benefits from their contributions; as such, members demonstrate shared consciousness and empowered execution, and feel a sense of responsibility to the community

Leaders understand that they grow by helping others grow, and they mentor junior members of the organization
Governance
Rewards No rewards Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded. Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards. The community is responsible to decide who has to be rewarded.
Monitoring Policies No existing monitoring policies Some people start using metrics for their own needs at their own hierarchical level Existing process at the organization Clear rules and processes in the use of metrics with specific training and monitoring in place
Support and Maintenance Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team There are rules and regulations to formalize the support on the product, given by a dedicated supporting team There are rules and regulations to formalize the support on the product, given by a mature community
Culture Silos Reactive Contributive Activist
InnerSource Roles There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen.

For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted commiter role.
An InnerSource Officer role is in charge for governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in
the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap.

The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors.

There is a standard process describing how to contribute to the community, contributor role is present.

Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution.
Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energyze" the community, being his main responsibility to attract and retain new developers/users (contributors/community members).

Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative.

Non technical contributors appear.
lenucksi commented 5 years ago

How about making a PR from the table such that it can be review-commented and have additional discussions around it?

dicortazar commented 5 years ago

Definitively! I'll work on this :). Thanks for the feedback.

StingRayZA commented 5 years ago

Thanks for this @dicortazar - looking forward to the PR!

maxcapraro commented 4 years ago

During the (this time not chatham house rule covered) summit, Dmitrii pointed us to the maturity model they are using: https://adeo.github.io/innersource/

The model in this MR appears to be focused on the maturity of a whole organization, dealing with IS. Dmitrii's model appears to be focused on the maturity of distinct InnerSource projects. So ... probably this warrants two separate patterns.

chtompki commented 4 years ago

Note PR #182. I think I’m playing around with a considerable number of the same ideas. What do you think of that PR? I would think we could potentially add a maturity model that references the definitions that I’ve laid out. Furthermore, I want to be sure that I’m not stepping on toes with my suggestions there. They are merely ideas that I’ve dealt with in my past experiences.

lenucksi commented 4 years ago

The pull request for this ticket just got merged - what do you think about closing this ticket now @dicortazar?

dicortazar commented 4 years ago

Let's close this :). I'll do it.