From 782ede2be9b85e399d6ef1444bce69239bb8e574 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 18 Mar 2020 23:03:01 +0100 Subject: [PATCH 1/5] Moving wiki pages to repo. Block: "Pattern Drafts (proven, not yet fully reviewed)" --- README.md | 7 +- overcome-acquisition-based-silos-developer.md | 82 ++++++++++++++++++ overcome-acquisition-based-silos-manager.md | 85 +++++++++++++++++++ 3 files changed, 170 insertions(+), 4 deletions(-) create mode 100644 overcome-acquisition-based-silos-developer.md create mode 100644 overcome-acquisition-based-silos-manager.md diff --git a/README.md b/README.md index b6e23f532..7a47312dc 100644 --- a/README.md +++ b/README.md @@ -30,8 +30,8 @@ possible to either deploy the same service in independent environments with sepa * [Cross-Team Project Valuation](crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.* * [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) - *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.* -* [Overcome Acquisition Based Silos - Developers](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos) -* [Overcome Acquisition Based Silos - Managers](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos) +* [Overcome Acquisition Based Silos - Developers](overcome-acquisition-based-silos-developer.md) +* [Overcome Acquisition Based Silos - Managers](overcome-acquisition-based-silos-manager.md) * [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.* * [Overcoming Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.* * [Start as Experiment](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.* @@ -76,7 +76,7 @@ The pattern form is useful for describing proven patterns but it can also be use [See our CONTRIBUTING.md for details on getting involved](CONTRIBUTING.md) -We encourage beginners seeking answers to jump in by creating ''donuts'' (problems without solutions). We encourage experts to pad their experience - these are hoped to become part of a book one day. Anyone can offer reviews and comments for [in-progress patterns](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls). +We encourage beginners seeking answers to jump in by creating ''donuts'' (problems without solutions). We encourage experts to pad their experience - these are hoped to become part of a book one day. Anyone can offer reviews and comments for [in-progress patterns](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls). We work together via Github, Webex, Slack, etc. Do not hesitate to join the [#innersourcecommons](https://isc-inviter.herokuapp.com/) or #innersource-patterns slack channels and ask to be included in the [patterns meetings](/meta/meetings.md) (there is an email list). @@ -102,4 +102,3 @@ The topics below cover information about how we define, operate, and upkeep this ![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png) InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License. - diff --git a/overcome-acquisition-based-silos-developer.md b/overcome-acquisition-based-silos-developer.md new file mode 100644 index 000000000..14e3d66fb --- /dev/null +++ b/overcome-acquisition-based-silos-developer.md @@ -0,0 +1,82 @@ +## Title + +Overcome Acquisition-based Silos (Developer Level) + +## Patlet + +TBD + +## Problem + +Inefficient/Duplicative development across teams because they are siloed + +## Context + +Acquisition(s) resulting in multiple cultural perspectives. Developer is aware and InnerSource program environment is available to them. Post-acquisition, so this won't account for code decisions that were made around acquisition. + +## Forces + +- Different processes in place +- Used to different tools and reluctant to change. +- Competing middle managers +- Rigid timelines +- Politics and egos +- Bi-directional fear/Lack of trust +- Fear of losing one's job +- Fear of loss of control of domain or code +- Fear of loss of identity +- Pandora's box/unknowns tied to opening up code + +## Sketch (optional) + +## Solution + +**For net-new acquisition** + +Make the acquired teams feel secure in the new environment by + +1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_). + +2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_) + - Joint effort between two teams to bring new software into existing platforms. (_validated_) + - If allowable/controllable, initial software selection not tied to job security. (_not validated_) + - Same ground rules as above for determining tooling platforms. (_validated_) + +3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_) + - Clear guidance on how to bring their software onto existing platform. (_not validated_) + - Definition of roles including Contributor and Trusted Committer. (_not validated_) + +4. Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (_validated_) + +5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_) + +6. Minimum commitment for face to face engagement between the two teams. + - can be representative team from acquiring company meet with team. + - potential Trusted committers from acquired company can meet with parent company. + +## Resulting Context + +- Silos are broken and teams working together +- This pattern does not address potential cultural issues due to the acquisition. + +## Rationale (optional) + +## Known Instances (optional) + +Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern. + +## Status + +Unproven (not reviewed) + +Old Status: Pattern Idea - Draft In Progress + +## Author + +David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank + +## Also see + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos diff --git a/overcome-acquisition-based-silos-manager.md b/overcome-acquisition-based-silos-manager.md new file mode 100644 index 000000000..5d84590ef --- /dev/null +++ b/overcome-acquisition-based-silos-manager.md @@ -0,0 +1,85 @@ +## Title + +Overcome Acquisition-based Silos (Management Level) + +## Patlet + +TBD + +## Problem + +Inefficient/Duplicative development across teams because they are siloed + +## Context + +Acquisition(s) resulting in multiple cultural perspectives. Acquired company's Middle Management is supportive of the InnerSource program. Post-acquisition, so this won't account for code decisions that were made around acquisition. + +## Forces + +- Different processes in place +- Fear of losing control +- Have to deal with developer fears +- Fear of losing developer resources (who work on other projects) +- Rigid timelines +- Politics and egos +- Bi-directional fear/Lack of trust +- Fear of losing one's job +- Fear of loss of identity +- Fear of being judged +- Pandora's box/unknowns tied to opening up code submissions + +(PICK UP HERE NEXT TIME)---------------10/25/16 + +## Sketch (optional) + +## Solution + +**For net-new acquisition** + +Make the acquired teams feel secure in the new environment by + +1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_). + +2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_) + - Joint effort between two teams to bring new software into existing platforms. (_validated_) + - If allowable/controllable, initial software selection not tied to job security. (_not validated_) + - Same ground rules as above for determining tooling platforms. (_validated_) + +3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_) + - Clear guidance on how to bring their software onto existing platform. (_not validated_) + - Definition of roles including Contributor and Trusted Committer. (_not validated_) + +4. Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (_validated_) + +5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_) + +6. Minimum commitment for face to face engagement between the two teams. + - can be representative team from acquiring company meet with team. + - potential Trusted committers from acquired company can meet with parent company. + +## Resulting Context + +- Silos are broken and teams working together +- This pattern does not address potential cultural issues due to the acquisition. + +## Rationale (optional) + +## Known Instances (optional) + +Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern. + +## Status + +Unproven (not reviewed) + +Old Status: Pattern Idea - Draft In Progress + +## Author + +David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank + +## Also see + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Overcome-Acquisition-based-Silos From d88e23aad594ad57fbb54673d7e991bfe7bb37b0 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 19 Mar 2020 21:43:38 +0100 Subject: [PATCH 2/5] Moving wiki pages to repo. Block: "Pattern Ideas (not yet proven; brainstormed)" --- README.md | 8 +- change-the-developers-mindset.md | 64 ++++++++++++++ ...-alignment-for-innersource-contribution.md | 84 +++++++++++++++++++ share-your-code-to-get-more-done.md | 67 +++++++++++++++ shared-code-repo-different-from-build-repo.md | 39 +++++++++ 5 files changed, 258 insertions(+), 4 deletions(-) create mode 100644 change-the-developers-mindset.md create mode 100644 developer-incentive-alignment-for-innersource-contribution.md create mode 100644 share-your-code-to-get-more-done.md create mode 100644 shared-code-repo-different-from-build-repo.md diff --git a/README.md b/README.md index 7a47312dc..d0ae52e49 100644 --- a/README.md +++ b/README.md @@ -41,10 +41,10 @@ possible to either deploy the same service in independent environments with sepa * [Don't Bother Looking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60) * [Junkyard Styled Inner Sourcing](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/61) -* [Shared Code Repo Different from Build Repo](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.* -* [Incentive Alignment](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution) -* [Change the Developers Mindset](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset) -* [Share Your Code to Get More Done - Likely Contributors Variant](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-Share-Your-Code-to-Get-More-Done---Likely-Contributors-Variant) +* [Shared Code Repo Different from Build Repo](shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.* +* [Incentive Alignment](developer-incentive-alignment-for-innersource-contribution.md) +* [Change the Developers Mindset](change-the-developers-mindset.md) +* [Share Your Code to Get More Done - Likely Contributors Variant](share-your-code-to-get-more-done.md) #### Pattern Donuts (needing a solution) diff --git a/change-the-developers-mindset.md b/change-the-developers-mindset.md new file mode 100644 index 000000000..5651fd125 --- /dev/null +++ b/change-the-developers-mindset.md @@ -0,0 +1,64 @@ +## Title + +Change the developers mindset + +## Patlet + +TBD + +## Problem + +* Change developer mindset, it's difficult to push developers to do things. +* Developers are resisting the change, they are in their comfort zone and it's hard to go out. +* Developer organizations maturity is high, so people are used to being in some hierarchy/rules +* Developers are formed in agile, the shift from agile is difficult + +## Context + +* Top-down inner source support +* 3k population of developers +* Middle Management is not supporting inner source +* There's already a successful group in the early stages +* Code visibility is product dependent + +## Forces + +* Manager are previous developers, so they like the way they were promoted and they want to proceed in similar ways +* Manager restrict where developers can spend time on +* Top-down approach to the inner source +* Different teams within the company have to decide to proceed with inner source +* No formal training +* Processes are not clear + +## Sketch (optional) + +## Solution + +* Showing reward/recognition of the developer team +* Formalize training +* Clarify more processes +* Give middle management specific objectives to make inner source successful +* Listen to manager complaints and fears and count on them + +## Resulting Context + +* Use of the several projects across the several development teams +* Collaboration within the same developer team (mentorship and so on) + +## Rationale (optional) + +## Known Instances (optional) + +## Status + +Unproven + +Old status: Pattern Idea + +## See Also + +This pattern has been moved for discussion at https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/39 + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset diff --git a/developer-incentive-alignment-for-innersource-contribution.md b/developer-incentive-alignment-for-innersource-contribution.md new file mode 100644 index 000000000..3983a527b --- /dev/null +++ b/developer-incentive-alignment-for-innersource-contribution.md @@ -0,0 +1,84 @@ +## Title + +Developer Incentive Alignment for InnerSource Contribution + +## Patlet + +TBD + +## Problem + +* The organization needs to adopt a more collaborative, open-source like workstyle, but its developers are not properly incentivized or extrinsically motivated to participate in the company’s InnerSource processes. +* There is a prevailing attitude in the developer culture that helping or contributing to others' success and learning is a “time sink” or "not my job." +* Credit and kudos are not consistently shared with developers who help or contribute to others' success. +* Prevailing developer culture is such that many believe the way up the organizational ladder - via increases in title or compensation - depends on one’s performance on quantitative metrics such as lines of code output, deadlines met, ownership of product releases or updates, and so forth. +* Developers aren’t moving up the ‘organizational ladder’ because it is perceived as a path toward people management and direct reports, rather than a path of deepened respect or capabilities in engineering. + +## Context + +* There is a need to foster team-centric behaviour and limit instances of [ego-driven development](http://deliberate-software.com/ego-driven-development/) or idolizing a 'star developer.' +* There are multiple developers within the organization or business unit with the same or related areas of expertise, such as front-end development, devops, testing, etc. +* Mid-to-top level management either do not have a technical background or their technical backgrounds and experiences are many years out of date; organizational emphasis is therefore on quantitative output of development team. +* The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas. +* The organization is comfortable with a personnel management and/or professional development style that is organic or “bottom-up” as opposed to traditional training or development programs run through HR (even as task management or velocity is managed in a more top-down fashion). + +## Forces + +1. Existing attitudes and developer culture + * Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint. + * Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity. + * Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process. + +2. Need to retain developer talent + * Managers focus heavily on tasks or velocity for developers rather than providing mentorship. Developers view helping or mentoring others as the job of Management, or something “I don’t get paid to do.” Career progression, or other ‘upward mobility paths’ (to receive a raise, for example) are not clearly identified in the organization. + * Existing job descriptions, promotion tracks or compensation bands are opaque or hard to get from the organization’s HR department, resulting in a mixed understanding of job responsibilities. This puts additional pressure on performance review or improvement plans because HR, developers and managers don’t have shared a shared understanding of roles or expectations. + * 'Home growing' developer talent - encouraging career growth within the company - is far cheaper for organizations in the long run than hiring from outside. Studies show employee retention increases as new opportunities, challenges, and paths for learning are introduced. + +3. Maintaining the product development lifecycle + * Keeping the status quo is encouraged or reinforced with existing product/project management processes and expectations. Developers and managers are reticent to make changes for fear of putting deadlines or product/business unit goals at risk (note that these often have financial implications for the company and individual). Working on one’s own individual contributions is seen as doing one’s part to protect this lifecycle; efforts outside one’s own individual contributions is seen as disruptive. + * Product/Business unit pressures + * HR - existing resource allocation plans & patterns + +## Sketch (optional) + +![Table of roles goes here] +![or maybe the pyramid] + +## Solution + +***Resolution to the problem*** + +* Job Descriptions/Roles on the engineering title ladder are allocated mentorship and "Open Source Time" as fits their level (i.e. 0% expectation for jrs, 100% expectation for Principals) +* Moving up the ladder requires taking on more responsibility for mentoring, reviewing code, and bringing in contributions +* Developers may choose not to move up the ladder because of a preference for certain types of contributions ("I like just writing code" vs "I want to have a bigger impact on the team") +* relevant Skills & experience are associated with advancing titles/roles - Moving up the ladder also requires developing the social skills necessary for mentorship +* Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc) + +## Resulting Context + +* culture has been shifted from contribution culture to learning culture +* devs & pms believe time spent mentoring and reviewing is equally, if not more so, valuable to time spent coding +* job descriptions include mentorship & contribution language to set expectations up front & make it easier to assess if candidates have requisite skills/experience required +* org is retaining and better utilizing existing talent +* devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management +* career progression clearly identified & understood by engs and management + +## Rationale (optional) + +## Known Instances (optional) + +## Status + +Unproven + +Old status: brainstormed solution + +## Author + +Jory Burson + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution diff --git a/share-your-code-to-get-more-done.md b/share-your-code-to-get-more-done.md new file mode 100644 index 000000000..36165fe35 --- /dev/null +++ b/share-your-code-to-get-more-done.md @@ -0,0 +1,67 @@ +## Title + +Share Your Code to Get More Done + +Old title: Share Your Code to Get More Done - Likely Contributors Variant + +## Patlet + +TBD + +## Problem + +* Developers do not realize that they can get more done by taking advantage of Inner Sourcing +* Developers continue to work in their silo or alone and never take the time invest in moving to Inner Sourcing +* Project Teams need a compelling reason to invest some time to make the change + +## Context + +* Development on a specific product is siloed and a finite number of developers are involved in development activity +* Development progress is not moving fast enough +* Developers are being asked to do more work than they can accomplish +* Other developers are likely to work on the product if the opportunity to participate existed +* Current developers are working near maximum efficiency + +## Forces + +* Developers have no extra time to shift to Inner Sourcing +* Management has not prioritized a shift to Inner Sourcing +* Adding staff to get the work done using traditional methods is not possible +* The value of Inner Sourcing is not included in the project plan + +## Sketch (optional) + +## Solution + +* Leverage existing case studies and collateral from Inner Source Commons to educate management on the value of investing in Inner Sourcing. +* Work with planning team to document an alternative project plan with some inner sourcing activities and estimated benefits from realistic expected participation +* Move the product code to an Inner Source compatible solution and open the code +* Assign a portion of the developers time to work as reviewers to ensure inner sourcing activities are successful +* Recruit potential contributors and inform them of the availability of the opportunity to participate +* Align incentives to participation for both existing developers and contributors to encourage behavior + +## Resulting Context + +* Development previously done in a silo is on the inner source system +* People from outside the traditional silo are contributing successfully +* More development is getting done per period (sprint) + +## Rationale (optional) + +## Known instances (optional) + +## Status + +Unproven + +Old status: Idea + +## Author + +David Marcucci + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo diff --git a/shared-code-repo-different-from-build-repo.md b/shared-code-repo-different-from-build-repo.md new file mode 100644 index 000000000..5e1118272 --- /dev/null +++ b/shared-code-repo-different-from-build-repo.md @@ -0,0 +1,39 @@ +## Title + +Repo for Shared Code Different from Repo the Product Org Uses in its Build + +## Patlet + +TBD + +## Problem + +Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds. + +## Context + +Shared code is kept in an accessible repository that is different from SCMs used by the products that use the shared code. Integration, testing and builds might be automated with the product SCM but not the shared code repo. + +## Forces + +When the shared code is in a separate repository, any use of it could result in forking modifications, leading to complications later when the source is changed by the owning organization. When starting an inner sourcing program, it is possible there are many SCM systems in use; and, frequently, a new SCM is used for the inner sourcing program. Migrating from one SCM to another is not trivial. Since the using organization has a copy, they might not be aware of changes to the shared code. It is difficult and expensive for the using organization to change their automated build process to use a foreign repo. + +## Solution + +Continuous integration, not only to with testing but also in production (aligns with DevOps). Known marker that shows the code hasn't been modified. Improved communication between teams. Accountability when you screw up; hold people accountable. Publish good stats about the negative implications of errors and processes for making this everyone's problem. + +## Resulting Context + +Ideally, overhead is minimized or eliminated. Or integrate the shared code repository in the production build. + +## Status + +Unproven + +## Author + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo From 5dc6ae97fe4b90657e778c6cc0137f6a94a0685b Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 19 Mar 2020 22:43:34 +0100 Subject: [PATCH 3/5] rename section to '## See Also' --- overcome-acquisition-based-silos-developer.md | 2 +- overcome-acquisition-based-silos-manager.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/overcome-acquisition-based-silos-developer.md b/overcome-acquisition-based-silos-developer.md index 14e3d66fb..34246ef35 100644 --- a/overcome-acquisition-based-silos-developer.md +++ b/overcome-acquisition-based-silos-developer.md @@ -75,7 +75,7 @@ Old Status: Pattern Idea - Draft In Progress David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank -## Also see +## See Also This pattern was originally created in this wiki and then ported here. Original wiki page: diff --git a/overcome-acquisition-based-silos-manager.md b/overcome-acquisition-based-silos-manager.md index 5d84590ef..df77904d1 100644 --- a/overcome-acquisition-based-silos-manager.md +++ b/overcome-acquisition-based-silos-manager.md @@ -78,7 +78,7 @@ Old Status: Pattern Idea - Draft In Progress David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank -## Also see +## See Also This pattern was originally created in this wiki and then ported here. Original wiki page: From 3fead953493e8658bcb093a525282dd5518597fe Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 21 Mar 2020 12:36:04 +0100 Subject: [PATCH 4/5] Moving wiki pages to repo. Block: "Pattern Donuts (needing a solution)". Details: - port 3 wiki pages into this repo - remove "Donut:" prefix in README - link one Donut to it's PR - last Donut could not be found in the wiki: [Donut 8: Not Invented Here](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-8:-Not-invented-here) --- README.md | 9 +++--- bad-weather-for-liftoff.md | 52 ++++++++++++++++++++++++++++++ defeat-hierarchical-constraints.md | 41 +++++++++++++++++++++++ organizational-mindset-change.md | 43 ++++++++++++++++++++++++ 4 files changed, 141 insertions(+), 4 deletions(-) create mode 100644 bad-weather-for-liftoff.md create mode 100644 defeat-hierarchical-constraints.md create mode 100644 organizational-mindset-change.md diff --git a/README.md b/README.md index d0ae52e49..9669cc7dd 100644 --- a/README.md +++ b/README.md @@ -48,11 +48,11 @@ possible to either deploy the same service in independent environments with sepa #### Pattern Donuts (needing a solution) -* [Donut 3: How to Defeat the Hierarchical Constraints](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-3%3A-how-to-defeat-the-hierarchical-constraints) -* [Donut 5: Project Management Time Pressures](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-5:-project-management-time-pressures) -* [Donut 6: Organizational Mindset Change](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-6:-organizational-mindset-change) +* [How to Defeat the Hierarchical Constraints](defeat-hierarchical-constraints.md) +* [Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47) +* [Organizational Mindset Change](organizational-mindset-change.md) * [Donut 8: Not Invented Here](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-8:-Not-invented-here) -* [Donut: Bad Weather For Liftoff](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Bad-weather-for-liftoff) +* [Bad Weather For Liftoff](bad-weather-for-liftoff.md) * [Get Contributions Despite Silo Thinking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/38) @@ -95,6 +95,7 @@ The topics below cover information about how we define, operate, and upkeep this * [Meetings](meta/meetings.md) - Become involved with the people and communications of the Inner Source Patterns group # Related References + * [A pattern language for pattern writing](http://hillside.net/index.php/a-pattern-language-for-pattern-writing), Meszaros and Doble # Licensing diff --git a/bad-weather-for-liftoff.md b/bad-weather-for-liftoff.md new file mode 100644 index 000000000..7762f0f3b --- /dev/null +++ b/bad-weather-for-liftoff.md @@ -0,0 +1,52 @@ +## Title + +Bad weather for liftoff + +## Patlet + +TBD + +## Problem + +- The team is not able to demonstrate any increases in quality or speed, because they did not adopt any of the principles of OSS development. +- As a result, the InnerSource approach is discredited. + +## Context + +- Company A would like to start an InnerSource initiative in order to increase development speed and quality of software artifacts. +- There are not many developers in company A, which are experienced in OSS development practices. +- The company was not able to contract or hire an experienced InnerSourcerer. +- Company A has put together a small team of software developers to work on a single project InnerSource style. The project has tight deadlines to meet. + +## Forces + +- By default, humans will be resistant to change if they have no compelling reason to change. +- Pressure (in this case induced by the project being a pilot and also induced by the deadline) reduces the ability to change and explore new ways of working. +- There is a natural tendency to pick low hanging fruits (e. g. tooling) and stop there. +- For InnerSource to blossom, a critical mass of experienced developers which can walk the talk is required. + +## Sketch (optional) + +## Solution + +TBD + +## Resulting Context + +## Rationale (optional) + +## Known Instances (optional) + +## Status + +Donut + +## Author(s) + +* Georg Grütter, Wyane DuPont, Michael Dorner + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Bad-weather-for-liftoff diff --git a/defeat-hierarchical-constraints.md b/defeat-hierarchical-constraints.md new file mode 100644 index 000000000..1318b7280 --- /dev/null +++ b/defeat-hierarchical-constraints.md @@ -0,0 +1,41 @@ +## Title + +Defeat Hierarchical Constraints + +## Patlet + +TBD + +## Problem + +Corporate culture constrains people to hierarchical goals. + +## Context + +In strongly hierarchical organizations, developers want to please their managers. Their managers may not support their people spending time on inner sourcing even if someone higher up does. In some countries, there is a strong cultural force to respect and obey authority. + +## Forces + +To make inner sourcing work, you need to allow some developers outside your org to participate in your development. +Managers have deadlines and they don’t see how having their people will help them achieve *their* goals and objectives. They may feel it slows them down. +Even if there is nominal higher support for the goals, developers may still feel afraid to take that step. + +## Solutions + +TBD + +## Resulting Context + +Developers feel empowered to spend at least 20% of their time on inner sourcing + +## Status + +Donut + +## Author(s) + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-3%3A-how-to-defeat-the-hierarchical-constraints diff --git a/organizational-mindset-change.md b/organizational-mindset-change.md new file mode 100644 index 000000000..00aff41c1 --- /dev/null +++ b/organizational-mindset-change.md @@ -0,0 +1,43 @@ +## Title + +Organizational Mindset Change + +## Patlet + +TBD + +## Problem + +How do you effect an organizational mindset change to support inner sourcing? + +## Context + +Upper management, middle management and developers are not convinced to fully support inner sourcing. They are used to doing software development in the old way. + +## Forces + +Changing an organizational mindset takes time and effort, which most organizations (feel they) cannot afford. +Inner sourcing could bring about a lot of desirable benefits, but it takes time to ramp up to deliver them. +Changing executive mindsets usually requires hype which then is hard deliver on. +KPIs to prove the benefits are often required early but choosing the wrong KPIs can severely warp the program. +Pressure from competitors and the market place makes management less willing to try significant change (deemed too risky). + +## Solutions + +TBD + +## Resulting Context + +All of the company heartily adopts inner sourcing! Cake for everyone! + +## Status + +Donut + +## Author(s) + +## See Also + +This pattern was originally created in this wiki and then ported here. +Original wiki page: +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-6:-organizational-mindset-change From 9fa386184ae9a83857213e6616e7b89bea91fb95 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 21 Mar 2020 13:14:48 +0100 Subject: [PATCH 5/5] Link to the correct old wiki page --- share-your-code-to-get-more-done.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/share-your-code-to-get-more-done.md b/share-your-code-to-get-more-done.md index 36165fe35..6597f13b6 100644 --- a/share-your-code-to-get-more-done.md +++ b/share-your-code-to-get-more-done.md @@ -64,4 +64,4 @@ David Marcucci This pattern was originally created in this wiki and then ported here. Original wiki page: -https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Shared-Code-Repo-Different-from-Build-Repo +https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-Share-Your-Code-to-Get-More-Done---Likely-Contributors-Variant