Principles of Great (Accessibility) Work

”You can’t disappear into a cave and come back with something 10 weeks later” — this is often one of the critiques of waterfall or other project delivery methods. The people you’re delivering that “something” to have no visibility into what work is happening, nor do they have the ability to give feedback on progress. Often this isn’t a good experience, especially when stakes and emotions are high (as they often are with accessibility work).

I learned a LOT about agile methods, lean, and other ways of working through founding Simply Accessible and leading the team for almost a decade. I had a tremendous leadership team to learn from, and I’m really grateful for all that time we had together. Charles Callistro, Elle Waters, and Jeff Smith: you all really pushed us to explore what agility might look like for us and shaped it into a practice… evolving it from its humble beginnings (“we need a tool like Jira to manage all this work!”) to excellence in execution throughout our entire team.

We made these moves because almost all of our clients at Simply Accessible were using some form of agile methodology to work. We wanted to make sure we were speaking the same language. We wanted to connect with them. We wanted to make it easy for them to work with us.

We asked ourselves many questions that were driven by agile (or at least agilish) principles:

• What “work” is valuable to our customers and their users of what we’re producing?
• How does that answer change over time?
• How can we reduce the time to our first delivery of value to those customers?

When our team answered those questions, it became clear to us that we were going to change the way we worked. If you engaged us to do an accessibility assessment of your product, we ran that entire engagement with ”being more agile” in mind:

1. We planned for success together: we brought our team and people from across our client’s team(s) to collaboratively plan what success would look like along the way and ultimately how we'd know we were done.
2. We broke down the work into iterations. Instead of going away for 10 weeks (into a dark cave) and coming back with a completed report that we plunked down on their desk, we broke down our testing and delivery of results into 2 week sprints. No dark caves. No customers wondering if any work was happening. No phone book of results to overwhelm them; instead, they received something that felt possible.
3. We defined working software. When creating software, a sprint’s goal is often to prioritize and deliver ”working software” with each iteration; so… what was our version of “working software” when we were actually delivering a report and set of accessibility testing results? Our answer: a cohesive unit of work that could be acted upon by our customers.
4. We created a visible backlog of things that were candidates for testing — that might include 100+ components or partial screens. We’d work with stakeholders to groom that backlog, make sure we had what we needed for testing ahead of time. AND — it was completely transparent and visible to our customer via shared Kanban boards.
5. We planned for changing priorities. The item that was originally number 15 in priority, sometimes became obsolete. Or the parameters changed because a new version was available, or someone had made a decision the last 2 weeks that made testing that particular thing irrelevant. Sprint planning in the form of reviewing the backlog and discussing priorities became a really important part of our collaborative work with our customers.
6. We aligned our ceremonies & rituals. We created ceremonies that served similar purposes to a sprint demo — “a demo of working software that was completed in the sprint” became “a walk through of actionable test results that were ready for the customer to review and respond to.” Part of that was an internal benefit for our team — we delivered a small chunk of work, got feedback, and got to celebrate a win. It was also an external win; we worked in a similar fashion to our customer’s teams. Shared ways of working helped created a great working atmosphere.

Look, that’s not everything that we did, and we didn’t always get it right. Ultimately though, here’s how I know it worked:

One of the things I’m most proud of from our time at Simply Accessible was that the feedback our customers gave about working with us was rock solid. We had such an outstanding team from 2011 to 2018. Sure, everyone was a tremendous accessibility professional. But it wasn’t their accessibility subject matter expertise or leadership skills alone that made the difference. Two key mindsets made it all happen:

First: everyone approached our work with a willingness to try new things, to experiment, to learn from it, and put it into practice.

Second, and maybe most importantly: we were all in on ensuring the ways that we worked were aligned with what would be most valuable for our customers.