An interview with John Le Drew by Kornelia Trzęsowska, part 1
Has the pandemic influenced somehow how teams work with agility?
I don’t think the pandemic has affected how we would apply agility or how we would work with it. I would say that teams that are already operating with agility are going to be able to adapt to their circumstances. What I talk about a lot is the idea of contextual alignment, this model has two core elements: you have the team context; the work the team is doing and the people on the team themselves. This is obviously changing all the time. Then you have the structure; this is the way the team is working (their process) and again, the people on the team. The structure is a team’s reaction to their changing context. A team notices that their context has changed, and adjusts their structure to best support their new context.
When the context changes, it could be something small like discovering a bug, or a new requirement. It could also be something related to the people on the team (remember they are part of the context as well) like a key team member going on paternity leave or, it could be something huge like a global pandemic that could completely change the way the team is working, and probably the whole business strategy will have to pivot as well. The heart of any individual, team or organisation operating with agility, is making continuous adjustments to their structure in order to support their ever changing context.
How does psychological safety affect teams working with agility?
Psychological safety is foundational to any collaborative situation, regardless of agility. Individuals on a team are safe when they can say what needs to be said, however difficult that might be for them. If there is a quality problem, then it probably won’t get fixed if nobody says anything about it. Esther Derby once described psychological safety to me as “speaking your truth”, which is a definition I like as it naturally leads into something I consider to be a foundational part of team agility.
An individual on a team that is able to speak their truth, is a person who is able to be their authentic self. And a team with a high level of psychological safety, is often one where the team can collectively speak its truth. And that team is able to build (and adapt) the most effective structure to support their context. They will have a high degree of contextual alignment, you see, you can’t align to your context if it’s not safe to talk about it openly.
The interesting thing about this model is that people are core to everything about it. People are everywhere, and really, that’s an accurate reflection of the teams we all work on. I think most people are exclusively on teams made up entirely of people, unless the robot apocalypse is closer than I realised! And everything you do as a team will affect and be affected by the people on the team. If your context changes because the pandemic forces everyone to work at home; the structural change (everyone working at home) has hugely affected the people. When a team changes their structure, they also change their context, and it’s always a fine balance of small, mindful adjustments.
Safety is critical to building and evolving your team’s structure over time. The structure is there to support both the work and the people delivering that work. If the team can’t have open and honest conversations about their work and also (I think perhaps most importantly) their individual and collective needs as people; what they need to be the most effective team they can be in that moment. Then they will never be able to build the most effective structure to support them and they will be misaligned.
What this really comes down to is authenticity. Creating an environment where people can bring their whole self to work. A team self-organising to build a structure that perfectly supports all the individual and collective needs of every member on the team, and also balances the needs of the business is like an F1 team, working in perfect harmony across multiple disciplines to get their car over the line ahead of the competition.
Safety creates space for people to be authentic, and I think there is a direct relationship between authenticity and efficiency. Someone who is being authentic, is aligned to themselves. A team, with a structure that is perfectly aligned to support the collective needs of its members is going to be incredibly efficient. I’m sure many people can remember being part of a team like that, how great that felt and how effective they were (or are still hopefully!).
In order to get there, team members must be safe to discuss their individual needs. For example, for me to be most effective, I need some “decompression” time on my own after speaking, giving a workshop or facilitating a meeting. Those larger group activities are something I love doing, but I find them exhausting. So for me, I need to take 20 minutes to myself after something like that to be the most effective I can be. For others, it might be the opposite. Some people love working in an open plan office with the hussle and bussle all around them, others find that impossible. But if half your team is unhappy in your open plan office and it’s not safe for them to express how this isn’t right for them, then half your team is going to be less effective than they could be. And that just doesn’t make business sense.
I often compare this to energy conversion in physics, like if we have a light bulb and want to convert electrical energy into light energy. Ideally, 100% of the electricity we put into the bulb is going to light our room. But in reality, a light bulb (especially the old tungsten ones some might be old enough to remember) are very inefficient. And they waste a lot of energy, very little of the electricity we put into them is actually converted to light, much is given off as heat. If we apply this to a software team, we might have money, time etc. on one side, and on the other, working software that’s delivering value. If a team’s process (aka structure) is misaligned to their context, then the process is inefficient and wastes energy. The process itself is getting in the way of the team’s progress, and as they continually butt up against it, this creates friction and heat. And just like our lightbulb nearing the end of its life, in our teams, we see this heat as disengagement, cynicism and eventually, burnout.
What is a key focus of the work you do with the teams you support?
One of the main facets of my work and an area I specialize in is working with teams, to (and I know it sounds a bit cheesy, but I’m just going with it) “embrace uncertainty”. I know that everyone says: “Oh, you’re ‘agile’, you should just embrace uncertainty and go with the flow!” But, When I say “embrace uncertainty”, I really mean talking about and working with uncertainty, in a tangible way. When you embrace something, you are literally accepting it into your personal space, into your life. And, if you hug something, you can’t simultaneously pretend it’s not there.
I think what we tend to do is just pretend uncertainty doesn’t exist, because it freaks us out. Something I have recognized is that uncertainty is probably the greatest cause of fear and anxiety for most people. In a (typically psychologically unsafe) corporate setting, speaking up to point out that the team doesn’t understand an aspect of the business or that they think the direction the project is taking might not be the right direction, can be very risky. So, we just keep going forwards, everyone pretending they can see the emperor’s beautiful new clothes. Only in this case the emperor’s imaginary clothes, not quite covering his very real nudity, are an imaginary bridge, not quite scaling a very real ravine.
It’s like, you are a project manager or program manager and have just been given a 10 million pound budget for the next 12 months of work to deliver this key thing. And you think: “Oh, crap! I have 12 months to deliver this probably undefined thing that I don’t really understand! The product owner doesn’t really know what they need to do and obviously I don’t even have a team yet because why would I have a project team already? I have vague requirements, a budget and a deadline! What more could I possibly need?! Yeh. That’s right. I need a plan!”
So you make yourself feel better by sitting down and firing up Microsoft Project to create the most beautiful Gantt chart the world has ever seen. You sit in the middle of your office floor, wrap the huge chart around yourself rocking back and forth, humming and sucking on your thumb. You feel much better, the chart is still warm from the printer and it reminds you of your childhood blanket. Very comforting, but just like when children cover their eyes and insist they are invisible, your plan hasn’t helped deliver anything, or make the real risks disappear. You just can’t see them. And that is a whole lot scarier.
But is that plan really a complete waste of time? Perhaps, the next week or two might benefit from that plan. But a month down the line? 3 months? That plan for 12 months was probably over 95% wasted effort.
Just think about how accurately you can predict the day’s events when you wake up in the morning. Let’s say that you lead a pretty mundane life and you can accurately predict 80% of what happens to you over the next 24 hours. What about the next 3 days? That percentage drops pretty sharply doesn’t it? So, what about 200 days? Eeek.
Your 10 million pound project, probably (thankfully) has more than just you on it. As we learnt before, people are central to everything we do. But it’s those very people, who are obviously essential, but also very alive and very unpredictable. Whether we like it or not, good or bad, life tends to happen. And with maybe 8 to 10 people on a team
(plus all the other people that any project at scale will depend on) there is a lot of life to go round.
In medicine, if I want to release a drug into the market, I have to demonstrate efficacy some way above the placebo effect in order to have the drug approved. Is your extensive 12 (or maybe just 1) month plan any more than a placebo that makes you feel more comfortable?
You refer to storytelling a lot, how could it help in working with uncertainty?
I’m not sure storytelling helps with how we work with uncertainty, but we do tell stories all the time. We (the human race) were telling stories as cave paintings before we had language and oral tradition is so foundational, it has been described by Prof. John Foley as “as the single most dominant communicative technology of our species”. That is, storytelling. Telling a story is the single most potent way to communicate an idea to another human. Our brains light up when we realise there is a story being told, even if it’s a rubbish one! And we tell stories to make us feel better about things that scare us, like uncertainty.
We have done this for thousands of years. Not using Gantt charts as comfort blankets! But, telling stories to make the unexplainable, understandable. Many millennia ago, somewhere in northern Europe, there was a loud and terrifying crashing in the sky, white light seemed to reach down from the clouds and where it touched, fire and devastation was left in its wake. The humans in the area couldn’t explain what was happening, but they were (as ever) armed with stories. With that Thor was born, and with him came some “certainty” around what was happening.
Now, all they had to do was sacrifice the odd goat, perhaps their least favourite child and they could keep the lightning from touching their house. At least, that’s what the village chieftain said. They certainly felt better with the story they told, but how do you think it affected their chances of being struck by lightning? Thankfully, management consultants haven’t started recommending human sacrifices just yet.
So, is storytelling all bad then?
No, not at all. It’s just incredibly powerful. There are many places for storytelling (of the less fictional kind) in our projects. For example, I was facilitating a story mapping activity recently, and in that we are actually using storytelling to tell the story of a user’s experience with a product. Often, we use personas to allow us to better imagine a user’s experience, it’s not just an ‘accounts user’ it’s Marjorie, 37 with a 6 year old child. You can empathise with Marjorie, far easier than with ‘accounts user’. I think most people have probably read a novel where its characters are obviously not real people at all, but you still connect with them deeply. And that connection helps us deliver better software. Because we actually care. All with a little storytelling.
But, remember, a story doesn’t change anything. It just puts a frame around it. Sometimes the frame makes the painting, sometimes, it distracts you from what is really there.
Telling a story is exactly what we do when we make a big detailed project plan. That is our story that is making sense of the uncertainty that lays before us. While it’s very valuable to tell stories in order to better understand the work needed to be done. The stories themselves don’t actually reduce the risk of a failed delivery.
Projects rarely (if ever) fail because we didn’t plan them enough. Projects fail because of people, because of uncertainty, because of all the things we could potentially have mitigated if we hadn’t ignored them at the early stage. What I’ve recognized is that one of the reasons teams don’t talk about uncertainty and pretend it’s not there is we don’t have the language to engage with uncertainty in a way that makes it safe. We can make it safe, not by closing our eyes and pretending it doesn’t exist, but instead engaging directly with it, head on.
Like with many problems that seem insurmountable in the mind’s eye; once armed with the right tools, they begin to feel like something you can manage again. And, speaking from experience, I find a good pack of post-its and a sharpie beats human sacrifice any day.
The interview has been conducted by Kornelia Trzęsowska in collaboration with Aneta Catalan Sikorska
John is the founder and principal consultant at Rainbow Laces. He has spent most of the last 2 decades working in the software industry. After 10 years as a software engineer he moved into consultancy where he quickly learnt the value of team dynamics and how most technical challenges are projecting underlying issues with collaboration. So, his focus shifted, primarily on facilitating safe, creative, collaborative environments for his clients. As well as his consultancy work, John is a DJ and producer and through this work founded the The Techno Festival, online charity music festival that has now, after three events in 8 months raised over $35,000 for charity. He lives in Manchester (UK) with his two boys and cat. He loves experimental cookery, photographing things that others don’t notice, getting lost in cities he doesn’t know and travelling to places he has never been to.
[ENG] Project Manager based in Wrocław and fascinated by the IT industry and Agile management approach. She considers effective communication and openness to others to be her greatest strengths. Creativity is her second name and if not management – she would probably become a journalist. She is fluent in German, loves this language and culture, and therefore enjoys most working with clients from German speaking countries. After work, she recharges her inner batteries thanks to creative activities such as writing, painting or photography and reading about psychology. She has been active as a volunteer for several NGOs for a long time.
[PL] Pochodzi z Wrocławia i pracuje jako Project Manager w IT, co bardzo lubi – branża ta codziennie zaskakuje ją nowymi wyzwaniami. Dodatkowo dużo przyjemności sprawiają jej kreatywne i artystyczne zajęcia – od zawsze lubi pisać, a jej dziecięcym marzeniem była praca w gazecie. Strefa PMI jest dla niej przestrzenią, która pozwala łączyć różne pasje w jednym miejscu oraz być na bieżąco z PMowym światem. Czynnie wspiera wrocławski oddział PMI.