From 89d3171338b2efca9f5e5ba94c5c753132cb874f Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 9 Oct 2018 06:27:33 -0700 Subject: [PATCH 1/6] Create problems-solved.md --- introduction/problems-solved.md | 35 +++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 introduction/problems-solved.md diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md new file mode 100644 index 00000000..51fb85aa --- /dev/null +++ b/introduction/problems-solved.md @@ -0,0 +1,35 @@ +This file holds the text to accompany the [What Problems Does InnerSource Solve?](https://www.safaribooksonline.com/videos/introduction-to-innersource/9781492041504/9781492041504-video321607) video. +This accompanying text will appear as a part of the learning path (like [this example](https://www.safaribooksonline.com/learning-paths/learning-path-lean/9781491999738/9781491946527-/part01ch01.html)). + +# What Problems Does InnerSource Solve? + +To illustrate the types of situations where inner source can help, imagine the following. +Suppose two teams at the same company deliver separate pieces of software with one team's software depending on that of the other. +An example could be a user experience that depends on an API service to retrieve data for display. +This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers. + +When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. +For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which come with their own drawbacks. + +1. **Wait it out**. The consuming team may do nothing and limp along without the requested functionality. + This option requires the least amount of work on their side. + Depending on the benefit of the feature request, waiting might be just fine. + However, it may come with real amounts of pain, especially if the requested functionalty is never delivered. +1. **Workaround**. A consuming team that doesn't want to wait may do extra work somewhere else to compensate for the absence of their requested feature. + This extra work may come as change in the consuming project. + Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team's system (code/project duplication). + This strategy allows the consuming team to get the requested feature via their own efforts only (no hard dependencies). It comes with several drawbacks, though. + + 1. Any work done by the consuming team remains unavailable to any other consumers with the same feature request. + 1. The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency. + 1. The company as-a-whole acquires duplicate projects and code in the same problem space. + +1. **Escalate**. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. +This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. +It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. +Additionally, this option does not scale as there are so many times that a consumer can escalate feature requests before damaging their credibility. +Escalate is similarly disruptive (even more so) for the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request. + +This discussion sets the stage for inner source. +Inner source applies to the same type of situation where a consuming team is unable to get what needs via feature request. +Inner source provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. From d2dd9c956e2a84a2e426c2be134b673aec6bf3ce Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 15 Jan 2019 10:54:39 -0800 Subject: [PATCH 2/6] PR feedback --- introduction/problems-solved.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md index 51fb85aa..767f2a70 100644 --- a/introduction/problems-solved.md +++ b/introduction/problems-solved.md @@ -3,8 +3,12 @@ This accompanying text will appear as a part of the learning path (like [this ex # What Problems Does InnerSource Solve? -To illustrate the types of situations where inner source can help, imagine the following. -Suppose two teams at the same company deliver separate pieces of software with one team's software depending on that of the other. +Inner source encourages and rewards collaboration from anyone, regardless of their location in company organizational structure. +This approach differs from the results seen in traditional organizations, where ideas and work tend to stay trapped within the boundaries of internal corporate hierarchy and the work and planning processes that align themselves to that hierarchy. +Inner source provides a way for these ideas and work to break free of those traditional bounds to the benefit of all involved. +Let's explore one situation that gives an example of this idea. + +Imagine two teams at the same company deliver separate pieces of software with one team's software depending on that of the other. An example could be a user experience that depends on an API service to retrieve data for display. This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers. @@ -18,7 +22,7 @@ For critical feature requests that are not prioritized for immediate work, the c 1. **Workaround**. A consuming team that doesn't want to wait may do extra work somewhere else to compensate for the absence of their requested feature. This extra work may come as change in the consuming project. Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team's system (code/project duplication). - This strategy allows the consuming team to get the requested feature via their own efforts only (no hard dependencies). It comes with several drawbacks, though. + This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though. 1. Any work done by the consuming team remains unavailable to any other consumers with the same feature request. 1. The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency. @@ -27,9 +31,10 @@ For critical feature requests that are not prioritized for immediate work, the c 1. **Escalate**. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. -Additionally, this option does not scale as there are so many times that a consumer can escalate feature requests before damaging their credibility. -Escalate is similarly disruptive (even more so) for the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request. +Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. +Escalation is similarly disruptive (even more so) for the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request. This discussion sets the stage for inner source. Inner source applies to the same type of situation where a consuming team is unable to get what needs via feature request. Inner source provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. +It also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. From a58c8cdba220ecb4f924bd281475f4187ff02c4a Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Wed, 23 Jan 2019 14:21:18 -0800 Subject: [PATCH 3/6] Update problems-solved.md --- introduction/problems-solved.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md index 767f2a70..f6c005e5 100644 --- a/introduction/problems-solved.md +++ b/introduction/problems-solved.md @@ -37,4 +37,7 @@ Escalation is similarly disruptive (even more so) for the producing team, who ar This discussion sets the stage for inner source. Inner source applies to the same type of situation where a consuming team is unable to get what needs via feature request. Inner source provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. -It also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. + +Inner source also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. +It facilitates sharing of ideas and solutions across organizational silos. +Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization. From 4b41f1b05226a23b4e21d8d0f800783302a64bf3 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Wed, 23 Jan 2019 14:23:30 -0800 Subject: [PATCH 4/6] Update problems-solved.md --- introduction/problems-solved.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md index f6c005e5..08756158 100644 --- a/introduction/problems-solved.md +++ b/introduction/problems-solved.md @@ -3,9 +3,8 @@ This accompanying text will appear as a part of the learning path (like [this ex # What Problems Does InnerSource Solve? -Inner source encourages and rewards collaboration from anyone, regardless of their location in company organizational structure. -This approach differs from the results seen in traditional organizations, where ideas and work tend to stay trapped within the boundaries of internal corporate hierarchy and the work and planning processes that align themselves to that hierarchy. -Inner source provides a way for these ideas and work to break free of those traditional bounds to the benefit of all involved. +Inner source encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company's organizational structure. +This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. Let's explore one situation that gives an example of this idea. Imagine two teams at the same company deliver separate pieces of software with one team's software depending on that of the other. From d521b8e0620bf4a14392aa6840f0ac10c024e26d Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Mon, 28 Jan 2019 12:05:05 -0800 Subject: [PATCH 5/6] mention mentoring and learning explicitly --- introduction/problems-solved.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md index 08756158..b10ec29c 100644 --- a/introduction/problems-solved.md +++ b/introduction/problems-solved.md @@ -38,5 +38,5 @@ Inner source applies to the same type of situation where a consuming team is una Inner source provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. Inner source also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. -It facilitates sharing of ideas and solutions across organizational silos. +Developers mentor and learn from one other as they share ideas and solutions across organizational silos. Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization. From 28ee81c547b1540c563dd4b23a1ce2b019750cb4 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 12 Feb 2019 10:10:48 -0800 Subject: [PATCH 6/6] Typo --- introduction/problems-solved.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/problems-solved.md b/introduction/problems-solved.md index b10ec29c..2300b6a6 100644 --- a/introduction/problems-solved.md +++ b/introduction/problems-solved.md @@ -38,5 +38,5 @@ Inner source applies to the same type of situation where a consuming team is una Inner source provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. Inner source also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. -Developers mentor and learn from one other as they share ideas and solutions across organizational silos. +Developers mentor and learn from one another as they share ideas and solutions across organizational silos. Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.