New pattern: Cross-Team Retrospectives

[MaineC]

This adds a new pattern at initial state that recommends running regular cross team retrospectives in particular for long running collaborations between host team and a stable set of contributors.

[spier]

@MaineC thank you for sharing this.

While it may sound simple, I have also seen time and time again that at the end of the day it is often such misunderstandings in communication that make projects fail.

The pattern sounds like it pulls experiences from existing literature about how to run retrospectives and blameless postmortems. Are there references in particular that we could point to from this pattern, for people that want to facilitate such cross-team retros?

[spier]

@MaineC have you seen an equivalent of this patter but in the open source world?

I am asking as solutions in the open source world may contain some ideas for how to run such formats in remote teams.

[MaineC]

I've found remote works pretty well with tools like Miro and the like.

Different timezone is what causes issues the most as that needs async.

In the open source world things like conferences are often a good way to convince employers to pay for travel and use for resolving issues face to face.

[MaineC]

The advantage that InnerSource teams have is that typically within a corporation there are ppl who can help facilitate such sessions, so a bit more formal structure actually is feasible - though often retrospectives are the last that ppl think of.

[MaineC]

Though in corporate open source you tend to have dev rel ppl who help keep the link between committer and contributor...

[MaineC]

As for references, honestly it's mostly based on over a decade of doing such things if nobody else steps up, so I don't really remember where I got the first ideas from.

What I do use though is whatever Google points me to for inspiration for check-in and checkout questions - I'm just awfully non creative for those...

But there is tons of literature on running retrospectives out there.

The one thing I would not mention in this pattern is post mortem. For a very personal reason: I have seen teams push out retrospectives until the project was shipped. They then decided to run a project retrospective. Usually this behaviour leads to a place where issues are found, but never addressed because they are forgotten until the next project (well, unless the team decides to share the lessons as patterns with us ;) ). Essentially this type of retrospective is a post mortem for the project, except often one with little use and this one that frustrated people because the next post mortem is likely to uncover the exact same issues again...

[michael-basil]

This is an interesting pattern. I'd be open to a 30 minute chat about it to unpack it a bit more. I'd like to hear more from @MaineC (or others) about the motivations and experiences. If that is desirable, feel free to put 30 minutes on my calendar: https://calendar.michael.basil.one.

If not, I will observe how this unfolds. I am refreshing my Agile certification currently so conversation seems particularly relevant.

[MaineC]

@michael-basil while I appreciate your offer for a 30min slot for discussing the pattern for the sake of keeping other watching the conversation here in the loop, I'd prefer to try and keep at least the initial discussion here until the point where we notice that it's no longer feasable.

And yes, the idea to try out a retrospective was based on positive experiences in agile teams, so likely it's a link there.

[michael-basil]

If there is no perceived benefit from a 30 minute break out and sharing back any useful insights here and or in Slack then it wouldn't make sense to meet.

Not a problem at all from my perspective.

[zkoppert]

Really love the idea here around retrospectives based on the InnerSource project rather than just teams doing retrospectives for their areas of ownership and overlooking including outside contributors. We haven't done this at GitHub to my knowledge but I will be looking for an opportunity to test drive this pattern!

Thanks for taking the time to put all this together @MaineC !

[spier]

The one thing I would not mention in this pattern is post mortem. For a very personal reason: I have seen teams push out retrospectives until the project was shipped. They then decided to run a project retrospective. Usually this behaviour leads to a place where issues are found, but never addressed because they are forgotten until the next project (well, unless the team decides to share the lessons as patterns with us ;) ). Essentially this type of retrospective is a post mortem for the project, except often one with little use and this one that frustrated people because the next post mortem is likely to uncover the exact same issues again...

This was likely a misunderstanding.

I did not mean to suggest to use a postmortem after the project is over to address the issues described in this pattern.

Instead I meant that the techniques and mindset suggested by blameless postmortems can also be helpful when running retros with InnerSource teams where there is tension in the room and vulnerability-based trust has not been established yet.

I can try to find other references that contain helpful background information in support of the ideas of this pattern. Will add them as inline suggestions. Then you can decide whether you think they support the readers of this patterns.

Thanks again for sharing this, and also great to see that a couple of people are contributing to the conversation already 🥳

[MaineC]

Sorry for the confusion. I did get you meant the techniques of a blameless post mortem. And those are great.

I've just seen that readers easily dwell on the post mortem part and run into issues as a result. That's why I'm itchy about including the term post mortem.

Maybe better mention specific techniques for blameless communication.

[spier]

Nice simpler pattern @MaineC. Those are often the best!

Left some comments inline, and already merged trivial fixes.

One general thought:
As another outcome of the retros, would you expect improvements to the Base Documentation and possibly the Trusted Committer documentation (path to become TC) as well?

If yes, maybe that could be added somewhere.

[spier]

I would include the cross-team bit here, as that is the key difference to a regular 1-team retro here.

Or maybe "Maintainer + Contributor Retrospectives" or similar.

[MaineC]

@spier thanks for the feedback. I also added a link to the page I typically use to generate checkin questions. I tried to find the one I used years ago for retro formats, but somehow that particular one is gone. It might be helpful for the pattern if there are others that people typically use to add those.

[spier]

@spier thanks for the feedback. I also added a link to the page I typically use to generate checkin questions. I tried to find the one I used years ago for retro formats, but somehow that particular one is gone. It might be helpful for the pattern if there are others that people typically use to add those.

@MaineC fantastic! I added one retro tool that I know, and made other minor fixes.

This pattern is already great as is. Therefore I am merging this to give it more exposure as part of the repro.

[spier]

The pattern is now available on main:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/cross-team-retrospectives.md

Curious to hear if we find others that have tried this or other methods to resolve collaboration issues between TCs and contributors.

Thanks a lot for sharing this with the community @MaineC ! ❤️