How we work: inclusive retrospectives for the GitHub Accessibility leadership team

Retrospectives are essential for a team’s ongoing growth and achievement, but they can be exclusionary for team members with disabilities due to the inaccessibility of most retrospective tools. These tools often depend on drag-and-drop functionality, images, color coding, and undefined digital spaces with no clear headings or navigational anchors. To ensure everyone can actively participate, the GitHub Accessibility leadership team uses tools and processes that fully engage every team member.

Who we are

The GitHub Accessibility leadership team is a diverse group that includes team members with blindness and hearing impairments. GitHub is a remote-first organization, so all of our meetings and collaborations are virtual. As one of the team’s technical program managers, I set up and run our retrospectives using primarily the following collaboration tools:

  • GitHub Issues
  • GitHub Discussions
  • Zoom
  • Slack

Our team members who use screen readers prefer to use GitHub Discussions for retrospectives rather than common web-based document collaboration tools. GitHub Discussions are well-suited to retrospectives because they support threaded conversations as well as provide the ability to vote on individual threads within a discussion. To make the discussions easy to find and navigate, we use a GitHub issue with a tasklist to roll up all the discussions in one place.

Setting up the retrospective

First, I created a GitHub Issue to house the retrospective. This includes a description of the retrospective format, a tasklist of discussions, and any shared agreements the team operates by. In our case, we used a Starfish retrospective as our format, and Norm Kerth’s famous retrospective, “Prime Directive,” as our agreement. It’s important to use appropriate Markdown format in these issues and discussions so the team can navigate by heading to understand the content of the issue, and how the retrospective will run.

Next, I created a discussion post for each category of feedback. Because we chose a Starfish retrospective, I created a discussion for each of five categories:

  1. Keep doing: what is working and we should continue?
  2. Less of: what do we want less of?
  3. More of: what do we want to see more of?
  4. Stop doing: what’s not working and we should stop?
  5. Start doing: what new things should we try out?

Once the discussions are set up, I linked to them from the tasklist in the original retrospective issue to make them easy to find and navigate. Creating a “Retro” discussion category makes it easy to look back at previous retrospective discussions.

A screenshot of a GitHub issue called “A11y EPD LT Retro.” The body of the issue says has a description of the retrospective, a tasklist of the five discussions posts (Keep doing, Less of, More of, Stop doing, Start doing). Under the tasklist is the Prime Directive:

I invited the participants to contribute to the discussions ahead of time, to allow time to read and think about the topics and to set expectations ahead of time. This is not only a great facilitation practice, but is also particularly helpful for our neurodivergent teammates.

Running the retrospective

Facilitating an accessible retrospective is surprisingly easy. Here are some things to bear in mind to ensure everyone can participate fully:

Wrapping things up

Once the retrospective is done and you have your action items, post a summary of the retrospectives main discussion points and next steps on the issue, so folks can check back and hold each other accountable.

The ultimate goal of the GitHub Accessibility program is to empower developers with disabilities to create, collaborate, and contribute. The realization of that goal starts with our own accessibility team. We intentionally recruit team members with different lived experiences. We continuously innovate and adapt our processes to ensure that everyone can fully participate and do the best work of their lives. We hope your team can benefit from our lessons learned.

Source link