June 4, 2018

Quality Lessons Learned at Accolade

By Stepan Kvetensky

I was always nodding to articles that said to unify your vocabulary first within your team, thinking “well, that's obvious.” But here I am, putting together “the obvious” and believing it's important to write about. In case you have the “that's obvious” reaction, please bear with me for few more minutes: I have some lessons learned that might come in handy.

Throughout my career I have spent 10+ years navigating through different companies' quality assurance waters (from rigid waterfall and RUP to Agile processes experience). Usually working in a QA related org, I found that somehow everybody automatically used a very similar language and if not, it was usually a very quick discussion to get everyone aligned. What I have not realized until recently is that this doesn't work as well for teams with Agile and DevOps approaches that are built from the ground up in a start-up or grown-up-start-up company.

In my previous gigs, I underwent the transformation from rigid specialty formed teams to agile teams. Since such teams were already used to working with each other in isolated silos, the vocabulary had already somehow leaked from one silo to the other. When distorting the silos and distributing people to full stack agile teams, the quality related vocabulary had already somehow been established from history, and small misunderstandings were usually solved during standup or after standup discussions. When a new-joiner came, since everyone already spoke the same language, he/she quickly picked-up and adapted. Moreover, cross-team communication worked the same way, since all teams evolved with the same QA core background - usually coming from and kept by the formerly QA silo team member/s (since quality is somehow in our DNA and we apply it to everything ).

Right after joining the QA team at Accolade two years back, we quickly identified we were speaking quite different languages (the team doubled in size within a month, bringing people from very different backgrounds).

Our first and “that's obvious” reaction to that was creating a wiki page that defined the basic quality related terms and making sure everyone was aligned.

At the very same time Accolade started the “Agile & DevOps” transformation, some of us formed a servicing team (quality related frameworks, infrastructure and approaches) and others joined respective full stack agile teams. My first thought was, I have already gone through this -it will work perfectly from the vocabulary perspective. What I didn't realize was that at the very same time, the company grew significantly and new teams spawned that either did not have a “QA representative” at all or the QA rep was a new joiner. Moreover, as a company, we did not have enough time to ingest the common quality vocab (in my previous gig that period was years long, but here it was few weeks), so (not so) obviously, cross-team quality related communication suffered.

This worked for the teams that had someone with Quality Assurance role experience. Where it was staggering a bit was in teams lacking such experience. The language defining the quality vocabulary was simply expecting readers to have some quality related knowledge.

Did all of the above help to avoid miscommunication? The honest answer is “Yes, but not absolutely.” It has mitigated a lot of misunderstanding and we are experiencing far fewer issues than two years ago. The biggest help is we have a well-established resource you can point someone to in case such a situation happens, and we do not have to spend time trying to explain, for example, the difference between functional and non-functional testing.

I hope the above will help you to revisit your “that's obvious” reaction and “everybody knows this already, I don't have to explain” thinking same as it did for me, as well as give you a bit of assistance for dealing with quality-related language differences. Always remember that what might be obvious to you might not be obvious (or even might be a completely new experience) to others.

Have you experienced some lessons learned related to quality related language differences? I would love to hear about them from you in the below comments!