diff --git a/README.md b/README.md index 2295e52c1..201efdd6f 100644 --- a/README.md +++ b/README.md @@ -43,13 +43,13 @@ The below lists all known patterns. They are grouped into three [maturity levels * [Praise Participants](patterns/2-structured/praise-participants.md) - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute* * [Repository Activity Score](patterns/2-structured/repository-activity-score.md) - *The repository activity score is a numeric value that represents the (GitHub) activity of an InnerSource project.* * [Review Committee](patterns/2-structured/review-committee.md) - *A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.* -* [Service vs. Library](patterns/2-structured/service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's -possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.* +* [Service vs. Library](patterns/2-structured/service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.* * [Trusted Committer](patterns/2-structured/trusted-committer.md) - *Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.* * [Standard Base Documentation](patterns/2-structured/project-setup/base-documentation.md) - *New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.* * [Issue Tracker Use Cases](patterns/2-structured/project-setup/issue-tracker.md) - *The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.* * [Communication Tooling](patterns/2-structured/project-setup/communication-tooling.md) - *An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to setup and document standard communication tooling that allows for discussions to become visible, archived and searchable.* * [Transparent Cross-Team Decision Making using RFCs](patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - *InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.* +* [Start as an Experiment](patterns/2-structured/start-as-experiment.md) - *Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.* #### Pattern Drafts (proven, not yet fully reviewed) @@ -58,7 +58,6 @@ possible to either deploy the same service in independent environments with sepa * [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.* * [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.* * [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.* -* [Start as Experiment](patterns/2-structured/start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.* * [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.* ### Maturity Level 1: Initial diff --git a/patterns/2-structured/start-as-experiment.md b/patterns/2-structured/start-as-experiment.md index 426b772e9..12844e465 100644 --- a/patterns/2-structured/start-as-experiment.md +++ b/patterns/2-structured/start-as-experiment.md @@ -4,94 +4,52 @@ Start as an Experiment ## Patlet -Start your InnerSource initiative as a time limited experiment to make it -easier for managers unfamiliar with InnerSource to endorse and support the -initiative. +Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative. ## Problem -An InnerSource initiative is considered but not started because management is -unsure about its outcome and, as a result, is not willing to commit to an -investment. +An InnerSource initiative is considered but not started because management is unsure about its outcome and, as a result, is not willing to commit to an investment. ## Context -The company is considering InnerSource to increase the efficiency -of collaboration on software projects. However, most managers are not familiar -with the Open Source working model and are instead accustomed to hierarchical, -top-down control style management. The idea of InnerSource is very popular with -software developers in the company, not the least because many developers use -or are actively developing Open Source software. +The company is considering InnerSource to increase the efficiency of collaboration on software projects. However, most managers are not familiar with the Open Source working model and are instead accustomed to hierarchical, top-down control style management. The idea of InnerSource is very popular with software developers in the company, not the least because many developers use or are actively developing Open Source software. ## Forces -- Managers will want to validate the claims of improved collaboration through - InnerSource before making a long term investment. This usually involves - measuring the improvements. -- If the InnerSource initiative will likely have a huge uptake among developers - and if many projects are likely to rely on it, a decision to shut it down - will be very unpopular and therefore hard to make. The perceived resulting - loss of control might deter some managers to even start with InnerSource. -- Implementing InnerSource style working models are often a radical departure - from previously practiced working models. It is therefore likely, that - existing, mandatory processes are no longer applicable and that appropriate - governing processes are missing. The result might be that one has to operate - in a regulatory, sometimes legal no-mans land. Examples are tax and export - control related regulations in large corporations with multiple legal - entities in multiple countries. +- Managers will want to validate the claims of improved collaboration through InnerSource before making a long term investment. This usually involves measuring the improvements. +- If the InnerSource initiative will likely have a huge uptake among developers and if many projects are likely to rely on it, a decision to shut it down will be very unpopular and therefore hard to make. The perceived resulting loss of control might deter some managers to even start with InnerSource. +- Implementing InnerSource style working models are often a radical departure from previously practiced working models. It is therefore likely, that existing, mandatory processes are no longer applicable and that appropriate governing processes are missing. The result might be that one has to operate in a regulatory, sometimes legal no-mans land. Examples are tax and export control related regulations in large corporations with multiple legal entities in multiple countries. ## Solution -Declare the InnerSource initiative as a time limited experiment. Define and -communicate the criteria for projects to join the InnerSource experiment. Choose -criteria that will maximize the chances of building a healthy A set of criteria is -a good one if the insights generated from it within the context of the experiment -can intuitively be applied to contexts involving other potential InnerSource projects. +Declare the InnerSource initiative as a time limited experiment. Define and communicate the criteria for projects to join the InnerSource experiment. Choose criteria that will maximize the chances of building a healthy community. A set of criteria is a good one if the insights generated from it within the context of the experiment can intuitively be applied to contexts involving other potential InnerSource projects. + Examples for such criteria are: - Sufficient geographical distribution of developers -- Sufficient departmental mix of developers, -- Openness of communication within community, -- Career path based on merit within community, -- Democratic decision making within community. - -Consider designating the end of the experiment a _pivot_, _change_ or _pause_ -point to re-evaluate. Also consider establishing a [Review -Committee](review-committee.md) to increase the chances of management buy-in -through participation. Depending on company culture, it might be helpful to -accompany the experiment with appropriate metrics [First Steps With -Metrics](../1-initial/introducing-metrics-in-innersource.md). If the projects in the -experiment don't provide a direct impact on the companies revenue, consider -introducing [Cross Team Valuation](crossteam-project-valuation.md) to highlight -their value contributions. +- Sufficient departmental mix of developers +- Openness of communication within community +- Career path based on merit within community +- Democratic decision making within community + +Consider designating the end of the experiment a _pivot_, _change_ or _pause_ point to re-evaluate. Also consider establishing a [Review Committee](review-committee.md) to increase the chances of management buy-in through participation. Depending on company culture, it might be helpful to accompany the experiment with appropriate metrics [First Steps With Metrics](../1-initial/introducing-metrics-in-innersource.md). If the projects in the experiment don't provide a direct impact on the companies revenue, consider introducing [Cross-Team Project Valuation](crossteam-project-valuation.md) to highlight their value contributions. ## Resulting Context Managers are able to kick start InnerSource for the following reasons: -- The experimental setup eases the need for managers to scrutinize the - InnerSource program numbers in the same way that they would for typical - projects. -- The possibility of failure of the experiment is understood and accepted. The - personal risk for the supporting managers is minimized. -- Even in case of a failure, the setup ensures that the company will learn from - the experiment. -- In case of success, the data gathered during the experiment will allow - managers to make a longer lasting commitment to InnerSource. - -Participants in the InnerSource experiment are now conscious that they have to -prove to management that InnerSource yields the promised benefits. -It will therefore help to focus work on those activities which provide the most -demonstrable value thus increasing the chances of success. - -Finally, starting as an experiment makes it much easier to sidestep regulations -and forces such as tool and process policies which could decrease the chances -of success. +- The experimental setup eases the need for managers to scrutinize the InnerSource program numbers in the same way that they would for typical projects. +- The possibility of failure of the experiment is understood and accepted. The personal risk for the supporting managers is minimized. +- Even in case of a failure, the setup ensures that the company will learn from the experiment. +- In case of success, the data gathered during the experiment will allow managers to make a longer lasting commitment to InnerSource. + +Participants in the InnerSource experiment are now conscious that they have to prove to management that InnerSource yields the promised benefits. It will therefore help to focus work on those activities which provide the most demonstrable value thus increasing the chances of success. + +Finally, starting as an experiment makes it much easier to sidestep regulations and forces such as tool and process policies which could decrease the chances of success. ## Related Patterns -- _Trial Run_ (from the book [_Fearless - Change_](https://fearlesschangepatterns.com/)) +- _Trial Run_ (from the book [Fearless Change](https://fearlesschangepatterns.com/)) ## Known Instances @@ -100,7 +58,6 @@ of success. ## Status * Structured -* Old status: Proven ## Author