Notes from Agile Cambridge 2024

I spent 3 days at Agile Cambridge conference in October 2024. Great range of sessions and attendees to spend time with, all based at Cambridge university – an ideal location to put you in a learning mood. I’ve had a few weeks to think it over, and now I’m ready to write this “What would I like to remember” post of notes.

Workshops

I’m always interested in learning more about facilitation, I think well-run meetings and workshops are a superpower. The opening keynote from Alison Coward, “A guide to building teams that thrive”, had a great collection of ideas about taking the best elements of workshops and making them part of your day-to-day work and team improvement. Alison started with a suggested definition of “thriving” at work: a high level of well-being, and a high level of performance. She had a few thoughts about what would could look like:

• What if work didn’t drain us? What if it topped up energy, so when you came out of work you could put lots into family, community, hobbies, other places?
• What if work was a place we went to practice relationship skills? Learned dealing with disagreement, diversity, and more?
• What if organisations took responsibility for making workplaces like this?

Alison talked about a pattern she noticed: Workshops or away days often had amazing work, breakthrough understandings, collaboration happening … and then back to the day job, where all that energy just trickled away. A great workshop and then absolutely nothing changed.

She’s found success in helping teams to see teambuilding not as a separate, occasional activity – it can be part of every day’s work. Lots of teams and orgs are “working by default”: they don’t realise they have agency over how they work together. Alison talked through frameworks and steps to start moving in that direction, and gave everyone a copy of her Workshop Culture book that follows these up in more detail.

Right after that, I attended Emily Webber’s workshop on “Building team connections and empathy, quickly”. I was at an earlier version of this at an Agile in the Ether, IRL event in February – I was interested to see how much the content’s evolved, and how much difference this being a longer session made (90 min instead of 45). Like last time, we got to try out a team manual and the capability comb – but with more time for Emily to introduce and explore how they work, and more discussion in the room about how they could be useful.

We also got to hear about “transactive memory systems” – like an index for keeping track of your team’s collective knowledge. Knowing who to ask, knowing what topics your team collectively has covered, is valuable. An organisation that has good transactive memory systems has a competitive advantage: Able to move quickly, understand its own capabilities. Emily’s written about the role of transactive memory systems in great teams, and linked to a research paper about them.

I attended one more workshop at the conference: Sorrel Harriet and Clem Pickering’s “Rescue higher education from grave peril while cutting some groovy team topologies shapes”. Some things I liked about this one:

• It started with indicative learning aims – a clear summary of what we’d hope to get out of this. There was a combination of learning how to apply team interaction and flow based modelling, along with reflecting on how scenario-based learning and storytelling could be used as a catalyst for change.
• The scenario (fictional, but drawn from a range of real issues) was fantastic. Sorrel said: “I want you to understand how this feels for the people in this story, I want you to have some empathy for them”. She did a great job, bringing the little emoji characters to life in their frustrating situations. I think both in fictional case studies and real-life applications of this kind of thing, we don’t often start with this much understanding how things feel for the people involved.
• This scenario had enough depth and realism to be useful – that’s often missing with this kind of “here’s an example to practice on”. And, I can imagine how practicing a new technique on a fictional scenario first will feel safer, more contained, and more objective than starting with “our own mess”.

Research, and rethinking things

Lots of talks made me think again about topics I thought I knew a bit about already.

Matt Philip has been researching psychological safety and remote work. Looking at lots of factors, he’s concluded that the best approach is small team sizes (single digits), well-defined teams that do most of their work together (as opposed to being matrixed across multiple teams), and some in-person interactions (doesn’t need to be much). Some other advice:

• Help people start well, with strong onboarding: talk openly about why you asked someone to join the team and why you’re excited to work with them, and explore as a team what things you’d all like to get better at.
• Explore points of difference: When it’s becoming clear that people have very different opinions about a topic (estimation, “best practices”, anything else), find a space to explore that. Matt’s scheduled “let’s talk about…” sessions to help understand each other.
• Work aloud: Let your colleagues know what you’re doing, what you find interesting, what they might get involved in.

There’s lots more about this topic on Matt’s website.

Adam Tornhill has been working on code health metrics, and a product that can analyse them, for 25 years. He says it’s notoriously hard to define what “bad code” is, objectively – and to quantify how much of a team and business impact it has. He demoed his tool that can be run on codebases and visualise it. His research across many companies has found that “red” rated code here is much more likely to be the source of bugs whenever we change it, and almost impossible to predict how long changes will take, compared to code that ranks as more healthy.

”If this was my team’s codebase, as a product manager or engineer this would be really valuable information. You can see where it’s important to put your improvement efforts.”

He shared a white paper, a research publication, with lots more links available on the CodeScene site.

One more chance to rethink things: Elizabeth Ayer talked about how transparency (held up as a dear value and obvious good by lots of people) is actually quite problematic. She toured through lots of examples of how transparency’s brought good outcomes, and where it’s caused problems – used as a tool to consolidate power, had asymmetries in who gets to “see” things, and how it’s been used to abdicate responsibility for hard work (”the information is all there, we don’t need to do any more!”).

In every case where good outcomes came from making things transparent, one thing stood out: it takes so much work. Checking in with people, explaining the meaning behind what’s being shared, framing things clearly and usefully for different audiences – it takes time, skill and effort.

Looking at how to get the most out of it, for software teams in particular:

• Inside teams, and between peer teams, transparency’s pretty much a solved problem. It can be tricky to get right but we have tools that work fine (Team Topologies is one example).
• Where we struggle is crossing “zoom levels”: up and down levels of the org, across disciplines, and “anywhere we have to communicate across worldviews”.
• You can help by sharing relevant info with other groups, with a story to make it relatable and stick in people’s heads.
• Value of mapping workshops: it’s not in the map. The value is in getting access to how people are thinking about the world, and seeing how different that might be from your understanding.
• Reflection on your own beliefs, understanding, worldview, is all very important to let you understand where other people are coming from.
• It really does take a lot of work.
• And finally: Please don’t use LLMs for this.

Other things

There were lots of other great sessions and conversations across the 3 days – here’s a few more examples.

Emily Webber and Cara Bermingham hosted Agile on the Bench, “the world’s premiere outdoor lo-fi meetup”, which started 10 years ago this month.

• Cara talked about “the joy of awkwardness”: Early in her career she felt awkward lots: often the only woman in the room, didn’t feel able to speak up about things she wanted to change. Looking back she wishes she’d pushed through that sooner. It’s OK to embrace awkwardness – showing people how you’re feeling is a form of vulnerability, it helps others share things too. Cara blogged about her talk afterwards.
• Neil Younger talked about learning to ride a unicycle, and how it relates to learning in general – for example, giving people shortcuts to get going can come at a cost – they don’t learn things that will help them later. In unicycling, starting off with a block to stop it rolling away backwards when you first get on means you can get to balancing sooner, but you’ve missed out on the foundational “what do I do when it starts rolling backwards” skill that’ll catch you out later. Are you aware of what trade-offs you’re making?

Dan Abel talked about the struggles he’s had when helping engineers grow in their careers – yearly evaluations and progression frameworks didn’t feel like they were helping him, so he’s worked on a different way to approach things. He’s identified several stages, and the different support people need at each one:

• Beginners need to build foundations in a safe place where they can learn by doing: “Don’t put them on a team that’s got critical work, urgent deadlines, and no time/energy to mentor and develop new people. Find a team that’s the opposite of that.”
• Competent engineers need to build a broad wall of skills – help them understand the range of things that are important, and enjoy getting the most out of learning and doing satisfying work.
• For fluent engineers it’s less about building that range of skills – now the focus should be on putting them to use on hard problems. How do you really make things work? Those strong foundations and broad solid wall of skills are needed to build impressive things. You need to know how lots of things really work, in lots of detail.

Dan shared a doc of takeaways.

All for now

There’s still more talks that I enjoyed, but this post is already long enough for a summary – thank you to all the other speakers, and the organisers!