12 things I learnt from Agile Manchester 2023

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 – Software is not like wine but more like milk. You want to use it quickly before it goes bad. – From Charity Major’s talk, is it time to fulfil the promise of continuous deployment
Day 2 – The bottlenecks in any team are always at the interaction points – From Remote mob programming in a high-stakes environment.
Day 3 – Working with people with different perspectives and backgrounds is essential because your domain context can limit what you can see. Jon Ayre emphasised this point in his talk on Agile at Scale.

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

Software is not like wine but more like milk. You want to use it quickly before it goes bad. – From Charity Major’s talk, is it time to fulfil the promise of continuous deployment

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

The bottlenecks in any team are always at the interaction points – From Remote mob programming in a high-stakes environment.

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.

Scales of Collaboration

Reading time: 3 minutes

Idea in brief: The scales of collaboration can help you and your teams to work more effectively by improve your collaboration. It allows you to measure how you are currently collaborating and what you can do to improve its effectiveness. But what’s wrong with our current approach and how do you use the scale?

Issues with existing collaboration

Whenever I talk with people who work in teams one of the things I hear quite often is how much they are collaborating. But when we start digging into what they are doing you begin to notice that everyone has a different idea of what collaboration means.

This results in behaviours between team members that puzzles them when they think they’ve done everything right but the other people don’t respond in the way they anticipated.

Examples I’ve heard of collaboration :

‘They should know where to find all the information’
‘I sent them an email with all the details, they just never did anything with it’
‘I gave them an opportunity to feedback anything they wanted, they didn’t so it must be fine’

In all three cases the people involved believed they where attempting to collaborate but in reality all they where doing was making information available. It was up to the recipient to decide what to do with the information if anything.

Scales of collaboration

If this isn’t collaborating then what is it and for that matter what is collaborating? This is where the scales of collaboration could come in useful. Taken from the work of Bruce B. Frey et al 2004, Measuring Change in Collaboration Among School Safety Partners . Which was originally developed from Levels of Community Linkage Model (Hogue, 1993)*. It was developed as a questionnaire to measure how well groups of people collaborated.

*Which unfortunately I’ve been unable to find the original paper only references to it

This works on 0 to 5 scale with each level having a defined set of characteristics. Where 0 is no interaction at all and 5 being collaboration. With each level building on top of the previous one.

**Scales of collaboration** developed from Levels of Community Linkage Model (Hogue, 1993)

When applied to the collaboration examples above you can see that example 1 is just making the information available which would indicate level 1 – Networking. Example 2 while is providing the information isn’t asking them to do anything which is level 2 Cooperation. Example 3 would welcome feedback but isn’t explicitly asking or providing them with a mechanism to do so therefore it would also be level 2 Cooperation.

Following the scale up towards level 5 begins to highlight what else each example would need to do to improve their collaboration.

Characteristics of collaboration

I have further augmented the scale with a few extra characteristics. This will also help you work out where you are on that scale and what you trying to achieve. This includes

How you make information available to others
Consumer/provider interaction model of this information
Speed of decision making
Engagement levels of the people involved
Examples of what each level of collaboration could look like

I’ve also left off level 0 on this diagram as that would indicate no interactions and possibly not even awareness of one another.

How to us it?

Establish where you are on the scale
- You could do this by seeing if what you are doing fits onto the scale based on its characteristics or if it looks similar to the examples on the scale provided
- Once you’ve established where you are on the scale then
Where do you want to be on the scale?
- The best way to do this is to identify the aim you are trying to achieve based on:
  - The information:
    - Is it just information providing, an opportunity to get feedback or to change opinions/direction?
  - Decision Speed:
    - How quickly does a decision needs to be made
  - Engagement:
    - If something needs to change due to that information and/or decision then there will be a greater need for engagement
How will you move up (or down) the scale?
- Use the characteristics on the scale as possible things you could do to move to this level
- What do you need to do to move in the direction you want to go in?
Share the scale with the people you are trying to collaborate with
- This would create a shared understanding of what collaboration means to this group
- Which helps everyone involved understand what is going to be expected of them and what overall outcomes everyone is trying to achieve

If you have already started to work with people then I would also avoid trying to jump straight to where you want to be. The risk being that it doesn’t lead to the collaboration you anticipated. Which could make it much harder to convince those people of your collaborative efforts in the future.

My personal preference is to use each stage of the scale as a stepping stone to the next. This way you iteratively build up your skills and approaches towards getting more of what you want and less of what you don’t. This also allows more room to tweak approaches as you get feedback and are therefore more likely to be successfully in the long run.

What do you think?

What do you think of the scales of collaboration?
Where do your teams sit on the scale?
Would this help you and your teams to collaborate more or less?

Let me know in the comments section below.

Foundations of great teams? Start with relationships

4 mins reading time

tl;dr: check out my miro model to get the key points.

Model of who do we prefer working with

https://miro.com/app/board/o9J_khGWgWc=/ — Good informal relationships are they key to better collaboration https://miro.com/app/board/o9J_khGWgWc=/

Over the last couple of years I’ve started to see that relationships between people appears to play a big role in how successful their teams are. The better the relationship the more willing those people are to share ideas and learn from each other. Which generally leads to much better results for those teams in the long run. Not only that they get those results a lot faster and are typically happier too.

But this is work so shouldn’t we be leaving our personal feelings at the door when it comes to getting things done? What do relationships have to do with anything?

Who do we prefer to work with?

One thing I have seen is that when people like each other they tend to be more likely to work together then people who don’t like each other. Generally for people who don’t get along their interactions tend to be the bare minimum usually resorting to asynchronous methods of communications like email or other group message systems (Slack, Teams etc). They pretty much do anything they can to avoid face-to-face contact.

The problem here is that this can leave messages more open to interpretation and further exacerbate poor relationships. Not only that sharing information this way can at times be slower than simply speaking face-to-face.

But how much do people have to like each other to work together successfully and is there anything we can do to make sure people who do have to work together can get along?

How much do people have to like each other?

The amount tends to be quite subjective but these types of relationships are usually characterised as work colleagues or sometimes work friends. They are essentially informal relationships between people who work together where they are very likely to say that the like each other. Multiple informal relationships lead to informal networks which can make working in teams much more productive and enjoyable for the people involved.

The benefit of informal networks is that they are more likely to lead to collaborative behaviour that enables learning from each other. This in turn can lead to new ideas and innovations. Which all successful teams need.

What can we do to help people get along more?

By helping people to find more common ground with each other tends to lead people to think of each other as we rather then us and them. This common ground can help people to see that they are similar to each other which can lead to familiarity. Both of which can help towards more positive reciprocal behaviours towards each other. All three of these (similarity, familiarity and positive reciprocal behaviours) benefit us psychologically by making us feel good.

Feeling good to think and collaborate

When we feel good we are more likely to think freely rather than when we feel threatened and are looking to protect ourselves. When we are threatened our brains actively limits resources from working memory. Working memory is a key component for analytical thinking which you need for creative insight and problem solving.

The level of collaboration is also improved as when we feel good we are also more accepting of people’s differences and more willing to take interpersonal risks with other people. Interpersonal risks are very personal to the individual but can typically be classified as:

Looking incompetent because you don’t know something when you think you should
Thinking you are being disruptive by wasting someones time by asking questions or needing things to be explained in more detail
Looking ignorant because you don’t know something

All three of which can have perceived negative consequences to your reputation.

All these risks need people to be vulnerable in front of others so that they can learn from each other and therefore collaborate more effectively. But if they are unwilling to do this then they are not going to share what they do and don’t know which leads to less effective teams. Essentailly everyone has to figure things out forthemsevles instead of learning it quickly from someone else.

Feeling good means better innovations?

Better team member relationships, feeling good, collaboration and learning from each other doesn’t guarantee that the team will come up with best and most efficient solution to a problem. What it does do is create the right conditions for those solutions to found and implemented.

Not only that a team that enjoys working together and is able to work through their differences is more likely to keep doing this repeatedly and get better at it every time they do. Therefore leading to more ideas and increased likelihood of the team finding alternative solutions to problems. One of which might just be that innovation your organisation has been looking for to give them the edge over their rivals.

What are the trade-offs to all this harmony?

There is a risks of overly harmonious teams though. This is that they are less likely to challenge each other and are more likely to go with the flow. Which could actually lead to less innovation and creativity. As they are more willing to just accept the first idea rather than challenging it which could risk the team harmony. So some level of “creative abrasion” is needed to help people productively challenge ideas.

But again good working relationships will help stop challenging situations from causing so much tension that people begin to refuse to work with each other.

Is there data that back this up?

Research by Tiziana Casciaro and Miguel Sousa Lobo for their 2005 paper Competent Jerks, Lovable Fools, and the Formation of Social Networks backs up a lot of the ideas above. Their data was based on surveying 4 large organisation and collecting over 10,000 data points on work relationships.

You can find my notes in this model.