Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add Agile InnerSource Dojo pattern #695

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

michael-basil
Copy link

This pattern follows on from recent presentations with the ISC and many conversations.

This is still in draft while we allow space for final commentary before formally proposing it.

@spier
Copy link
Member

spier commented Jun 23, 2024

I suspect this pattern is related to this ISC Community Call?

Do you already want feedback, or should I wait until you mark it as "ready for review"?

@michael-basil
Copy link
Author

michael-basil commented Jun 23, 2024

Hello @spier,

This pattern is definitely related to what was described in that community call.

Please defer feedback until it is marked ready for review.

There are 4 people who I am specifically leaving space for that have verbalized they would like to contribute and or do a coherency check (relative to previous or ongoing conversations).

That said, if you or anyone wants to discuss informally in Slack or in a synchronous call please send me a DM.

🌿

@spier
Copy link
Member

spier commented Jun 23, 2024

All good the. Just wanted to see if you need any help.

Looking forward to this.

Will wait until ready for review.

@spier
Copy link
Member

spier commented Jun 23, 2024

@michael-basil just two technical tips that may help to get this merged into main faster

a) On the PR you see a couple of alerts by the GitHub Action "vale", which are related to spell checking. I can help to fix those later, so you can just ignore them now.
b) For most patterns we recommend that they first get integrated into our repo in maturity "Initial" (i.e. in the patterns/1-initial folder). That way the patterns don't go live in our online book immediately, and it allows us to collect more feedback from the community and harden the pattern before publishing it more widely.

Thank you already for working on this pattern and for even considering to share it with the InnerSource community ❤️

@michael-basil
Copy link
Author

Thanks for the technical pointers @spier.

I have made the adjustment to the status to be Initial as you suggest. I was hazy on that, but thought it may be Structured since there are multiple known instances.

Very excited to work on these patterns and for the help.

🙏🌿

@tsadler1988
Copy link
Contributor

This feels to me like a great known instance of #696 rather than a separate pattern, so I'm unsure we need both patterns. But I may be missing something!

@michael-basil
Copy link
Author

Hi @tsadler1988, fair point and nice observation. I thought about that before drafting.

In software design patterns there are composite patterns, perhaps this is an example of that.

In any case, a Circle Community is a much simpler instance to apply (or to become aware of).

Spinning up circles was relatively straightforward and we will have maybe one more example which is separated from the Dojo example on 696.

Launching a Dojo has similar motivations and forces, but the intention and investment is huge in comparison.

There is much more nuance and expertise that needs to be brought in or built up over time.

Essentially this is running a change champion network once we center on Priortized Mentorship as a driving principle.

Does this help clear it up a bit? Perhaps we will need to collect more feedback.

@aphor
Copy link

aphor commented Jun 24, 2024

@tsadler1988 I can see where you might get the impression that a dojo practice is just a circle, but there are some differences. IT may be appropriate to employ a circle but not a dojo in some circumstances, and in other circumstances it may be appropriate to employ a dojo with no matching circle, and other circumstances might best fit both or neither. This, as I see it, makes them functionally orthogonal.

A circle is primarily a group forum where everyone participates interacting together synchronously. It may be videoconferencing, but it is still face time in a big group style communication. There is also a huge emphasis on equality of opportunity to contribute to the circle. The goal of participation in a circle is primarily to hear voices and input that one might not ordinarily expect to get in the course of work or conversation outside the circle. The only work that gets done in a circle is dissemination of information or agreement between the participants about the information disseminated. It plants the seed though. A circle can be measured or quantified by enumerating the participants and the information disseminated and agreed upon or disputed. A circle is a facilitated "safe space" for contemplation together.

A dojo is primarily a learn-by-doing curricular framework (an expensive work product as @michael-basil said) where people who ascribe to a discipline described by a curriculum are conferring or reinforcing skills to/on each other. This interaction need not be synchronous, and might be 100% asynchronous if, for example, the dojo discipline is all about how to approach certain software engineering process problems using the pull request pattern. Rather than being a roundtable forum for gathering diverse voices and perspectives from participants who are treated as equals, a dojo encourages paired interactions between those who are more experienced and those who are less experienced. It lends itself to (but is not limited to) paired interactions (and especially pair-programming). It's not equal, just equitable. Those with more experience owe forbearance and patience and discipline to those less experienced as they interact in a dojo, and those with less experience owe a certain amount of diligence and deference. A dojo puts a pattern into practice, and while it is a learning process, participants learn by doing and work products should be expected to emerge from dojo practice. A dojo can be measured by enumerating the work products of those who progress through the challenges. A dojo is a supervised "brave space" for challenging each other.

It's not always easy for an experienced insider to distinguish two closely related concepts when explaining them, so I would like to hear whether or not this explanation makes sense and how that should inform edits to clarify the pattern descriptions. If they look redundant to people reading this the first time, we're missing something. I feel like this edit has gotten too wordy though (so I don't feel great about just pasting this content into the pattern pages), and I'm not sure how to strike a balance between clarity and brevity. Maybe someone else can help identify key distinctions that would draw a bright line between circle and dojo practices to add in?

@michael-basil
Copy link
Author

Great conversation @tsadler1988 and @aphor ....

I will add just one thing before stepping back to see what @tsadler1988 and or others may have to add into the mix.

I had been waffling on adding Agile to the front of this pattern name. Now I understand that it makes sense why I put it there.

Agile (and DevOps) dojos (at least in North America) feature immersive learning. So Agile implies Lean thinking and dojo is a strong metaphor which the draft qualifies in the concepts of sensei and senpai.

The point of a learning system like this relative to InnerSource is that there will be a LOT of resistance and impedance to helping InnerSource movement, policy and strategy take root. Much nourishment will be needed over a LONG LONG time for many larger, more established organizations.

Dojos are not uncommon in Agile circles generally and do very well when the dojo is InnerSource based to the core.

My hypothesis is that we will be able to distill some finer points of distinction once we understand the gaps / disconnect in perception.

@tsadler1988
Copy link
Contributor

I understand, thank you for the additional context @michael-basil @aphor! We have a similar separation with different types of community (I'm going to try and get our internal community people to talk or blog about this because I'd love to have sources to reference!).

  • Community of Belonging - informal, mostly social/support networks around various affinities such as location based or diversity groups e.g. Manchester social group, internal Pride network
  • Community of Interest - sharing knowledge and resources of a given topic such as a tech stack or methodology e.g. InnerSource, JavaScript
  • Community of Practice - similar to a community of interest but actively working towards agreed standards and preferred approaches rather than just sharing knowledge and resources
  • Community of Action - deliver something tangible e.g. training, documentation, shared tooling

So I think a Circle would map to a Community of Interest, and a Dojo would be a training based Community of Action. Some people would group Communities of Interest, Practice, and Action all under the heading of Communities of Practice, but from both our experiences it seems more granular definitions of communities can be useful.

For the Patterns then - we could leave these 2 as separate patterns or we could merge them into 1 'internal communities' pattern which would describe these 2+ different types/levels of community. But perhaps the dojo specifically is a powerful enough pattern to be called our as its own thing.

@michael-basil
Copy link
Author

Dojo is powerful as a stand-alone pattern because of the audiences who can pull and apply or notice and label.

Agileists to consider InnerSource

InnerSource/ DevOps to consider Agile

Other blends like this

Agile InnerSource Learning as a foundation for technology / support domain up skill

However the deep value in this pattern is in the socio-technical learning system featuring Systems Thinking and Priortized Mentorship to the highest levels.

These two pattens can be used for outreach and inreach throughout Agile, DevOps and InnerSource based communities.

Independently and or interchangeably and at the same time.

Evidence for this claim is the request for presentation from the ISC and then this past Friday with Cloud Security Office Hours.

It is possible to know what is meant by these words intellectually. If it can be directly related to existing understanding to a similar mentorship model reasonable coherent understanding is achieved ... though people familiar with Agile / DevOps
dojos like those familiar with Dojo Consortium in North America and or Aikido or other martial arts get it right out of the gate.

The dojo metaphor tested out neutral to positive with just about every case encountered with SAP over 6 years. Vetted by marketing and legal as well.

It is considered fair and or positive and endorsed use by every Zen or Martial arts expert I have had mindful discussion with.

Dojo is an Extreme Programming practice of System Metaphor.

This is powerful and lightweight Agile.

I learned a lot more about deep cognitive linguistics and metaphor through my interactions with a few Germans at SAP who turned me onto Metaphors We Live By written by Lakoff and Johnson (who give talks at Google and such).

When I took this conversation back into the backwoods old school Agile communities I found it was a strong 💪 part of the thinking underpinning the Design Thinking aspects of Agile practices.

But I digress!

@michael-basil
Copy link
Author

@tsadler1988 @aphor - I added links to the SAP Samples and Dojo Center models (live / demo and source) as a way to qualify the pattern more.

@michael-basil
Copy link
Author

Did a light touch on this with @tsadler1988 during a call. Good to go to move this into review it seems and allow for other feedback.

@MaineC
Copy link
Member

MaineC commented Jun 28, 2024

Leaving the comment here instead of at the pattern draft:

Reading through the draft it seems to focus very much on the solution. However I am unable to find information on the problem the pattern solves.

It would help readers to describe the situation before the pattern is applied: What is lacking? What is wrong? Which symptons should one look for that should trigger applying this pattern? There is a lovely template for patterns that helped me a lot understand exactly which information goes into each pattern section.

One example of what I mean: In your patlet, you summarize the solution. However in the template it says it should contain a combination of problem and solution: "Concise 1-2 sentence description of the problem and solution."

That way readers can easily identify if this pattern might help them address a challenge that they are currently facing.

@michael-basil
Copy link
Author

@MaineC - I took a step back after looking at the link you provided. However, the prompting questions you suggested were most useful.

I made a commit to modify the Patlet and Problem.

Is this going in the right direction? (It will need more distillation and refinement perhaps.)

Co-authored-by: Sebastian Spier <[email protected]>
Co-authored-by: Sebastian Spier <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants