Agile in the Ether, IRL: 2025 edition

I’ve been part of the Agile in the Ether online meetup for years, and in 2024 we had a one-day, in real life event in Liverpool. It was so good we decided to do it again this year. Emily Webber has posted about how the overall event was planned and run – a good read! In this post, I’ll share some reflections and “further reading” notes from the 4 interactive sessions at the event.

Making sense of stuff with causal loop diagrams

Sophie Weston gave an introduction to causal loop diagrams, a tool from systems thinking, and let us have a go at drawing some in groups. I’ve seen these before but not tried them out – they’re surprisingly easy to get started with, and seem very useful for spotting non-obvious consequences of things you might be doing.

You could try making diagrams for all kinds of things. Drawing it doesn’t mean it’s “right”, but it is a useful starting point for discussion and investigation. “If it’s true that more of x leads to more of y, then look at this horrible reinforcing loop we didn’t realise was happening”. Once you have that, you can go and look into whether that x-y relationship is true.

This short practice made me want to learn more and try these diagrams out on real-world problems. Sophie shared some nice resources:

• Short introductions, with examples, from The Systems Thinker and The Open University.
• A talk from Hibri Marzook on why so many good ideas in software delivery are counterintuitive: video, slides.
• If you want whole books, try Thinking in Systems: A Primer by Donella Meadows or Learning Systems Thinking by Diana Montalion.

How do you *do* that?

I’ve worked with quite a few people whose skills I’d love to emulate – particularly people who instinctively pick the right way to approach tricky tasks. Things like how to design some new feature, write an email that defuses stakeholder tensions, or rapidly spot the exact cause of some live tech issue. I’ve been looking into a few promising-looking techniques for how to learn this kind of expertise, even when the experts in question struggle to explain how they do it, and I ran a session to let people hear about these and try them out.

A few years ago I found Cedric Chin’s Commoncog blog – an amazing range of posts documenting Cedric’s search to get better at learning. The tacit knowledge series in particular had excellent leads on how to get better at the kind of “can’t even explain how I do it” skills I’m looking for help with.

• In “Copying Better: How To Acquire The Tacit Knowledge of Experts” Cedric talks through Naturalistic Decision Making, a framework for studying these kinds of skill – that pointed me to Gary Klein’s “Sources of Power” book that’s full of stories of how this research started and how it’s helped understand this kind of expert decision-making.
• The “skill extraction” techniques described there require a lot of expertise themselves – not something easy to pick up and use. In “An Easier Method for Extracting Tacit Knowledge”, Cedric describes finding “Applied Cognitive Task Analysis” (ACTA) in a paper from Laura Militello and Robert Hutton – simpler interview prompts and task simulation ideas, designed to be easy for anyone to try out with a little practice. Perfect!
• Further blog posts describe how Cedric tried ACTA with John Cutler’s Product Org Expertise – helping both Cedric and John understand more about how that skill can be learned – and how a Commoncog reader used it to learn from experienced team members (”Tacit Expertise Extraction, Software Engineering Edition” with Stephen Zefras).

Minimum Viable BSL

Simon Manby has been learning British Sign Language for a few years – he took it up because he wanted to learn something new, and not directly work-related. He gave us a very quick intro to some basic phrases, and spelling out words like our names, in a completely silent lesson with group work.

Learning a tiny bit about BSL was great: how the word order can be different than English, how you get your face and body involved in getting meaning across, and how some signs are different in various parts of the UK (just like dialects in spoken English). I also found the style of learning really interesting: when you don’t yet know enough to ask for help or properly follow what people are trying to get across, it brings home how daunting learning a brand new skill can be.

There’s lots of ways to learn some BSL if you’d like to give it a try – either in-person classes like Simon’s been going to, or from lots of online options. I haven’t looked into enough to be sure what to recommend, but I like the look of these:

• Manchester Metropolitan University has a free online self-study course, after which you can go to in-person sessions on their campus.
• “Commanding Hands” site has lots of videos, guides, and a BSL fingerspelling font!
• Other recommendations appreciated, I can add notes here if there’s something nice I’ve missed.

That BSL font is a fun idea… I downloaded the file, double-clicked to install it on my Mac’s FontBook, and now it appears in the list of fonts for Keynote and a few other apps.

The Multidisciplinary Team Building Game

Emily Webber ran an interactive game to simulate a real-world task: who do we need on a team? I’ve definitely had trouble in the past where people have confused capabilities with job titles – small pieces of work can seem to need huge teams (”Does it have a front end? Need a front end engineer. Does it have users? User researcher. Does it need delivered? …”)

This game challenged us to put teams together for different scenarios, covering all the capabilities needed with a set, small number of people. Smaller teams have all kinds of advantages – less communication overhead, better understanding of the whole picture, cheaper to run – so finding ways to make them work is a valuable skill.

Some good features of this exercise:

• It set constraints, and asked you to note how you dealt with them – for example, “people can be responsible for a maximum of two capabilities”. It’s too easy to say “x can do a bit of this, and has covered that, and”… it’s unfair to overload people, this practice keeps you honest.
• Noting compromises and how you’ll manage them is useful too; if someone’s interested in learning client management, and you say they’ll cover that with some advice and mentoring from an expert outside the team, it’s important to keep a record of that and remember not to load up that expert with other tasks. I’ve seen intentions like this get easily forgotten.
• “There must be at least two learning opportunities” – all potential team members had capabilities they hoped to learn, and finding team combinations that enabled that was an explicit part of this exercise. On-the-job learning is valuable for individuals and for the organisation as a whole, but it’s often left to chance. We had good discussions about how to think more about that in real team design activities.

Emily’s game is available on the Miroverse if you’d like to try it out.

Until next time

We’ll definitely run this IRL event again – in the meantime, the Agile in the Ether community has online things throughout the year, you can sign up to hear about the next meetup.