Start as an Experiment

Search…
Title
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.
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.
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.
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.
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 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 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. If the projects in the experiment don't provide a direct impact on the companies revenue, consider introducing Cross-Team Project Valuation 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.
Related Patterns
Trial Run (from the book Fearless Change)
Known Instances
Robert Bosch GmbH (globally distributed software development)
Status
Structured
Author
Georg Grütter (Robert Bosch GmbH)
Acknowledgements
Jason Zink (Robert Bosch GmbH)
Diogo Fregonese (Robert Bosch GmbH)
Robert Hansel (Robert Bosch GmbH)
Hans Malte Kern (Robert Bosch GmbH)
Russ Rutledge (Nike)
Tim Yao (Nokia)
Clint Cain (Optum)