Add introduction to product focused learning path.#508
Add introduction to product focused learning path.#508rrrutledge merged 7 commits intoInnerSourceCommons:mainfrom
Conversation
lenucksi
left a comment
lenucksi
left a comment
There was a problem hiding this comment.
That's a nice write-up.
It reads a bit more like "combining Agile and InnerSource / where's the difference and what do I do as a team lead".
Wondering where this fits in though and what's the planned future?
We tried the outline & scope first with the other parts - do you think that could be a worthwhile approach here too?
(If nothing else: Good content, yay! 🎉 )
|
As for the focus: The goal is to answer all questions related to InnerSource some product manager might have. My challenge is that my own product management experience is limited. Thus so far this mirrors the questions I have gotten. Happy to include other aspects people have received as well. As for other issues:
Outline: Have you seen https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/product/outline.md ? |
Got it.
Yes, too long ago. I forgot the connection. Now the connection is there, though. :) |
rrrutledge
left a comment
rrrutledge
left a comment
There was a problem hiding this comment.
Thank you for this work, @MaineC ❗ We are very glad for this effort and teaching that you are putting in to this new section of the Learning Path.
Can you kindly put each sentence on a new line in the markdown source? The text will still render the same in GitHub, but this practice makes it easier to leave review comments on a particular sentence. See Contributing.md. Thank you!
|
I've changed the formatting. I also added the content for the "relation between agile and InnerSource" segment, however so far I tried to stick with outline-like bullet points only. Thanks for that reminder @lenucksi |
rrrutledge
left a comment
rrrutledge
left a comment
There was a problem hiding this comment.
Thank you, @MaineC ❗ We are very excited for this work!
|
|
||
| ## Common misunderstandings when coming from agile teams | ||
|
|
||
| * Impact on performance reviews: InnerSource moves some of the energy you spend developing outside of your own team. |
There was a problem hiding this comment.
Are you going to talk about Sprint and roadmap commitments here?
There was a problem hiding this comment.
Re-reading that bullet point now, it's in the wrong section.
In Germany at least companies have regular, often once a year, or quarterly or something like that, performance reviews where your line manager looks at what you accomplished and what your focus area should be in the coming months. Typically that manager is fairly close to your daily work so it's easy to talk about the accomplishments of previous weeks and months. As employees move to roles that have impact beyond their local teams that conversation needs to adjust. InnerSource is a bit special here: Contributors and Trusted Committers by their job title come from a "software engineer" background, but their impact may go across several hierarchical branches inside of the organisation - though a bit less than in Open Source: If in Open Source you work on backstage, foundation level topics, your work may impact even other corporations, but still be invisible - because private - to the person who agreed to donate your time to that foundation. In InnerSource all that remains within one corporation, but might still be out of sight for where your manager and your team typically operates.
There was a problem hiding this comment.
And with this comes the crucial part of answering the "what in it for me?" question for the middle managers. They need to be able to sell their engineers working outside of their line and have that in their KPI or else this will die really quick as it does not help them fulfill their KPI or even worse detracts from that.
There was a problem hiding this comment.
Ultimately there need to be factors that go into KPIs.
Contributing outside of your team and mentoring contributors is something that I would expect to become part of seniority levels.
If we look back to the "enlightened self interest" for open source contributions I could see something similar for InnerSource as well:
- Move faster by standing on the shoulders of giants, combined with
- accomplish more by collaborating across business units (like we do here for the Learning Path segment - we all need it, it's not a unique selling point for neither of our employers, but by collaborating we can create something that would be more costly when done internally only), combined with
- fix issues that block shipping features to your customers and move maintenance to a team that is larger than your local team
In advanced settings I would expect people to understand the value of contributors working on simpler features freeing the host team to work on more complex changes that the contributors have a business need for.
There was a problem hiding this comment.
Essentially I would like to capture some of the learnings that Myrle Krantz shared in her keynote at the InnerSource summit in that segment.
There was a problem hiding this comment.
Is there any update to make to the outline to incorporate these ideas?
There was a problem hiding this comment.
Good point - I'll see where these points fit.
| - Existing test driven development means that confidence in contributions is higher. | ||
| - XP teams have a "leave the code in better shape than you found it" attitude - mitigates the risk of decline in quality or co-hesion of code when faced with multiple contributions from different sources. | ||
|
|
||
| ## Common misunderstandings when coming from agile teams |
There was a problem hiding this comment.
Separation of ownership for a feature - Host team ultimately owns the feature design and ongoing maintenance. Guest team owns the code creation.
There was a problem hiding this comment.
I've tried to address that in the fifth section below.
Co-authored-by: rrrutledge <rrrutledge@users.noreply.github.com>
|
I've added outline-like skeletons for the remaining sections. |
|
Excited for these changes, @MaineC ❗️ Will take a look soon. |
|
Also - as an invitation to others involved with teaching InnerSource to people with less experience in open source project management - any additional feedback welcome. @claredillon I believe you had also been talking to some folks who might have valuable input here? |
|
FYi we have this early pattern draft: You might not want to link to it from the Learning Path content yet, as it hasn't been vetted by any org until now. /cc @mishari |
|
@spier thank you for the pointer, I hadn't thought of the pattern but it is a good idea to link to it. |
Co-authored-by: rrrutledge <rrrutledge@users.noreply.github.com>
@MaineC I meant this more for inspiration, and less for for linking. Once we level up the patterns to "Structured" and publish them to the book, the links can be expected to be stable. |
|
@spier thanks for the reminder about links being unstable as long as the pattern is marked as initial... |
|
I have a question: For the past few days I had a bit of time to work on the full text version (instead of just outline/ bullet points) for this learning path segment. I wouldn't want to simply push that over the discussion here, but create a separate pull request for it. Does anyone have any objections to doing that? |
Which discussion are we talking about, here? I have a note to come back to review this PR again hopefully to merge soon - it feel like we are getting pretty close or already at that point. |
That is why I think it might be best to post the full text version I have been typing up the past few days in a separate pull request that builds on this one. That way we can merge the work done here soon and continue to work on the full text in a separate pull request. Does that make sense? |
rrrutledge
left a comment
rrrutledge
left a comment
There was a problem hiding this comment.
Yes. Separate pull request for the full text sounds great.
4 participants
This adds the introduction to the product focused learning path.