Quality Strategy Workshop

In Swiss Cheese Model, I mentioned running a quality workshop as a way to implement the idea behind the method. Here is a more detailed look at this particular workshop.

The workshop itself is split into 5 parts:

  • Who Cares
  • What Cares
  • Our Cares
  • Our Layers
  • Analysis

Identify the affected personas and what their needs/wants are
prioritize the targeted personas, but still paying attention to how the non-targeted should be affected
Also identify malicious personas you want to block
Computers/programs are also personas as what a different set of code needs is different than what a human needs (human readable vs machine readable)
Identify the architecture from a QA point of view, specifically paying attention to integration points

Who Cares

Time estimate: 10 minutes

In this, we identify everyone who is affected by the project. Most projects will have:

  • Users (aka, who is directly using your project)
  • Business (aka, who is paying you to build the thing)
  • Development Team

Some other personas to keep in mind:

  • Malicious users (what could this project inadvertently give them access to?)
  • Other projects (will other projects rely on this one? Do we need to think about machine readability?)
  • End customers (if different from the direct users - for instance if you are building an API, your users and end customers are different)
  • Data analysts if your company uses them
  • Other groups within the company who need to use data or other aspects from your project (eg, does your company have a separate platform team who needs to support the infrastructure?)

Once there are no more ideas for who, we move to asking what do they actually care about - specifically identifying needs and wants.

Some examples for the first 3 groups listed above:
Users:
Need - able to accomplish goals using project, stable project
Business - Project generates money when launched, customers like business more because of project
Development Team - Easy maintenance of project, able to add features quickly, able to onboard new team members easily

Even if not all needs and wants are in scope for the project, being aware of what folks are trying to use the project for feeds into a quality strategy.

What Cares

Time estimate: 10 minutes

In this section, we will draw a high level diagram of the project’s ecosystem. We are specifically looking to identify integration points and characterize them. An integration point can have a variety of characteristics, and we want to pay special attention to:

  • Relationship within the integration point (is it between two projects in the same company? A 3rd party company?)
  • Volatility of the other member in the integration (is it liable to change rapidly in big ways?)
  • Maturity of documentation, community, and support of other party (if you run into issues, how easy is it to get answers?)
  • Integration testing (is there a sandbox environment or something similar?)

Our Cares

Time estimate: 10 minutes

Here, we brainstorm concerns the quality strategy should address. The previous 2 sections should provide a lot of inspiration and this is where team members can bring prior knowledge and experiences into the conversation.

As a bonus, you can do this section with a Impact / Likelihood chart for the concerns.
As a bonus, you can do this section with a Impact / Likelihood chart for the concerns.

Our Layers

Time estimate: 5 minutes

Now we finally look at the current state of our quality strategy, if there is one.

We create a sticky and row for every layer. If the layer’s purpose is already known, that can be added as well.

If there are layers which have already been planned to add, they can also be added with an asterick.

Once some layers have been added, participants can start dragging concerns over to layers which should be covering them.

Analysis

Time estimate: As much as possible

Here we begin by looking at existing layers and making sure they all have a purpose attached as well as at least one concern. If a layer is missing purpose or concern, ask the participants what it should be. If they have no idea, propose deleting the layer (as an action). If accepted, strike through the layer.

Additionally ask which layers are not working - are there layers which are painful to work with? Layers which just are not handling the concern? Make sure to mark these layers to come back to.

Next go through the remaining concerns - trying to cover at least all of the high impact and high likelihood ones. Work with participants to propose layers which can resolve the concerns. As layers are accepted as proposals, move the matching concerns over.

If there’s time go back to the not working layers and see what can be addressed. Is it implementation problem? Is it the purpose has issues?

Follow Up

After the workshop has concluded the participants in the workshop should document the new quality strategy with the architecture diagram & layer purposes/concerns in a place where they can use them in their day to day. We want all that info so future conversations around changing the quality strategy can be easier (eg, if the architecture changes, we can use the diagram to trace what would be effected)

Accepted proposals for removing, adding, and changing layers should be planned and worked on, with team members themselves prioritizing what should come first. (eg, sometimes removing a layer will allow everything else to speed up and could go first to get that benefit quickly…but on the other hand, it might also be the lowest priority to deal with)

Any layers which need changing not addressed in the workshop should have a follow up to fix them - the follow up could be a task and does not have to be full on workshop style.