Hope you're all doing well out there, that you're keeping warm if you're here in NZ, or you're keeping cool if you're in one of the heatwavey parts of the world right now!
The term "Systems Thinking" has come up in conversation a couple of times this week, and so I thought it would be an interesting topic to dive into a little bit. Read on, I hope it's interesting!
⚽ Systems Thinking and the 1994 Caribbean cup.
One of my beliefs about testing is that to be a good tester, you need to embrace Systems Thinking.
But, Systems Thinking is kind of a buzz word, and I find it hard to explain. It's also a really broad subject.
I'm going to use a sports analogy - and I sports analogies aren't always popular - but I think this is a good one, so bear with me.
The Caribbean cup is a football tournament (the soccer kind).
When the tournament was held back in 1994, the Barbados team were in a bit of a situation. If they wanted to progress in the tournament, they needed to win their next game against Grenada by two goals or more. A margin of one wouldn't cut it, due to the results of their other games.
To make it more interesting, the Caribbean cup tournament had some unusual rules:
- Firstly, they played golden goal - if the score at the end of the game is a draw, they keep playing until a goal is scored, so that a winner of the game can be declared.
- Not only that, but any goal scored in extra time (i.e. a 'golden goal') would be worth two goals.
In the 83rd minute, the scoreline was 2-1 to Barbados. Barbados were ahead, but only by one goal. If the game ended with this score, Barbados would be out of the tournament, despite being the winner.
The Barbadian team realised at this point, they had two options. They could try and score another goal, which was proving difficult. Or, they could go for a draw. A draw would let the game go to extra time, and they could then hopefully score a 'two point' winning goal. That would get them through.
So they did exactly that - in one of the stranger moments in football history, Barbados scored a goal against themselves to bring the scoreline to 2-2.
Realising what had happened, Grenada then found themselves bizarrely trying to score a goal at either end of the field. A win or a loss by one point would let them progress, but a draw would put them at risk.
Unfortunately for them, Barbados succeeded in defending both ends, and the game ended 2-2.
Barbados went on to score in extra time, making them the winners, 4-2, and progressed to the finals.
What I get from the story is this: there must have been some systems thinkers on the field that day.
At a surface level, either teams objective would be to "score more goals than the other team". That's traditionally how you win.
As systems thinkers, they were thinking deeper than this. Winning the game is not the objective, they want to win the tournament. It took some thinking about the wider system, to acknowledge they needed to win by two goals. I would say it took even deeper thinking to realise that scoring against themselves was the best strategy.
I guess what I'm saying is this - to me, Systems Thinking is going beyond the task at hand, and thinking about the bigger picture. How does the work we're doing fit in to organisational goals, and the context of what else is happening? What alternative strategies might be uncovered by thinking this way?
It's an important skill in us testers. Not just testing the work in front of us, but continually thinking about how it applies in a wider context, what other parts of the system it affects, and what else is happening in parallel.
Systems Thinking makes great testers - it can be hard, especially when stuck in the details - but I'd encourage pursuing becoming more of a Systems Thinker. I would recommend Gerry Weinbergs book as a starting point!
🖥 Neat stuff from around the internet
- Honeycomb are offering their O'Reilly book on Observability Engineering for free. Why wouldn't you?
- I wrote a thing for TestProject on why speed is an important consideration in automation.
- If you've ever been on a video call with me, you've probably heard me rage against my bluetooth devices. Ben Kuhn feels my pain - wireless is a trap. (thanks Nick for the link!)
- It's 1997, and you want to build a website. A trip down memory lane, just for those of us who remember the 90's.
- This one's kinda interesting - the argument that self-driving cars would be safer if the "AI" chose when to delegate responsibility to humans (rather than the other way around). I'm not sure it's right - but - it is thought provoking.
- I'll be honest, I don't know what this is. It seems like part meme, part development advice. The Grug Brained Developer. It's weird but I like it. (thanks Jay for the link!)
- Mary and Tom Poppendieck on how approaches to quality have changed in the last 20 years.
- Maaike Brinkhof gives a wonderful rant on some of her frustrations with testing, and organisational bugs.
- In our latest Tech Engineering Lounge video, Camy and I chat to Prae Songprasit about UX Engineering.
- Absurd Trolley Problems - if you're familiar with the classic trolley problem, this is like that - but - absurder.
🎟️ Events coming up
Panel discussion: Skill Assessments (Auckland, 28 July)
Next Thursday, I'll be on a panel discussing skill assessments for testing roles. What sort of things to look for, and what I look for as a hiring manager. Come along and be part of the conversation!
Marty Cagan| Empowered: Ordinary People, Extraordinary Products (Online, 9 August)
Leading the Product are hosting Marty Cagan, to talk about how to build an engineering culture that can empower and inspire.
Ideation: Alternatives to brainstorming (Online, 9 August)
Agile Auckland are hosting Aaron Power and Rhiannon Bond from RedVespa to talk through their ideation and creative process.
Lauren Woolf - WAGMI (We're all gonna make it) - aren't we? (Auckland, 10 August)
Tech for Good are hosting Lauren Woolf to talk crypto, NFTs, web3, and why humanity and creativity are at the heart of it all.