The Things I Go Back To When Working With Agile Teams
My talk at Agile Yorkshire — 3rd July 2024
Hello
Please add a few words about what you do. That could be your job title or not, it is entirely up to you. Thank you, a lovely varied group in the room. I am mostly a coach, facilitator and trainer these days. I have spent a lot of the last ten years doing these things under a lot of different job titles. I have been an engagement manager, service manager, programme lead and others. Mostly in those jobs I was helping government, agencies and digital teams to build capability among people joining ‘digital’ for the first time. Some of those people were from “the business” as they refer to themselves. In general they are people who have not had much experience of technology.
Here are some things I have found useful when working with these groups.
Curiosity
Please let me know what you think is important about curiosity and how we can encourage it? In this context I am mostly talking about people who are joining teams from elsewhere in government.
Yes, here are some things I have captured in case we did not get them.
The most important things for me is that we create a safe environment for people to be able to ask questions and encourage experimentation and learning.
One of my favorite tools is The Celebration Grid. Jurgen Appelo wrote a book called Management 3.0 and there are lots of great tools in that. In this one we work in three levels of outcome: success, failure and learning and three levels of behaviour: mistakes, experiments and practices. What we want is more learning and more success and so if our favoured behaviour is to use practices and processes, which applies to a lot of the people I come into contact with, we will have mostly success but we will not learn very much. Occasionally things will go wrong despite the process or practice but in the main we are repeating things which are well understood and embedded. In order to innovate and to do new things we need to open ourselves up to possible failure by experimenting. If we experiment and we fail, we learn and if we are successful we also learn. Mistakes are things which are not planned and so there is little learning but occasionally they will be successful. We should look for ways to avoid those mistakes in the future.
One of my cheesy sayings is “we win or we learn and then we win”.
It is a great way to run a retrospective. People can identify things which happened in the period and place them on the template (either printed or on Miro etc). You could have a persistent template and people could add things to it throughout the iteration once they get the hang of it.
Community
You know what to do: In one of the big pieces of work I did we were training people across government in a brand new role and so we put them into cohorts. They had a little community and then were included in the larger community as they went through their training. We found it worked really well as a lot of these people were the only ones or one of very few in their department with this role.
Again more about trust, learning and collaboration.
One of the important enablers for this is for time to be allocated for people to build community and learn together both in teams and across functions. I always think that eating together is great for group cohesion.
I did a piece of work for a product community who had started well but had got to a point where there meetings were a round robin of updates. We made some suggestions for other formats for the meetings. I use a lot of Liberating Structures and one of my favourites is Troika Consulting. This was one of the patterns we tested with the group. Three people, each with a challenge, take it in turns to get and give advice. The first person takes a minute to describe their challenge, then the other two people ask clarifying questions for 2 minutes. After that the ‘client’ turns off their camera and mic and the ‘consultants’ tak about the challenge for 5 minutes. At the end of the time the client comes back and says thank you and tells the consultants what the most useful comment was. The group decides who will go next and continues. Each person spends twice as long giving help as getting help and every time I have done it someone has come away with something really useful.
Confidence
Once we have piqued their curiosity and created a community hopefully they are already feeling more confident.
The big things here and it is reflected in your contribution is psychological safety.
“The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for interpersonal risk taking” Amy Edmondson, 1999
In order for this to be the case the culture needs to be one where people feel safe to express their ideas. Regular 1:1s with feedback and positive reinforcement and no micromanagement are key.
This is an onboarding template using Trello created by Sarah Carter. It allows you to give a new starter a lot of information to consume and tasks to complete. I had one when I started at GDS in 2014.
When I joined GDS we had a lovely delivery manager who had a pilar of praise. We would add stickies to it during the week and talk through them at our weekly get together.
Another Management 3.0 tool is Kudos cards. They can be purchased as physical cards. Justice digital in Sheffield had these covering an entire wall. You can also download a PDF and use Miro or something similar.
One of my first actions when joining a team is to set up a Slack channel for appreciation. I use it to thank the people who have helped me onboard and add them to the channel and then it grows organically until everyone is in there. It is an absolute joy. When I left dxw F put a post in appreciation, appreciating that I had set it up (meta) and when I joined my next team and they already had a channel this was Clare Young’s response.
Of course you need to be careful it doesn’t turn into this.
Capability. The point of all this, building the ability to do the work.
Trust, learning and confidence get a look in again.
I think that we have probably covered most of these across the four areas
A lot of people only see learning as training courses but my preferred way for us to learn is by working together, pairing, being a backup for each other to avoid single points of failure.
If I have a group who either know nothing about agile ways of working (or think they know everything) I use this exercise. I ask for one thing per sticky with things they have heard about agile which they things are true, they think are not true and they are not sure about. There is often duplicates in more than one area and if this is the case I will ask the group. Usually someone will give a really good answer. If the answer I get is not something I agree with then I will ask if anyone has a different opinion. I very rarely have to give the answer myself.
A favourite exercise is the fruit estimation exercise. I give the group cards for 10 different fruits (or they are on Miro) and tell them that everything is ripe and clean. They need to decide the order or most difficult to prepare and eat to easiest to prepare and eat.
Every time I do it we get into specifics about the fruit but it works really well. e.g. Not many people know what a dragon fruit is or how to prepare it. If this was something you are working on what would you do? They usually come up with a technical spike or more research. Each fruit is on a card by itself and so the mango is often confused for a necterine. People argue that they are different but I say that they both have a stone in it so they can cut the fruit in half and remove the stone. The funniest things always come about when discussing the kiwi fruit.
- “We need to peel it, it is a pain” — “no you cut it in half and eat it with a spoon like an egg” 🤯
- “You can eat the skin” “Urgh”
- “It is easier to eat than an orange, they invented easy peelers and so the others are difficult to peel” — honestly we thought this guy had gone to buy an orange and a kiwi fruit to prove his point the next day.
Another favorite Cynefin by Dave Snowden. This is a sense making model. When people get a couple of days into training or onboarding I usually get one who says something like “just give me the best practice” or “Is there a checklist” which gives me a great opportunity to introduce Cynefin.
Cynefin is made up of five domains. Confusion in the middle where we put things which don’e yet have a home.
Clear which does have a direct cause and effect relationship. It is best practice and is tightly constrained there is no freedom. My example for this is that I am doing a talk and need my dress laundered. I give my other half a checklist. Turn the dress inside out, wash it with this much of this detergent, put it on this programme, when it is finished hang it from the shower rail on a hanger. If he follows these instructions we have a good chance of success, like the practices in the Celebration grid.
The next domain is complicated. Again there is a direct cause and effect relationship we can see. My example for this is my car which needs a new catalytic converter. I need someone with expertise and the right tools to fix this for me. There might be more than one way to do it. It is good practice I just need to pay them money.
The next domain in Complex. There is no cause and effect relationship which we can discern up front. You can see a relationship looking back. There is emergent practice and we need to try things, keep doing those things which are having a positive effect and stop doing those things which are not working or having a negative effect. My example is medicine. I have a chest infection. The GP asked me some questions, took my blood pressure, listened to my breathing and sent me for a chest xray. I developed a sharp pain and so another GP looked at the xray which suggested an infection and prescribed some antibiotics. If that doesn’t clear it we will keep trying.
The fifth domain is chaotic. My example is a fire. There is only novel practice. With chaos you just need to try anything to resolve it and then move it into the next appropriate domain. It is possible for things to move domains such as the fire from chaos to complicated. If my other half did not follow my instructions properly and shrunk my dress we would be in chaos pretty quickly. I recommend learning about Cynefin as it helps people to understand why we can’t just plan harder to make certain things happen.
Switching forces from Jobs to be Done is really useful when you are trying to understand the appetite for switching from an old solution to a potential new solution. Above the centre line are things which enable to switch from old to new and below are things which block the switch.
For example if the old system has frequent failures that will push people towards switching to a new system and if the new system has redundancy to avoid those failures that will pull people towards the new solution.
If people are very familiar with the new solution that will create intertia and may discourage people from switching. Also people may feel anxiety about the readiness of the new service and whether it does everything the old one does.
This is a reason that people sometimes continue using a poor legacy system rather then change to a new service which is being incrementally built.
Geoffrey Moore wrote Crossing the Chasm. His main thesis is that the needs of people who are prepared to use something very new are very different to those who come afterwards. Innovators want the cachet of using something new and different. Early adopters will compare utility but when it comes to the later groups they need much more in order to trust the service enough to change.
Here is a real example. Tana is a note taking tool. I was an innovator and early adopter. As they move into beta they are finding that people want the whole product and as a small team they are scrambling to provide all of the needs.
These are genuine requests and complaints on the product Slack channel asking for updates on the full featured mobile app and if there will be parity for android users as well as IOs. iPad and apple watch functionality, MacOS calendar integration and better and more certain communication about timing of features which sounds very familiar.
This is one of the teams I worked with. We started off as people from three different organisations including developers, researchers, service designers, content designers, product and delivery management and policy people from a government department who had no current responsibility for running a service and we worked together to build the service, resolve problems and to determine processes and procedures. This photo is the only day everyone was in the same place as we were mostly a distributed team and was the day we made the service available on GOV.UK.
Excellent, I am happy that the fruit estimation went down well.
Here are all four pieces together
Thank you.
