You go to a 3-day conference, which in reality means you are on a rollercoaster of keynotes, breakout talks, workshops and networking (oh and coffee and food). You get on the train back home and you wonder:

What just happened?

Here’s a summary of what I felt. And what I learnt. Oh, and what new plans I have.

🫶 What I felt

Throughout the conference, I felt welcomed, relaxed, calm. Everyone was willing to speak to everyone and did the simple things to make everyone inclusive. These are ideal conditions to learn together and fill up with new ideas.

The conference was hosted at a central hotel in Bath - a city you must visit if you haven’t, it’s beautiful and calm. As a speaker at the conference, I had the benefit of staying in the hotel with beautiful rooms and a pool, sauna, steam room, gym etc. Quite a luxury, but one I shamelessly took full advantage of.

🎓 What I learnt

You can often feel completely overwhelemed or underwhelmed at multi-day conference. At Agile in the City I was the perfect amount of “whelmed”.

There are a few things I learnt that I want to explore more. While reflecting on the train back to Leeds, and because you asked for it Andy, I noticed 3 themes at the conference:

• Organisational & business sense making
• Learning & growing capabilities
• Collaborative working

I also noticed a few things that were glaringly missing from the conference.

• Communities of Practice
• Value Streams & Org Design -> Optimising for Flow & Cognitive Load
• Food without onion

Collaborative working

Due to the nature of the conference (agile ways of working), there were plenty of talks that suggested ways of making multi-team software delivery more effective.

Estimates & Complexity

Gary Fleming’s quest to finish his talk in 42.5 mins because he promised it at the start, just to prove that you really shouldn’t estimate. But if you really do need to estimate, use t-shirt sizing and probabilistic forecasting (averages and distributions over exact numbers).

How working effectively with finance can accelerate your journey to business agility

We all know (and have felt) that more often than not, Finance and Tech don’t look eye to eye. Tech “moves fast and breaks things”, Finance “counts beans”. How can we bridge the gap? Statements like “Value delivery over story completion” and “a CFO can kill a piece of work faster than a CTO can” have stuck in my head, along with Stuart Munton’s advice on how to improve the working relationship between Tech and Finance. If you want to broaden your agility from the team level to the company level - THE BUSINESS - you might want to consider tackling the challenges that Stuart themed as: involvement, forecasting, value, funding and ownership.

I’ve experienced first-hand how funding mechanisms and approaches can make or break everything in a company. Some of Stuart’s suggestions are “organise Finance away from cost centre lines to profit centre lines” and persuade your CFO to consider Throughput Accounting over Cost Accounting.

Making the case for product design

Designing our products to please our users and customers is vital for a business. Yet, product design is something that often needs to be argued for to properly embed in a product engineering centric company. Everyone loves a maturity model when they want to gauge if they have made any progress and figure out what the next steps are:

1. Product Design - fill in the gaps from the basics you are doing now
2. Integrated - peer collaboration (sit the UXer next to or the team)
3. Empowered - having a decision making framework and leading with context is the difference between feature teams and product teams
4. Strategic - set the company direction, introduce things like a Design System

I’ll be using this for sure!

How to navigate through turbulence in the aviation industry

You may be doing “all the agile stuff” but actually not delivering with momentum and predictably. The agile ceremonies and practices are not the problem in themselves. The issue is that most teams are told what to do and they follow the process. Give teams agency and autonomy to decide their ways of working and you may end up with the same processes but now they have agency. The teams have decided to work this way, understand why, are happier and more effective.

Organisational & business sense making

There is a clear acceptance that businesses are socio-technical systems, the problem spaces are often complex and simplifying, iterating and building a shared understanding are our friends.

Event Storming by example

This was my favourite talk of the conference. Event Storming is a workshop that brings together all the domain experts in a business - including the software engineers - to find aha moments from common language. Willem gave an excellent primer of Event Storming:

• rationale (flesh out intricate details together, and work towards a working system)
• purpose (a workshop to co-create an understanding of significant events in a process)
• a walk through of an example on Miro

We also got a bonus ad-hoc presentation of the concept “aggregates” - a cluster of associated objects that we treat as a unit for the purpose of data changes or simply “a unit of behaviour, which really is a unit of change”. Willem demonstrated with his talk that although some of the Domain Driven Design concepts may seem dry and complex - they are simpler than you think. I really liked the practical examples of heuristics you can use to find or evaluate aggregates.

As a side note, I was impressed by the clarity of content, Willem’s relaxed and engaging approach to speaking, allowing a safe space for questions and conversation throughout the talk.

Experimentology - test & learn like a boss

“Everything does what they want” is not agile and “give them a boundary of freedom, define the interface between people and teams” set the tone for this experiemntal approach to organisational change by Gez Smith and Jonathan Churchward. The premise is to take iterative, small steps to organistaional change - avoiding big bang changes that lead to “transoformation debt”. The workshop walked led each table through creating a small experiment to change via a template provided.

Gez and Jonathan have created a website were experiments can be submitted so that we can start building a public knowledge base of organisational change experiments, so that we learn from each other and from the past. Each organisation is different but as the popularity of Team Topologies has proven, there are definitely things that are common and shared across organisations.

Stop being dependent on dependencies

More often than not, teams and the domains or systems they own are not well aligned, which leads to unwanted dependencies. John Roberts from Kin+Carta gave us a deep dive on the types of dependencies that exist based on their nature & source:

• time
• location
• resource
• other

Why are dependencies bad? Ultimately, they lead to low agility. Or if we use our fast flow lenses (Team Topologies 👀), permanent dependencies are the enemy of flow. And so, John walked us through some case studies and some ideas of what you can do when you find yourself at a place with low agility and many dependencies between teams.

Hint: start by counting them.

I really do hope that we start talking more in terms of alignment to value streams and figuring out team boundaries when it comes to understanding why our teams are “not so agile”. It’s not easy, but it is necessary.

Learning & growing capabilities

I have spent enough years now working in software-centric businesses that I can clearly see the value of learning in any company. Learning is a core capability that makes or breaks a company. There were plenty of talks that explored this theme at the confrence.

How teams remember

https://bristol.agileinthecity.net/programme/how-teams-remember

Giles Turnbull - The Agile Comms author (yes, read it!) - talked about how various organisations remember their history. Often we get so caught up in doing the work in front of us that we miss important knowledge about how the organisation got to where it is now.

Key takeaway: start weeknotes, be creative. Someone (maybe Giles?) will turn it into a history record one day.

Embrace the power of product thinking

This keynote by Alia Shafir, was less about Product Thinking itself but more about how you grow the capability of Product Thinking in a gigantic organisation like Bloomberg. However, we got a sneak peak in Bloomberg’s principles for good Product Managenet in the 4 Cs (Clarity, Competency, Collaboration and Consistency).

The appraoch to growth was to build a bootcamp program to train new Product Managers. Alia’s story was a story of reminders to take a lean approach, shorten feedback loops and prioritise ruthlessly.

I’d be interested to see whether peer to peer learning structures like Communities of Practice might help in these scenarios, especially in such an emerging and confusing discipline like Product Management.

Stop trying to learn like a robot & start learning like a human being

A lovely workshop by X and Y exploring the practics and techniques you can use to learn together, collaboratively.

Key learning point: learning and thinking together almost always leads to better and more diverse learning.

The Shape of Thoughts

Gemma Honour taught us how to draw, and gave us some great tips on how to help teams think together effetively through:

1. clearing the mental clutter: categorise things, de-duplicate and theme, use venn diagrams, prioritise.
2. creatign a great culture via stories
3. imrpove your problem solving via metaphors (hero and victim being an example for the case of call centres)

I am intrigued now to learn the basics of drawing so that I can quickly visualise something for myself or a group to undertand.

🫶 What I plan to do

I met so many interesting and fascinating people. I am convinced that practicing event storming sessions regularly is a good idea, and I hope to do it more often in my new role. I’m also fascinated by an idea presented by Anne Deir: the value of thinking about “how you might kill a service”, at design phase. Currently, most companies don’t think about this at all, leading to all sorts of problems: waste, security vulnerability, unwanted costs, increased cognitive load on teams etc. Not sure how, but would love to explore this more.

You should try one

That’s all, I hope this was not too long to read. If you get the chance do attend one of these Agile Conferences. I always leave energised, inspired and with new ideas.