Accessibility Retrospectives

Reflect on your wins and identify things you wish had gone differently

An agile retrospective (sometimes called a post-mortem) is a gathering of interested and involved parties at the end of a sprint to review the project’s events and learn from the experience. The main difference between retrospectives and post-mortems is that post-mortems are generally held at the end of a project (which may consist of multiple sprints) where agile retrospectives provide insights that you can implement in the next sprint of the same project. The term “post-mortem” also seems a little ghoulish and implies the death of a project.

No single individual knows a sprint’s whole story, each person holds their piece with their own perspective. Each person only has one piece of the overall jigsaw puzzle that is the full sprint story. The retrospective gathering is the collective telling of the story and identification of learnings that can be carried forward to future sprints. With an agile retrospective, you can look into a mirror at your reflection (and others can as well) to see what you can learn.

Accessibility-specific retrospectives can come in two forms:

1. One point of view or aspect of a sprint retrospective;
2. A standalone retrospective for a sprint that was 100 % about accessibility. This might include things like deploying a new VPAT creation strategy, or deploying new automated testing resources.

The following steps come from Agile Retrospectives — Making Good Teams Great by Esther Derby and Diana Larsen.

Step 1: Setting the Stage

Retrospectives can be contentious if they turn into finger-pointing sessions. It is important to avoid the gathering degenerating into that by creating a safe space where everyone feels comfortable telling their piece of the sprint story.

Step 2: Gathering data

This is often done by looking back and identifying what went well and what did not. This is a good in-meeting post-it note exercise, but some attempt should be made to gather information before the meeting as well, especially if you have people who can’t make it.

• Give everyone a stack of post-it notes and a sharpie
• Give the retrospective participants 5 minutes (set a timer) to write down everything that went well during the sprint
• Put up the post-it notes and group them
• Then repeat the above 3 steps for everything that could have gone better.

Step 3: Generate insights

This is quite possibly the most important of the steps. Select a few of the the stacks of post-it notes with the most mentions/votes and perform root-cause analysis to identify why things happened and what should have been added, removed, or tweaked to that process to prevent it from happening in the future. An excellent, structured way of doing root cause identification is performing a “five whys” analysis.

Five Whys is an iterative interrogative technique, popular with Agile retrospectives, but usable in just about any context where you are trying to find the *source* of a problem rather than band-aiding it at some other level (which everyone knows will not prevent the problem from occurring again). The primary goal of a “Five Whys” analysis is to determine the root cause of a defect or problem by repeating the question “Why?”. Each answer forms the basis of the next question. Sometimes it takes more than five rounds, sometimes it takes less, but the average is five.

First Why: Why were there so many exceptions on the VPAT

• because there were numerous accessibility regressions?

Second Why: Why werethere were numerous accessibility regressions?

• because people were introducing new bugs

Third Why: Why were people introducing new bugs?

• Developer turnover
• Lack of training
• People with disabilities not consulted

…

So the solution is not “stop introducing regressions” The actual solution is Require more/better training, less development personnel turnover, consult with people with disabilities etc.

Note that “five” is not a fixed number. It may be more, it may be less, but it is usually somewhere around there.

Step 4: Decide what to do

Look at the items called out in the root cause analysis process and figure out what to do about them. This includes deciding on specific, meaningful, agreed and realistic actions that will be done in the next sprint. There needs to be an accountability component to this, otherwise, the same known problems will be repeated in the next sprint. Sometimes the actions required will take more than one sprint. In that case, break those longer actions down into sprint sized chunks so you can monitor progress from sprint to sprint.

Step 5: Close the retrospective

Sum up the results of the retrospective and generally leave a good feeling behind for the participants. It is important that everyone attending should leave the room with the feeling that something positive was achieved, both in the sprint being reviewed and in the retrospective itself.

Conclusion

Retrospectives are powerful tools that allow iteration on sprint activities to create a a better, more seamless accessibility process that is more tightly integrated with the projects that need to be accessible.

• If accessibility is included in a project and that project does retrospectives, make sure accessibility is part of that retrospective
• If an entire sprint or release is about accessibility, make sure someone fluent in accessibility is responsible for holding a sprint retrospective focused heavily on accessibility related issues