pattern/change-developers-mindset

[dicortazar]

Related to issue #39

[NewMexicoKid]

Comments from the Fall Summit:

• Describes a common situation: support from upper management and developers in the company; but middle management isn't supportive (or anything outside their BU).
• Fourth bullet is a good building block (successful group); just need to publicize it to show it can scale up -- shows feasibility.
• Really like "Developers are formed in agile, the shift from agile is difficult". We all understand the benefits Agile gave us, but InnerSource is another step in showing how we can change people's minds.
  • What is the real difference between Agile and InnerSource?
• Context (middle-management) and problem (emphasizes developers) -- this is a little confusing; what is the pattern we're trying to solve?
• Agree: they are giving us one piece of the situation but not the entirety. What other contributing factors are there? CIO support?
• Top-down -> Top (in Context)
• There are too many patterns in this pattern. They talk about size of developers; and also about training; and the shift of methodology; then how management gives back support. Tons of things.
• Within forces: no formal training; in Problem: developers are actively resisting the change. Do they not know how? Are they trained? Probably a separate pattern for either one of those.
• Context: change the language around; there is already a successful group in the early stages. Successful in what way? Other people are contributing to the asset? What does success mean here?
• Managers are previous developers... (force); how does that tie in with this pattern? How does performance management (promotion) play a role? Needs to be integrated further into the pattern. Be more up front with this.
• Listen to manager complaints and fears and counter them.
• "Give middle-management specific objectives" -- not giving them objectives; they should want to participate in the program.
• No direct advantage from top management in using InnerSource development in the short term. You have a gain in the long term but not direct game on a single product or development.
• Executive management supports InnerSource; all this says is put this in their objectives.
  • but communities are made of volunteers; teams are told to participate
• InnerSource as the marshalling of resources across the company to pursue a specific goal.
• Change the developer's mindset is good; focus on developers and their resistance. Get middle-managers out.
  • we have two teams: one is very InnerSource-friendly; the other doesn't want others touching their code and they don't want to use new tools. How do we change those people's mindset to be open to change? How do you address the fear of people forking the code and then running with it without attribution?
• Another pattern: help middle-managers. Often they aren't getting the support they need (resources, time and attention)
• A lot of people are resistant to change. You can be scared to show that your quality isn't good. Some people can be scared about exposing themselves to potential criticism.
• There are two different patterns: There is a pattern for people who have been in the company for 20-30 years and have done things for a consistent way. Vs. someone who doesn't have the skillset and training.
• Resulting context says using several projects across the several development teams. Collaboration within the same developer team.
  • need a group or individual acting as the advocate to do hands on training to speak to issues, to advertise and sell the idea. The push has to be real strong; you need to make a commitment to enacting the change that the CIOs want. Who will give the hands on training, show them where to find documentation, etc. This is missing.
• Solution improvement:
  • having a beachhead or key disciple inside the team is the most effective. Find the one person that the rest of the team will trust. Get that person onboard. The influencer.
• Solution: For formal training: In Open Source there is no formal training; you learn by doing (self-teaching). This gives you knowledge on how to do things. You find others who are doing it. The space of doing and experimenting (and even failing) is better.
  • Agree except with the inception and kick-starting of projects; README.md, CONTRIBUTING.md, HelpWanted.md -- if you don't know how to establish that...
  • The way we've done it: buddy somebody up with the team that was doing it very well and give them a paired, joint goal. Get them out of their physical location so they are in a new, uncomfortable space with a person helping them not to fail. Formal but not written down. Mentoring. We found that it is a very visceral feel for the developer to get more productivity. We have a quote log whenever somebody says something cool in their job.
• Solution: You should let your developers contribute to open source; learn new things. Having some dedicated time that you don't have to give back to the product where you are focused the other five days. Where you can learn by yourself and contribute to open source. "Formalize training." - Continuous learning and education.
• Solution: doesn't call out anything on tools specifically. Trust (built over time) and tools -- some people are very particular about the tools they like. Top down mandates on tools can backfire. Some tools aren't conducive to InnerSource. So you should have an assessment of tools.
• Technique to change the community: ignition camp: each team that was going to use the tool; if you have a real customer opportunity (business results), you can come to our HQ, ship your equipment ahead of time; 5 day bootcamp, we'll teach you open source tools, methodology, platform; then we'll do a hackathon on the solution (cradel to grave process with a prototype); we get a community, they get a working solution they can push to their customer. And they are productive now--they know how to push and pull off the server. Managers love it because it is tied to real business results. We didn't use the word training; this is driving orders in the next queue and the queue after--scaled quite nicely.

[dicortazar]

Wow, thanks for the so detail feedback from the commons @NewMexicoKid I'll try to come back with a new version of this and try to push this forward.

Thanks!

[spier]

@dicortazar the pattern proposed in this PR looks to be a duplicate of this existing pattern in master. Note that the file has a slightly different name: change-the-developers-mindset.md

I compared both files (from master and this PR). There are some differences but I cannot tell which version is newer or better.

Do you recall what work you had still planned to do on this PR?

[lenucksi]

@dicortazar the pattern proposed in this PR looks to be a duplicate of this existing pattern in master. Note that the file has a slightly different name: change-the-developers-mindset.md

I compared both files (from master and this PR). There are some differences but I cannot tell which version is newer or better.

I did the same comparison and found that the differences are

• clarified writing this PR does have valid textual contributions that we should merge.
• different sorting of sections
• added empty Patlet section
• removed mostly empty Status and See Also section

Do you recall what work you had still planned to do on this PR?

Who do you refer to here? Last longer contribution is by @NewMexicoKid. I'm not sure if this has already been incorporated or discussed fully.

[lenucksi]

Please take a look at @NewMexicoKid's detailed review comment and discuss it's contents as commit suggestions and review comments against the now fixed to be mergable pull request.

[spier]

@lenucksi just to confirm:
You are talking to @dicortazar and @NewMexicoKid, as the contributions on this PR are from them, right?

[lenucksi]

@lenucksi just to confirm:
You are talking to @dicortazar and @NewMexicoKid, as the contributions on this PR are from them, right?

Yes! You are welcome to add your insight and discussion elements too, if you have any, though! :)

[spier]

@NewMexicoKid your feedback in this comment is fantastic. As this PR is open for so long, I opted to merge the current status to master, so that the improvements that this PR already contains are shared with the broader community.

Also @dicortazar if you should have made any further experiences with this InnerSource challenge and pattern in the meantime, feel free to open a new PR.