feat: Add Agile InnerSource Dojo pattern

[michael-basil]

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]

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]

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]

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

Looking forward to this.

Will wait until ready for review.

[spier]

@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]

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]

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]

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]

@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]

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.

[michael-basil]

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]

@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]

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]

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]

@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.)

[michael-basil]

@spier - I cleaned up the links on this.

@MaineC @spier @tsadler1988 - I am curious if the Patlet and Problem redraft is trending in the right direction.

I am hopeful to get some engagement with Addie and Guilherme down the road, but it would be helpful to see how this is connecting or not. It's okay if not, which would mean there is more work to do to connect the dots!

[tsadler1988]

@spier - I cleaned up the links on this.

@MaineC @spier @tsadler1988 - I am curious if the Patlet and Problem redraft is trending in the right direction.

I am hopeful to get some engagement with Addie and Guilherme down the road, but it would be helpful to see how this is connecting or not. It's okay if not, which would mean there is more work to do to connect the dots!

IMO it flows nicely now :)

[michael-basil]

I am closing this pull request to leave space for #696 (Add Circle Communities) to clear and settle. I/we may redraft this pattern subsequently or we may defer depending on how that conversation unfolds.

Warmly,
Michael 🙏🌿