Convergence Rules Of Engagement

[saintsal]

This is where we explore our various concepts for future kernel blocks, and adapt them so they fit together cohesively.

When proposing:

1. Propose only the parts of the program you are committing to design and run yourself. The main thrust of this form of communication is not to design a program that others will run, but rather to take responsibility for the part you will run and how it fits with other parts.
2. Include parts of timelines that can be combined with other concepts (like puzzle pieces.) Full program timelines can be included as examples if they combine other concepts, but be clear which parts you’re proposing to run and which you won’t.
3. Proactively seek “deference” to other concepts. What aspects of what you’re exploring don’t fit well with others, and which do? If so, how? Look at other concepts to anticipate these issues, and ask specifically about them. (Ideally, keep a section in your proposal called Deference Questions updated to invite this kind of feedback.)
4. Engage with other concepts – ask clarification questions and express which aspects of what they propose work well with the parts you will run, and which might not.
5. Focus your dialog on narrowing the range or option set specifically for the next upcoming stage gate:
   1. Gate 1: length of block & schedule communicated to fellows
   2. Gate 2: specific modules decided with input/output between them agreed
   3. Gate 3: modules prepared for execution

Remember. the most critical information in this communication is the ranges and option sets for the parts of the program you will run – here they get adapted and/or eliminated through dialog.

A useful way to communicate this with boundary objects – practical and understandable things like timelines, event formats and user interfaces – that project relevant implications to each others’ work from a common object.

[saintsal]

We’re off to an energetic, but slightly wobbly start, so here a few guide-rails that will hopefully help:

Starting module assignments

Propose only the parts of the program you are committing to design and run yourself.

This refers to the parts of Kernel already in various people’s hands:

Firesides: Vivek and/or Andy
Learn track: Andy
Guilds: Andy
Celebration: Aliya
Adventure Time: Vivek and/or Aliya
Application/Reviews: Andy
Services: Simon and/or Andy

If you have any changes you’d like to see to Kernel, the idea is that you first propose what changes you’d make to your area of “custody” or proposed custody, then the deference feedback also relates to the modules you’ve taken responsibility for.

This is useful as a filter in a few ways:

1. It makes sure that proposals are made with enough consideration to how they’ll work (they’re not just outcomes but designs)
2. The feedback loops are limited to the people who will take responsibility to see those things through to execution.

Suggestions to someone else’s section

Anyone can propose how they’d like someone else to do their module, but then these are either just suggestions that you’re asking the module owner to consider (in which case they’re not a proposal and I’d suggest those happen 1:1 before being posted here, or at least clearly marked as a suggestion in the subject, like “Suggestion for Guilds: shorten them to 3 weeks” ) You can also propose your own idea of an alternative to their module (or more realistically an overlap in some of the functions), provided you’re willing to deliver them.

Forum conventions for Converging

I think some forum conventions might help too. Let’s start with a few things:

1. When submitting a design for convergence feedback, make the subject line a descriptive label of the proposal. ie “Timeline: 2-month version with 1-week breaks” or “Adventure Time with Office Hours” That way, we can stay on topic to that idea, plus find and link to relevant threads.
2. It helps us all stay on-topic to the subject thread, and start new topics if necessary. (You can link and cross-quote to connect ideas.)

[saintsal]

Alrighty then, for the next 2 weeks, it’s go time!

First, just some quick vocab. I’ll start to use “module” as any part of Kernel we’re taking on within this convergence process. So far, we’ve been thinking about these as puzzle pieces or timelines but let’s add some structure to that.

A module can be a fellow-facing set of events (firesides, learn track, guilds…) , or some service we offer to other stewards (convo, weekly email).

While modules might overlap in functionality, each module only has one steward designing it.

Each module has multiple Options, the first being the “Fail-safe” or last known working version from kb5 or kb7. The idea with Convergence is to start by creating other Options, usually exploring a new concept, and optimizing for a single need or performance measure.

Modules will start as low fidelity “napkin sketches” exploring wide variations and possibilities, and as we progress, will become “production ready.”

Phases & Gates

Gates:

1. Thu Jan 12 - Dependency Graph freeze
2. Tue Jan 17 - 2-3 full option sets chosen, Learner-centric dry runs, Primary option set chosen with fallback options
3. Fri Jan 20 - Primary or fallback options ready to roll

These are set-based convergence phases, which is a different approach than spec-first, which is what most of us are used to. To avoid some assumptions that might lead us astray, pleaseread this short paper (14 pages) on SBCE, particularly the section on principles (p. 73 - 80).

Phase 1 - Dependency

Phase 1 is about framing these Options and is divergent.

Modules Options have dependencies on other module options. For example, Guilds and Juntos depend on the Convo app. But others will be emergent. For example, we may learn that some Guild Leaders have target personas that depend on the Application process, or explore inverting the planning dependencies between the Learn Track and Firesides.

The goal of Phase 1 is a Module Dependency Graph. Basically, this is a master list of all Modules, their Options, and which Module Options depend on other Module Options.

This will allow us each, as Module Stewards in Phase 2, to have a definitive list of which other Modules depend on us.

At this stage, we’ll be “low fidelity” sharing timelines, high-level content plans, participant criteria and major user cases or user journeys – for each Option.

We’ll also want to start to think about Trade-Off Curves that affect the performance of our Modules, as a headstart for Phase 2.

If it feels right, you can advance to more elaborate artifacts from future Phases – maybe to explore the viability of your idea with a prototype, or as a way to illustrate your concept.

The important constrain for this phase is to aim for 3-4 Options for each Module (including the Fail-safe).

The “convergence event” here is freezing the Dependency Graph. After this point, if you have a dependency on someone else that’s not documented here, that’s a problem. We’re saying to each other at this point, “the future range of possibilities I’m putting forward will be within this known set of options with this known set of dependencies on you.”

Phase 2 - Fit

Phase 2 is about converging on good combinations of Modules.

For example, working out that Fireside Option B works really well with Guild Option C, any Learn Track Option, but works poorly with Convo’s Fail-safe.

The goal is to arrive at 2-3 “full sets” or alternatives for complete Kernel programs. This will give us a few options for “Shapes” that work well together.

To do this, we’ll elaborate on our various Options, sharing more detail like deck outlines, UI flows, event formats. and test content.

Ideally, feedback isn’t given as a “no, that idea is poop” but instead responding with the trade-off curves that are causing negative ripple effects.

As we learn which of our Options are not ideal fits for others, and can start to voluntarily eliminate our own Options if we see fit. (Keeping in mind they maybe resurrected in the next block.)

Our convergence event here is to Dry Run but differently from how we’ve done it the past – this will be done as a Fellow Role Play, where some of us will act as various personas, to “user test” the experience at a high level and give feedback.

Here we should be able to prioritize which Shapes we want to elaborate on first in Phase 3, and which become “Fallbacks”

Phase 3 - Feasibility

At this stage, we have an idea of which overall shape we’re aligned towards, but since we haven’t fleshed them out completely, we still need a margin of error.

So here is where the Module Stewards get their leading Options ready to roll. If we find something that doesn’t work as well as we thought, we can switch to one of the Fallback options, since it’s still within the agreed range.

The final convergence event is a classic Dry Run, where we run through everything together (and quickly!) just to get an overall feel from a Stewards perspective and prime ourselves for the overall Shape we’re ready to deliver.

Rhythms

Daily

Every day, let’s start our Nemawashi time with a quick Agile standup (todo, doing, done in 2 minutes or less) explicitly flagging people we need to talk to. The rest of that call is in breakout rooms, mainly for 1:1 checkins and feedback.

Sometimes we may need group workshops, but I’m hoping those will be limited. Ideally, most of the communication will be Module explanations and feedback in forum threads, and when more fluid conversations are easier, that happens as needed with the next Nemawashi time being a stop-gap to prevent waiting longer than 24 hours for a needed conversation.

Phase rhythm

Each phase ends with an integration event, followed by a team retrospective.

The retrospective is focused on process, combining perspectives on what parts to keep, and parts to change. We’ll make changes for the following phase, and record Lesson Learned to remind us before the next Convergence process (KB9).

[saintsal]

@Kernel-Stewards onto Phase 2!

By now, we should have had our hard conversations and have the dependency graph locked in.
So, we can start assembling our various Options into potential Shapes of programs.

That said, as we continue to explore Options, I encourage you to ground them to reality by making prototypes with actual content, and ideally based on personas with specific learning goals.

I changed the categories in the forum to a new structure and moved some posts around.

I’d like to lean on something I picked up from indigenous knowledge in KB5 - that sufficient dialog of a certain character better serves the same goal that voting does – especially in small groups. Put another way, the chiefs know that with enough conversation around the fire, empathy and understanding is given space to emerge, and there’s no need for voting or adjudicating. Everyone already knows what to do. It’s evident.

So with the Shapes category, l’ll take the lead with one thread per Shape being explored, in the same style as “updates from the kitchen.”. Under each thread, can I ask that you follow and engage in the same type of dialog with each other as before? These expose needs in actionable ways – inputs and constraints to design for.

You’re welcome to follow my lead and suggest shapes of your own too, but I still need your feedback in the form of this kind of dialog.

We’ll modify the concepts from the design feedback that emerges from our discussions.

[saintsal]

@Kernel-Stewards The dashboard to narrow down on responsiblities and expose remaining risks is here: https://www.notion.so/KB8-Shape-Tracker-05ebfcf0ea8545ca9c930c0ea4625184

Here’s where we’re at with the possibilities: