12 things I learnt from Agile Manchester 2023

,
Close up of mic

Reading time: 5 minutes 

Below are my key highlight and insights from 3 days of Agile Manchester 2023. You can skim-read it to things that catch your eye or deep dive by following the links to my notes taken during the talks. Please note: expect lots of typos and mistakes in my notes. If you have any questions, then let me know. 

Still too long, didn’t read:

Day 1

Mathew Skeltons talk On CD at scale made me realise that agile, scrum, continuous delivery, DevOps, quality engineering etc., are all trying to achieve the same outcomes – smoothing the flow of work while simultaneously improving speed and quality in a sustainable way for engineering teams to deliver regularly, repeatedly and consistently. With each, in some instances building on top of whatever came before. But after some time of trying to work those methodologies and failing, those terms become trigger words, so we have to find another way to talk about it and get people on board. 

So it doesn’t matter what you call your approach. As long as you have a common understanding, then you’ll make progress. 

Emily Webbers, Why can we just get along? It showed me that multi-disciplinary teams are critical to successful teams, and you can use the capability comb to help people connect. Another insight I had was that how we collaborate in teams varies a lot, so having a better definition of what collaboration means might help people do more of the effective type. 

Lianne Mellor and Nikola Goger’s BFFs & rocket ships talk showed me how valuable a strong metaphor can be to hang your idea off. They used rocket ships, allowing people to bring in their ideas of space exploration. This creates a shared understanding and minimises the interpersonal risk people need to take when asking what something means. Documenting the terminology is also valuable so people have a backup when clarifying their thinking. This only lasts for a while but can be enough to get an approach started and people to buy in. 

Racheal Shah’s talk, Delivering delivery metrics, showed me how valuable building credibility is before heading into metrics conversations with teams. She did this by first getting to know as many people 1 to 1 as she could, having open forums for people to chat with her and sharing documents of her thinking and background. This way, the people that want to engage know where you’re coming from and the value of what you’re trying to do. They will eventually help spread that message if they buy into your approach and ideas. 

Charity Major’s talk, is it time to fulfil the promise of continuous deployment taught me two things. The first is that software is not like a wine that ages better with time but is more like milk that gets worse, so we should ship it as soon as possible before it spoils. The other was having the engineering team truly practising continuous deployment is an excellent tool for retaining and recruiting people. Everyone wants to work on delivering meaningful value, not toiling with technical debt you might not have even caused. 

Day 1 highlight 

Day 2 

From Dr Lewis’s talk, psychological safety – how to boost creativity and increase collaboration– backed up many of my thoughts and ideas about PS. But one I had yet to hear before is the first attempt at learning or, shorter, Fail. 

I learned from Jaimella Espley Laughter and High-performing Teams that Laughter could help people bond and feel more psychologically safe. I also learned that play is an excellent tool for encouraging Laughter, but also that it shows people that it’s ok to express yourself in a way that is none judgmental. You also don’t have to be funny. Find the little things that make people laugh, amplify them, and iterate. It won’t always work, but eventually, you’ll find something that does. 

For me, the underdog talk of the day was Giovanni Asproni’s remote mob programming in a high-stakes environment. This team built the UK’s COVID-19 app for track and trace. I got four takeaways from this. 1. In a high-stakes and pressurised environment, remote mobbing is a great way to ensure you create a high-quality and on-time product, regardless of your team’s skill level. 2. The bottlenecks in any team are always at the interaction points. So limit them as much as possible by stopping handovers and mobbing/pairing on work. 3. Leaders can act as firewalls and gateways to your engineering team, so use them to shield them from distractions. And 4. working in a mob forced you to work through your differences. You can’t put it off or ignore it for very long, so you have no choice but to either find a way through or someone has to leave. 

Day 2 highlight 

Day 3 

Annette Joseph’s talk, seven steps to Unlocking the Power of diverse teams, showed me a great way to help people connect to the idea that our in-groups are often less diverse than we might think and are usually products of our environments. So if you want more mixed opinions in your life, change your environment. She also introduced me to the concept of group attribution error which is similar to the fundamental attribution error but applied to how we think of our in-groups as rational and logical people but our views of out-groups as illogical and prone to bias. Also, our brains reward us when out-groups fail and feel pain when our in-group fails. This reinforces why we like people that look, sound and act like us. 

Jon Ayre’s talk, Agile at Scale, taught me an important lesson: context limits what you can see within a given situation using a simple game that asked people what the following symbol meant (X). Most said the letter X. But to a Roman, that would have been the number 10. He then asked how you would make it a 9. You would add ‘I’, which makes ‘IX’. He then asked how did you get 6? We all said it would be ‘VI’, but one person said to add ‘S’. Because we had all been thinking of Roman numerals, our brains couldn’t see the seemingly obvious right in front of us. He also showed me how much we are products of our environments using an example of experiments on rats. If given limited food, they would fight and kill each other. But if they were put into enriched environments and given the same amount of food, they were more willing to share and survive together. It’s often not the person (which is our bias of naive realism at play) but the environment that makes people behave the way they do. Culture is a response to the climate, so don’t try and change the culture to change people’s behaviour. Change the environment. 

Valerie McLean’s talk, it’s simply not that simple, showed me soo many things. But, if I had to narrow it down, it reminded me about complex adaptive systems and the four categories people can often fall into when coming up with solutions to problems. These are – Hierarchise, who see issues due to lack of rules. Egalitarians see problems stemming from the weaknesses of a community and that we need more solidarity. Individualists see things done to people not playing their parts, and fatalists see everything as doomed. Ceri Newton-Sargunar helped me understand how these could connect to our fight, fawn, flight and flip response to fear. Valerie also reminded me of enabling constraints, which I’d forgotten as a tool and need to use more. She’s also onto a great idea on 7 steps on how to work with complexity, which is worth keeping an eye on.

Day 3 highlight

  • It’s essential to work with people who have different perspectives and backgrounds from you because your domain context can limit what you’re able to see. Jon Ayre emphasised this point in his talk on Agile at Scale.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *