Lean Agile Scotland 2025: Lessons for Quality Engineers
Last week I was in Edinburgh for Lean Agile Scotland. It was my second time speaking there, but one of the best parts of any conference is getting to sit in the audience and learn from others. Over two days, I went to talks and workshops that covered everything from complexity modelling to feedback to resilience engineering.
As I listened, I couldn’t help but notice how much of it connected back to quality engineering and my own talk on the Uncertainty of Change. It almost felt like the programme had been designed to weave these themes together. Here are some of my highlights, and how they tie into the way we think about quality in complex systems.
Day 1 - From small teams to complex systems
The day kicked off with Sander Hoogendoorn, CTO of iBood.com, talking on the Seven habits of a (mostly) successful team. What I loved here was the simplicity: strip away the heavy frameworks, give people autonomy, and put purpose front and centre. Small teams clustered around problems, communicating constantly through lean coffees, mob programming, and event storming.
What stood out to me was the emphasis on purpose, which mirrors something we often miss in engineering and quality work. Too often, we talk about tools, frameworks, or processes. But the real anchor is making sure everyone knows why we’re doing what we’re doing, and what outcome we’re aiming for.
The next session I jumped into was by Suzanne Morrison and Vinnie Gill from Outcome over Output, which went deeper into complexity with a workshop on using Current Reality Trees. Instead of narrowing in on a single “root cause,” the method maps out undesirable effects in the system and traces how they’re interlinked. What I took away was the importance of modelling problems in a way that respects complexity, rather than reducing it too quickly. For quality engineers, it gives us another way to make sense of messy problem spaces and decide which levers we can actually pull
Suzzanne and Vinnie offer a Udemy course, and it is available at half price until Monday, September 29th, at 10:00 AM.
Right after lunch, I was up with Navigating uncertainty in complex software systems. If you’re looking for a write-up, then check out Uncertainty of Change, which has fully annotated slides of my talk.
Later, I joined a workshop on feedback by Tutu Ariyo, which introduced two practical tools I hadn’t seen before:
FADEAWAY – to help us manage our own fight/flight/freeze/fawn responses when receiving feedback. (See image)
COILED – for giving and receiving feedback and what each persons role is.
Both are useful not only for one-to-ones but also for navigating the stress responses that naturally show up in everyday engineering work.
Day one closed with Ade-Lee’s energetic talk about changing agile teams. The big lesson: agile itself often isn’t broken, we just get stuck on parts of it. Switching frameworks won’t fix the underlying issues. This is something I’ve seen so many times in the quality space, if you don’t understand the second-order effects, you’ll keep fighting the same fires in different disguises.
If you enjoyed this reflection, you may also like my weekly newsletter, where I share additional thoughts on quality engineering, resilience, and the human side of software development. You can subscribe here:
Day 2 - Communication, resilience, and human responses
Jenny Martin’s keynote on Nonviolent Communication was one of my favourites. I’ve admired NVC for years but struggled to use it consistently. Jenny broke it down beautifully, especially the distinction between sharing genuine feelings versus smuggling in disguised thoughts. That shift can completely change how feedback lands.
She also shared the “empathy staircase,” which showed the difference between sympathy and empathy, and why perspective-taking is such a powerful but difficult skill. For me, this connects directly to quality work: when teams feel safe to share openly, we uncover risks earlier and respond to them better.
From there, I went into the first of two workshops, Expecting the unexpected: how to become resilient, by Charles Weir from Lancaster University, which felt like a masterclass in connecting quality and resilience. The research shared showed that the biggest risks weren’t technical failures but poor responses to failure. That flips the usual mindset on its head. Instead of just asking, “How do we stop things breaking?” we should be asking, “How do we detect, respond, and recover when they inevitably do?”
Two ideas I loved:
Using real incident stories as teaching tools. Rather than listing “if X then Y” playbooks, ask: “If this had happened to us, how would we respond?” It makes learning stick.
Designing for resilience as a quality attribute. Just like performance or security, resilience should be something we test, measure, and build for.
The last workshop I attended was Don’t panic: ambiguity tolerance and the case for rewilding work by John Le Drew and Kylie Yearsley. They introduced me to the Somatic Marker Hypothesis, which describes automatic bodily responses that trigger fight, flight, or freeze.
At first, I wasn’t sure how to apply it, but the more I reflected, the more it clicked. In stressful moments, whether in production incidents or tough conversations, our default responses are incredibly fast. The real skill is noticing them quickly enough to create a pause, and choosing how to respond, which connected back to this quote from the opening keynote from Jenny on NVC:
Out beyond ideas of wrongdoing and right doing their is a field . I’ll meet you there - Rumi
So what does all this mean for quality engineering?
Across both days, I kept circling back to a few key points:
We work in complex systems - and need tools like Cynefin and Current Reality Trees to help us make sense of them.
Uncertainty triggers stress responses - whether it’s feedback, communication, or incidents. Learning to notice and manage those responses is vital.
Resilience is quality - it’s not just about preventing failure, but preparing to adapt when failure happens.
Stories and models matter - telling real stories of failure and mapping problem spaces gives teams practical ways to learn and improve.
These lessons aren’t just theoretical. They’re tools we can use tomorrow: run an event storming session to align on purpose, try NVC or COILED in your next feedback moment, or bring a real-world incident story into your next team retro.
Why conferences like this matter
If you’ve ever looked at a Lean Agile conference programme and thought, “That doesn’t sound like it’s for me,” I’d encourage you to go anyway. My own talk was on Navigating uncertainty in complex software systems, but I learned just as much from sessions on resilience, communication, and human behaviour.
Conferences like Lean Agile Scotland (and its sister events in Manchester, Bristol, Cambridge, and Brighton) are fantastic places to feed your curiosity, pick up practical tools, and see your own work through a new lens.
For me, that’s the heart of quality engineering: connecting ideas across disciplines, and using them to help teams build better, more resilient systems.
I’d love to hear from you. Which of these ideas connects most with your own experiences? Reply and let me know.