Many companies I’ve been at are in a race to see how much like Spotify they can be and apply concepts of Chapters and Guilds. What I routinely see is companies get this bit wrong. Particularly around so-called “quality guilds.” So let’s talk about this.

Wait! What’s wrong with Spotify?

Nothing is wrong with them at all. What they do no doubt works great … for Spotify. But many companies have been in a rush to “copy+paste” what is called the “Spotify model.”

Yet as some have pointed out, doing so misses the point about the Spotify engineering culture. Others have argued that you should not just copy the Spotify model. Others have argued that you should be inspired by the model but not to the point of copying it.

There have been cautionary notes for years about this, including from Spotify. So why are companies simply copying the Spotify model? This is allegedly in service to better getting products out the door that add value by tailoring the development process to match what Spotify does.

Getting products out the door that add value is a quality concern. As such the “model” used to do such is very much a concern of testers. Or should be. But, with some exceptions, I rarely see testers talking about this aspect.

Why is that? Well, the most likely reason is that testers simply don’t see this as within their purview. But I do think there’s potentially something a bit more pernicious at work.

Previously I talked about the quote culture among testers and that’s very much in resonance with the idea of “copy pasting” ideas or concepts. I also previously talked about how testers tend to overly rely on received wisdom and that, too, has some resonance with this “copy past” idea. Finally, I also talked about testers relying on tradition and dogma quite often. Once again, there’s some obvious resonance there.

A case study of this problem is that I was recently in an environment where there was a “Quality Guild” — allegedly put in place because that was “what Spotify did.” It was part of the “Spotify Model.” I wanted to reframe that as a “Testing Guild.”

Much to my chagrin, there were testers — allegedly, experienced testers — who quite literally didn’t see the distinction between quality assurance and testing and thus didn’t see why this reframing was necessary. That was a separate issue but it certainly helped me see why none of them bothered challenging the received wisdom of having a “Quality Guild.”

But why did I challenge this bit of dogma regarding a “Quality Guild”? And how did I make the case for a “Testing Guild”?

Well, basically I said this …

Quality is a complex thing; it’s a shifting perception of value over time. As such no one team, or one Guild, can encompass quality. Yet, an interesting point of context, is that one of the core engineering values that people felt was most important at the company was quality.

So I argued that, consistent with that core engineering value, every Guild and every team should be talking about quality and what it means for their features all the time; during every sprint. So having a “Quality Guild” seemed to be a defocused from the day-to-day tasks that everyone was dealing with.

To make quality actionable — something that we could measure but also move towards — we had to provide testing. Testing is also a complex thing; it’s a design activity as much as it’s an execution activity. Testing is always performed by humans but it can be supported by tooling.

Thus the Testing Guild was framing itself to help with both aspects: the human and technology that was to be focused on running experiments to see if we were achieving the quality we believed added the most value to our features and thus to our users.

Perhaps some specific team would need help implementing better (or any) Selenium tests. Perhaps some team would prefer the use of contract-based tests or property tests but won’t be sure how to start implementing them. Perhaps some team will simply want help thinking about edge cases and corner cases. Perhaps some team would better want to understand how to write concise but not overly verbose tests. Maybe some team would want to start using a BDD approach but wouldn’t be sure how.

All of that is what the Testing Guild would be for. The guild would serve as a repository of knowledge and tooling that allowed our feature teams to test efficiently and effectively. Ultimately that would democratize testing but also, importantly, distribute quality assurance.

I hope this provides an example of having testers lead the charge to reframing a bit of received wisdom (i.e., the “Spotify model” and a “Quality Guild”). This allowed us to put in place something that made sense based on some thinking around the concepts related to quality and testing rather than just taking someone else’s ideas, from their culture, and copy+pasting them into our culture.