Neighbours: knowledge across teams | kanman documentation

Teams in one workspace often work next to each other: in the same group of repositories, on the same service, on the same tickets. kanman knows who works on what, so a question never ends with “I can’t”. When something lies outside your team, kanman names the team that works on it and offers to ask them.

You: Why can’t you read the C4 model?

kanman: It lives in arc/platform-design, which is not one of this team’s repositories. Team Architects works in that group (lead: Ada). Shall I ask them to add it, or to give this team access?

Where to find it

Open the team’s Mind tab, click Memory, then Neighbours (/<workspace>/teams/<team>/mind/memory/neighbours). You see:

Teams near this one: every team that works on the same repositories, groups, services or ticket groups, why (for example Works in arc or Service Engage), who leads it, whether it shares its memory, and the titles of its memory pages.
Sharing: whether this team shares its memory with the other teams.
Requests: what kanman asked other teams for this team, what they asked you, and the answers.
Across the workspace (owners and admins only): every pair of teams that overlap.

What kanman may use from another team

Facts are open inside the workspace: which team works on which repositories, groups and services, who leads it, and the titles of its memory pages.
The content of another team’s memory only when that team shares it, or when the person asking belongs to both teams. kanman always names the team it quotes (“from Architects’ notes: …”).
Code only through your own team’s access. Knowing that another team has a repository never lets kanman read it.

Sharing is off by default. A lead of the team switches it on under Neighbours > Sharing. Then kanman may quote your notes when it helps another team, always naming your team. Switch it off at any time; other teams then see only the titles again.

Asking another team

kanman asks another team only after you say yes. It puts one short request to that team’s leads as a card in their team chat: who asks, what and why. A lead answers with Agree or Decline and an optional note. The answer comes back into your chat as a reply to your question.

A request never grants anything by itself: the other team adds the repository or the access themselves. While the request is open, the stories that need it show who they wait on, and an open request also appears in the other team’s lead brief, so nothing waits silently.

Commitments between teams

Everything one team waits on from another is a commitment with a name, a deadline and a status, wherever it comes from:

a request kanman asked with your OK,
a story that needs another team’s repository or service,
a link in your tracker, for example a Jira issue is blocked by OTHER-123, when another team of the workspace works in that tracker project. kanman notices the link on its own; nobody has to ask.

Each commitment has an owner in the other team: the person the linked issue is assigned to, otherwise the team’s lead. The waiting story shows it (“Waits on Ada (Platform): OTHER-123”), both teams’ chats say it once, and the owner sees it in their lead brief. Under Neighbours > Requests every commitment lists who owes it, its deadline, the linked issue and its state.

The linked issue’s state in the tracker keeps the commitment up to date. When the issue is done, or the link is removed, the commitment is resolved: the story moves on and your chat hears it.

When a commitment is overdue, kanman reminds its owner, at most every two days and three times in total. One person gets one message however many teams wait on them, and your chat sees each reminder. After the third, kanman stops and suggests talking to them directly.

Changes other teams use

When your team changes something other teams build on, kanman tells them before it ships: an API route or OpenAPI spec, a protobuf message, a shared library, a database table, an event or topic format, a config key. It checks this for every merge request of your team (its own and the ones it reviews for you) and when an issue or epic in your tracker announces such a change.

kanman searches the other teams’ repositories with their access and passes on only where the change is used: the team, the file and the line, as links. It never copies another team’s code into your chat.

When another team uses it, both team chats get one card, Change across teams:

what changes, and whether old code keeps working,
each affected team with the places in its code,
the rollout order: consumers first (they adapt, then the change merges), compatible (old and new side by side), or the change first,
a proposed story for each affected team.

The affected team’s lead decides: Accept story puts the story on their board (it wears a small chip that opens the card again), Decline says no, both with an optional note both teams read. A change that must reach the consumers first waits until every affected team decided, unless your own lead taps Let it merge now. kanman never edits another team’s board or code, and the card says whom it waits on and until when.

Releases across teams

Sometimes several teams have to ship together: linked merge requests, one fix version or epic in your tracker that spans teams. kanman then keeps one Release across teams card in every team’s chat:

the order in which the teams ship,
a checklist per team, which that team’s members tick on the card,
the linked merge requests, issues and fix versions,
what holds the release now.

Each team’s lead taps Ready, Hold (with a short reason the other teams read) or Shipped. A merge request of the release merges only once its team is ready and the teams before it are. kanman never merges or deploys for another team; when every team shipped, the card says so. Stories of the release wear the same chip on the board.

Where it helps on its own

Incidents and tickets: kanman mentions when another team works on the same service, and links incidents of several teams that are one incident (shared incidents).
Security advisories: when an advisory affects several teams, kanman says so once and points to how another team fixed it.
A new team: kanman looks at its neighbours’ shared notes and conventions first.
Setup reviews: kanman can suggest a practice a neighbouring team uses.