Joep Schuurkes (Posts about peer conferences)

Structuring group discussions with K-cards

Joep Schuurkes — Fri, 25 Mar 2022 17:27:30 GMT

K-cards are often used at peer conferences to facilitate the discussion after someone has presented their experience report. Some people really hate them. In my experience they're a great tool to enable rich conversations. Since the facilitator uses the K-cards to structure the discussion in threads, K-cards allow the group to drill down to the details of the experience report. This instead of the conversation jumping around as person 1 broaches topic A, person 2 introduces topic B, and person 3 wants to return to topic A.

The explanation of these K-cards often takes the form of "This is what each card means." instead of "This is when to use this card for what purpose." And despite the elegance of the K-cards system, when you learn about them during the opening of a peer conference, it's a lot of information to digest. So I hope this blog post will be useful as a written explanation of how to use K-cards.

Thinking about quality: so what to do?

Joep Schuurkes — Wed, 07 Apr 2021 11:25:02 GMT

On 30 January 2021 I participated in the Quality Acceleration Peer Conference organized by Huib Schoots and Joost Voskuil. Participants were Alan Page, Areti Panou, Ash Winter, Bart Knaack, Conor Fitzgerald, Rouke de Jong, Gwen Diagram, George Dinwiddie, Janet Gregory, Joost Voskuil, Joost van Wollingen, Martijn Meijering, Rob Meaney, Vincent Wijnen - with Huib Schoots facilitating the peer conference. The main topics mentioned in the invite were: "How can you sell quality?", "How can you convince people that quality can accelerate software delivery?", and "What limitations or barriers do you hit?"

Reflecting during and after our discussions on these topics, I realized there are some interesting things going on about how we talk about quality and how to sell it. Enough interesting things to fill more than one blog post, so this will be a four-part series. And I might expand on some ideas in the series after that.

The first three parts covered rather philosophical topics: choosing your value system, exploring what it means to sell quality, and how management paradigms affect quality. At the end of the third post I brought up the main question for this fourth and last post: so now what? If you expect me to get very concrete and specific in this post, I'm afraid I have to disappoint you. What I will do, is share a way to think about actions that has been helpful to me.

Quality is something emergent

Anne-Marie Charrett says in a blog post titled "Emergent Quality":

"My hypothesis is that quality is an emergent behaviour. It relies on a whole set of independent systems coming together to create this emergent property. We can never truly know what quality is. It’s constantly changing and morphing into different things. For sure, we can provide examples, but know quality itself? I’m not convinced."

Thinking about quality: management paradigms and quality

Joep Schuurkes — Mon, 15 Mar 2021 08:32:08 GMT

This is the third part, exploring five different management paradigms as identified by Carol Sanford in her book "The Regenerative Business" and how they affect quality. The first part was about choosing your value system can be found here. The second part about selling quality can be found here.

Psychological cover and psychological safety

If the challenge of quality is getting several things right (perception, desire, and means) and getting to an agreement among people, how we organize ourselves becomes a crucial topic. As W. Edwards Deming said: "A bad system will beat a good person every time." Or as Kurt Lewin said in a more neutral way: "Behavior is a function of the Person and the Environment." An important part of any environment is psychological safety. In episode 155 of their Troubleshooting Agile podcast Jeffrey Fredrick and Douglas Squirrel make an interesting distinction between psychological cover and psychological safety.

Thinking about quality: who doesn't want quality?

Joep Schuurkes — Thu, 25 Feb 2021 11:34:08 GMT

This is the second part. The first one about choosing your value system can be found here.

Everyone wants quality, right?

In the previous post I distinguished two definitions of quality. If we proceed with the second and more interesting one, value to a person who matters, I would argue that everyone wants quality and is already doing their best to get it. The alternative would be that some people are not doing their best to get the things they value - which seems absurd to me.

Thinking about quality: choosing your value system

Joep Schuurkes — Mon, 15 Feb 2021 19:09:08 GMT

Quality has two different meanings

On the one hand, we use quality when we talk about things that are obviously better. A $3500 coffee grinder is obviously better than a £50 one. An application that does not crash on you is obviously better than one that does. Almost all other ways to input your phone number are better than these.

Two styles of leadership in spreading context-driven testing (TITANconf)

Joep Schuurkes — Sun, 06 Sep 2015 17:56:54 GMT

The last weekend of August I spent with some great people - Kristoffer Ankarberg (@KrisAnkarberg), Kristoffer Nordström (@kristoffer_nord), Anna Brunell (@Anna_Brunell), Fredrik Thuresson (@Thure98), Maria Kedemo (@mariakedemo), Henrik Andersson (@henkeandersson), Maria Månsson, Amy Philips (@ItJustBroke), Richard Bradshaw (@FriendlyTester), Duncan Nisbet (@DuncNisbet), Alexandru Rotaru (@altomalex), Oana Casapu, Simon Schrijver (@SimonSaysNoMore), Zeger Van Hese (@TestSideStory), Helena Jeret-Mäe (@HelenaJ_M), Aleksis Tulonen (@al3ksis), Anders Dinsen (@andersdinsen) - at the awesome TITAN peer conference in Karlskrona, Sweden.

During the conference we discussed leadership and testing and on Sunday morning I got the opportunity to tell my story¹. (I do wish I had captured more of the discussion afterwards to include in this blog post.)

The first style

When thinking about my own leadership in testing, one of the first things that come to mind are my attempts to influence my colleagues at work (testers, developers, project managers) to become more context-driven in their attitude towards testing.

DEWT3 experience report

Joep Schuurkes — Sun, 28 Apr 2013 13:32:02 GMT

Last weekend the third Dutch Exploratory Workshop in Testing (DEWT3 for short) took place. The ingredients were: a very nice hotel in the woods, lots of talk about testing, beer, whiskey, a small to moderate amount of sleep, stickies and a group of fun and interesting people (You can see them here.)

On Saturday the talks (and thus discussions) were about systems thinking. A few years ago I did read Jerry Weinberg's "An Introduction to General Systems Thinking" and although a very interesting read, w.r.t. to applying it to testing I never got further then: Software is (part of) a system, so you can apply systems thinking to it. Of course, that's very much true, but it's also quite a vague piece of advice.

A primer on systems thinking

Enter James Bach, who kicked off DEWT3 with a primer on systems thinking. Systems thinking is just a way of thinking - just like logical thinking, analogical thinking, creative thinking, etc. - in which we approach a situation as being a system. So what's a system? It's a set of things in a meaningful interaction with each other. This definition raises all sorts of questions relevant in systems thinking:

DEWT2 - Becoming a context-driven tester

Joep Schuurkes — Thu, 08 Nov 2012 22:14:57 GMT

About a month ago ago (October 5th - 6th) I was in Driebergen to attend DEWT2, a peer workshop with as theme "Implementing Context-Driven Testing". As it turns out, implementing context-driven testing is not easy to do. That should not come as a surprise: it requires people to change and that is difficult. Luckily, I'm not a manager wanting to implement context-driven testing, so I can dodge most of that problem.

However, I do like 'spreading the word' on context-driven testing, because I would like for there to be more context-driven testers in the Netherlands (and Europe and the world, of course). So to promote context-driven testing I think there are three things I can do:
1) set an example,
2) be available to other people,
3) leave bread crumbs.