Why ensemble working builds stronger engineering teams with Clare Sudbery

In this episode of The Digital Lighthouse, host Zoe Cunningham speaks with Clare Sudbery, independent technical coach, consultant, and international speaker. Clare draws on over 25 years in software engineering across industries including healthcare, insurance, and travel. She now helps technical leaders and teams improve performance through clarity, alignment, and collaborative practices.

Together they explore the concept of ensemble working (also known as mob programming or software teaming) – where teams move beyond pair programming to truly co-create. Clare explains why complex software systems demand collaboration, how agile and extreme programming practices have shaped ensemble work, and why kindness, iteration, and fast feedback loops are essential for modern development.

Discover

• What ensemble working is, and how it builds on pair programming
• Why large-scale software can’t be built effectively by isolated individuals
• How agile and extreme programming principles underpin ensemble practices
• Why short iterations and shared learning reduce risk and increase agility
• Real-world examples of onboarding, training, and feature delivery through ensemble working
• How collaboration accelerates feedback, eliminates bottlenecks, and spreads knowledge across teams

If you enjoyed this episode, please subscribe so you don’t miss any future episodes. We would also appreciate a few moments of your time to rate and review on Apple Podcasts and Spotify; we value all feedback from our listeners to deliver the best content and experience.

Listen here:

Watch here

Episode Highlights:

• [10:42] What “ensemble working” really means, and how it extends pair programming
• [13:09] Why modern software demands team collaboration
• [17:01] How extreme programming and agile practices shaped ensemble work
• [21:22] Fast feedback loops and no-blame culture in action
• [23:52] Inside Hunter Technologies: a company built on ensemble working
• [31:08] Why onboarding and training are the perfect use cases

Catch Clare at Outpace Conf (16th October, Manchester)

You can hear more from Clare on the topic at Outpace Conf next week (16th October in Manchester). She will be joining a host of speakers across 12 talks, including:

• The Road to AI-Generated Descriptions: Insights from Autotrader – Catherine Dickens & Tania Nandy
• Lessons from Autotrader going all in on data products – Thomas Inman
• Navigating the legal frontier of generative AI – Emily Nousios & Kristina Holt
• Team Topologies Vs Feature Teams – Luca Minudel

About our guests

Transcript

[00:00] Zoe Cunningham: Hello and welcome to The Digital Lighthouse where we get inspiration from tech leaders to help us navigate the exciting and ever-evolving world of digital transformation. I’m Zoe Cunningham.

[00:00:11] We believe that meaningful conversations can illuminate the path forward, helping us harness the power of tech technology for innovation, scalability, and sustainability.

[00:00:21] On this episode, I’m delighted to introduce Clare Sudbery. Clare is an independent technical coach helping clients improve team performance through clarity, alignment, and behaviour.

[00:00:33] Clare has an impressive 23-year career history in software engineering at organisations including the National Institute for Clinical Excellence, Swinton Insurance Group, and laterooms.com.

[00:00:45] In between her technical roles, Clare has also worked as a maths teacher and achieved the impressive feat of writing two novels. In her current role, she supports technical leaders and helps technical teams improve their software engineering practices.

[00:01:00] In this episode, we’ll be diving into what it means to truly work ensemble, where each team member is not just working alongside their colleagues but truly collaborating.

[00:01:11] Clare will walk us through the benefits. Clare, welcome to the Digital Lighthouse.

[00:01:18] Clare Sudbery: Hello, and thank you for having me here.

[00:01:20] Zoe Cunningham: Clare, you’ve worked in software engineering across an incredible range of organisations, from public sector to insurance, to travel. Could you share some more details about your journey and what you’ve learned along the way?

[00:01:35] Clare Sudbery: I mean, I have to be careful ‘ cause it could take a long time. And interestingly, I realised I hadn’t quite proof checked your bio because you said 23 years and it’s now more than 25 and I’ve stopped counting. Yeah. Oh all I could say is it’s more than 25 years that I’ve worked in tech.

[00:01:56] I, I think that I, I quite like the way that… that, the story that I often tell people is that I see my career as having been split in two halves.

[00:02:05] So I was working for tech companies in Manchester for 12 years. I quickly rose to senior engineer level and then I stopped. I, you know, I was a senior engineer for like 10 years or whatever. I became less and less engaged with what I was doing. and I think it became a kind of vicious cycle. You know, I asked to do the more interesting stuff. People said no, so I got less interested.

[00:02:34] I always struggled with insecurities that I didn’t think that I knew as much as my colleagues did that I think I didn’t think I was as good as my colleagues. I think a lot of that is to do with having very frequently been the only woman on the team. And it’s very difficult not to let these crazy ideas get in your head that somehow as a woman, you’re less capable.

[00:02:57] So anyway, long story short, at the end of that 12-year period, by which point I had already written two novels and given birth to one child, both of which were other things that, that were taking my passion and attention, I was made redundant. And, I thought, you know what? I don’t really wanna do this anymore.

[00:03:19] And that was when I became a high school maths teacher. So I spent two years being a teacher. I spent two years being a writer. So that was a four-year period where I was out of the industry, and I didn’t think I was coming back. So I was making no attempt to catch up with what was happening in the industry and towards the end of that 12-year period, my career had been stagnating anyway, so I, I already wasn’t really up to date with what was happening and was less and less interested.

[00:03:47] But after four years, unfortunately, being a high school maths teacher didn’t really work out, and I didn’t have a job, but I did have 12 years of experience as a software engineer.

[00:03:57] And, you know, I could see that that wasn’t nothing, even though I didn’t think that I was gonna come back. So what I did was I did come back into the industry, but I came back at entry level. So, I got a job for a company that explicitly had a habit of taking on graduates and then training them up.

[00:04:16] So they were very strong on training, on teaching and learning. They were very keen for people to both ask and answer questions. It, it was mandated in fact, you were supposed to ask and answer questions and you know, that was part of what they were about. Also, they were a web development shop, and I’d previously only developed desktop software. ’cause I left that… I was major redundant, I think in 2007. And at that point it was entirely possible to, to have nothing to do with web development. You know, to only write desktop software. But when I came back in, the company that I worked for was called WebApps. it was entirely, web development.

[00:04:57] And so that was a, a new skill. You know, working asynchronously instead of synchronously was a big shock. and a logical shift. In terms of how you think about software that, everything isn’t synchronous, but I found it fascinating. I really wanted to learn, and I often tell the story of, you know, one time when I was in the classroom, and one of the pupils said to me, “oh, miss, oh, you have to do is stand there.”

[00:05:25] And I was like, oh God, if only you knew, I wish. I wish I could just sit and have a teacher pump my brain full of knowledge. And I know it’s, it’s not that simple being a teenager, you know, they have other things to worry about. But I, I was jealous. I was jealous of people who got to spend their whole day learning. I wanted to learn too.

[00:05:48] So it was exciting to me to come… And, and the way that I thought about it was rather than feel insecure about not knowing stuff, if I’m just completely, if I just say, listen, I’m an empty vessel. Fill me up. Like, I don’t know anything. Let’s, let’s pretend I don’t have 12 years of experience and then I don’t have to feel insecure about, you know, having to pretend I know stuff that I don’t know. I’m just gonna be really excited to learn.

[00:06:12] And of course, those 12 years of experience were much more valuable and meaningful than than I thought they were. And, and actually I knew a ton of stuff that I didn’t think I knew. and actually software development skills are highly transferable. Even though I’d never done Async before, actually I could pick it up pretty easily.

[00:06:31] That first job I had, they also used SQL, which I’d also never worked with before. So I taught myself SQL in the week before the job interview. I mean, obviously I didn’t become an expert in that one week. But what I realized was I can learn. I can learn. I’m excited to learn. And so my attitude ever since then has been completely different.

[00:06:52] Obviously, I still have insecurities. I don’t think they’re ever gonna go away. I wish they would. You, like you would look at somebody in my position with the experience that I’ve. You know, in, in the second half of my career, I’ve been a, a contractor, a consultant, a technical lead. I teach people, I travel the world speaking at events and running workshops, and still, still, I worry that I’m not clever enough and I don’t know enough stuff and that I’m not as good as everybody else.

[00:07:20] I wish, I wish my brain didn’t do that to me. But it does. And, but it also means that I can understand how it feels for other people. And because I spend so much time teaching, I mean, the way I characterise it now is that I get to be a teacher without having to be a teacher. You know, it’s not my job in a school, but I get to teach adults, which is easier than teaching teenagers because they don’t have so much other crap going on in their heads and they’re more motivated, and engaged.

[00:07:47] But I do get to teach and I love to teach. I love helping people have those experiences of learning, and it actually means that I also get to do even more learning, because I learn to teach.

[00:08:01] Yeah. I will deliberately teach things that I know less about so that I can learn them in order to teach them. And it’s the, it’s the last step of learning. It’s the, it’s the step where things really, really get, get, you get that deep understanding is when you have to teach it to somebody else.

[00:08:18] And so yeah, that, that I, I mean, I, I could give you chapter and verse of how the, the second 12 plus years of my career in involved me trying lots of different modes of working. So I’ve mentioned contracting, I’ve mentioned consultancy. I’m now independent. But one of the things that’s been really important for me is to be able to experiment and change and move and try different things out.

[00:08:43] I’ve also just last year, been diagnosed with ADHD, which is definitely relevant to my tendency to move constantly between different things always be moving and wanting to do something new, the brain absolutely never quiet and full of ideas. One of my challenges is to keep myself on track and not just go “squirrel!”.

[00:09:08] But yeah, it, it is the teaching and the learning and the collaboration as well. So that isn’t, and that’s what we’re gonna be talking about today, but in that second half of my career. What I realised was how powerful collaboration is, and that was something that I didn’t embrace in the first half.

[00:09:29] I think that’s partly how I managed to stay so insecure for so long is that it was too easy for me to work on my own. I wasn’t working with organisations that used agile techniques. So it was entirely possible for me to be sent away with a task to do for weeks, you know? And then come back and supposedly deliver the thing that I’d been working on, rather than there being any kind of regular check-in.

[00:09:56] So that was another thing that… discovering agile techniques, discovering extreme programming practices, discovering collaborative working practices, and realising that they weren’t as scary as they thought, and I could interact with people without exploding. Well, yeah, but it also, but anyway, yes. So it means that I understand what it feels like to prefer to work alone.

[00:10:20] To, to be scared of people finding out that you don’t know stuff.

[00:10:24] Zoe Cunningham: Brilliant. Well, yeah, let’s start there then. So yes, you’ve got this great term ‘ensemble working’ and so I’d love to like explore… for me, I’ve always been like, oh, there’s, there’s teamwork and there’s working as an individual, does ensemble working mean something more than that?

[00:10:42] Clare Sudbery: It does. It’s, it’s actually a very specific practice which previously, people used to call mob programming. And I think, to be honest, within the industry, that is still the most common term. People will talk about mobbing or mob programming. Most people think of it as referring to writing code specifically.

[00:11:02] . And it is an extension of pair programming. So when you’re pair programming, you have two people working together. I was gonna say sitting next to each other, but, but these days, not necessarily, but two people working on the same computer or the, you know, using the same processor at any rate, to build the same piece of code, so they’re looking at the same code at the same time. It’s two minds working on one problem.

[00:11:31] Ensemble programming is that, but with more than two people. I think the sweet spot is between four and six people, and I think most people do tend to work with those kinds of numbers. When I first encountered it, it was before lockdown and before I’d done any remote working, so it was absolutely a team of people like between four and six, literally physically looking at the same screen. And we set things up so that we had a giant table. We actually stole the table from the boardroom, and a giant screen because obviously between four to six people looking at one laptop. Not pleasant, no. That’s, that’s gonna lead to a lot of neck and shoulder problems.

[00:12:12] But ensemble working, it is a group of people working on one computer, one problem at the same time. It’s also called mob programming and it’s also called software teaming. And Woody Zuill who originally came up with the term mob programming, now prefers not to use it. He prefers to talk about software teaming.

[00:12:30] Zoe Cunningham: Brilliant, brilliant. So the other thing I’d just like to explore to kind of set us up is the change you talked about in your journey, right from coding on your own and thinking my job is to be here on my own, to do this on my own, to produce some code.

[00:12:46] That’s what it means to be a coder. To this shift of, we are producing it as a team. And that can mean all kinds of things for what we do individually. So could you explain a bit about why being part of a team is so critical for software development? Why? You know, creating it as a team is so important.

[00:13:09] Clare Sudbery: Yeah. Great question. So it is possible to develop software on your own, but you are not going to do it very quickly and you’re not gonna create anything that’s very big. Mm. And and actually, you know, modern software is typically big, so code bases are big. There’s er, you know, like it’s not unusual to be serving millions of users.

[00:13:36] It’s not unusual to be having millions of transactions a day. That kind of system can’t be built by one person alone. And those kinds of systems which are ubiquitous, they’re everywhere. And also, those big systems, you can have a big system that appears small. You know, you can be building a small mobile app that looks like, even, feels like a physically tiny thing ’cause it’s on a physically small device and it might be doing something trivial.

[00:14:06] It might just be a game or it, it might just be a very small utility app that doesn’t appear to do very much. And yet behind the scenes it’s a large code base with a large team of people working on it that has several moving parts and there isn’t even just one code base. Bits of it are on the cloud, you know, bits of it… it’s interacting with third party services that are scattered all over the place. And so. It’s actually very difficult to build software with just one person.

[00:14:38] And therefore, because the systems are so complex, you need several people working on them. And if those people are operating in isolation, that’s gonna cause problems because not only do the different components of the software have to interact with each other in order to make that happen smoothly, people have to interact with each other and people have to understand what it is they’re trying to do. They have to understand how each part works, how the pieces interact. They have to understand what it is the user wants. They have to understand how it’s deployed. They have to understand security concerns.

[00:15:24] They have to understand lots of things, but no one person is gonna hold all of that stuff in their head. So different people have to understand different parts to greater or lesser degrees, and that’s only going to work if they can communicate with the other people who know the other things and be able to do that in a way that means that each person isn’t just telling everything they know to another person.

[00:15:51] We have to be able to understand what’s important and what isn’t important. And we have to be able to prioritise, and we have to be able to communicate when things go wrong, and we have to be able to collaborate about how to fix things when things go wrong. All of that… all of that requires a lot of collaboration and a lot of communication.

[00:16:16] And it’s funny though, because we still tend to, with, as an industry, think of ourselves very much as individuals. And sometimes be kind of resistant to high degrees of, of collaboration.

[00:16:32] Zoe Cunningham: So let’s talk a little bit about the history as well. So there, there have been over, over this period, that it sounds like you, you and I have been around a similar amount of time, you know, building systems and seeing new concepts arrive and then sometimes also depart.

[00:16:50] How influential have things like agile programming and extreme programming been on this concept of ensemble working?

[00:17:01] Clare Sudbery: Yeah, I mean it’s… I mean, people can talk about the history of agile, the current state of agile endlessly, and to a lesser degree extreme programming. So extreme programming is less well known and therefore has become less polluted.

[00:17:19] Maybe, not a great word, but agile has been around for so long and has been visible for so long and known about for so long that it’s had a lot more, opportunity to just become a thing that people are, oh God, really? And it has become a thing that people kind of pay lip service to without really, really getting the benefit from it that they could be.

[00:17:51] And Agile is more than 20 years old. Extreme programming is more than 20 years old, and yet there aren’t many people who are really making the most of agile. And there are even fewer people who are really making the most of extreme programming. And I should explain what extreme programming is ’cause people won’t necessarily know.

[00:18:10] It often gets shortened to xp. the X having been pulled out of the middle of the word extreme, there are actually 13 tenets. I’m not gonna go into all of them. I think it’s 13. But the practices that people will be most aware of are test driven development, pair programming, continuous integration. And there’s something else as well, which has gone out.

[00:18:31] Oh, refactoring. Yeah. So those are the four things that people will be most aware of. And those are four things that I am particularly excited about and spend a lot of time on. And then pair programming has now kind of extended into ensemble programming or mob programming or software teaming.

[00:18:48] And it sits within the idea of agile. So extreme programming is also very much about frequent iterations, fast feedback loops, making sure that you’re trying to break everything down into really small steps and constantly reviewing what you are doing, assuming that everything will change. All the time.

[00:19:08] And nothing is gonna stay the same. So you wanna avoid, too much upfront work. you don’t, you, you don’t want to be, using waterfall practices where you decide what you’re gonna do and then six months later you do it. You wanna decide the smallest possible thing, do it really quickly, get feedback, and then find out what you discover and decide what the next step might be.

[00:19:31] Interestingly, agile did not have anything to say about pair programming. Pair programming came out of extreme programming, but extreme programming and agile were very close to each other and absolutely feeding into each other constantly. And then ensemble programming came out of pair programming and Woody Zuill who first came up with the idea of mob programming was, very much, you know also working within agile practices. So also looking at short feedback loops, iterative programming, tiny steps, breaking everything down, assuming that there will always be change.

[00:20:07] And that’s really, that’s all that agile means. I like to think of the actual word, agile. Agile means being able to move quickly and change direction.

[00:20:15] That’s agility. That’s, that’s really all it is: assume that things will change and that you’re gonna have to change direction and therefore anticipate that and move in tiny steps because the smaller the steps, the more agile you are. Yeah. And really that’s that. It’s as simple as that.

[00:20:32] What ensemble programming gives you is the ability to have those fast feedback loops propagate much more quickly. Because everybody sees when things change because everybody’s in the room. So the thing about working individually is that even if you have daily standups, so the time between communication is only 24 hours, that’s still 24 hours of doing things on your own.

[00:21:00] And during those 24 hours, a lot can change and a lot can go wrong. And if you think I’m on my own, then you are not gonna tell people when things go wrong. And actually you are gonna… there’s gonna be a tendency to want to hide it because there’s gonna be a tendency to think, oh, no. That was my fault.

[00:21:22] Zoe Cunningham: Right?

[00:21:23] Clare Sudbery: Yeah. And, and, and people are gonna find out how useless I am and, and they’re gonna tell me off or they’re gonna judge me, which is why also no blame culture is a really important part of agile and xp.

[00:21:34] But if you are all in the same room at the same time working on the same thing, then you all find out when things change. You know, straight away. And you all know the tiny little details of, of the little thing that needed changing.

[00:21:51] And another really powerful part of it is it’s not just software engineers who are part of an ensemble. Typically, people who are not deeply hands-on technical might come and go. So they might not be there all the time, but you can bring in your testers, you can bring in your product owner, you can bring in, any kind of management levels that you have. And I’m not even gonna say roles because role names change so much between different organisations. But you can bring in people who have an interest, and an input into what’s happening.

[00:22:26] And you can have the conversations with them live rather than. Going off and having a meeting and then coming back and then having to share what’s been decided in the meeting. All of it is all happening with everybody all at the same time. And in terms of agility, in terms of of xp, that’s amazing because you can iterate really quickly. You can get very first feedback, and you can propagate the knowledge very effectively.

[00:22:56] Zoe Cunningham: Could you run us through maybe just a kind of example of how you might run it? Is it four people in a room together? All day, every day. And if so, how would the roles break down? Or is it more flexible than that in terms of what we’re talking about here?

[00:23:14] Clare Sudbery: It absolutely depends. So there are companies, there aren’t very many, but there are companies who do it all day, every day. The best example that I’m aware of is Hunter Technologies, which funnily enough is the company that Woody Zuill was working for, when he first came up with the idea.

[00:23:32] He doesn’t work there anymore, but he has left that legacy behind. And they still, a long time later, at least 10 years later, still work as a whole company using ensemble work or software teaming as their main practice. So actually describing how it is for them is, is a good place to, to start.

[00:23:52] And I know because I got to visit and they do encourage people to go and visit. I’m in the UK and they’re in America, so I didn’t physically visit, but they work mostly online anyway, so I spent a day with one of their teams observing and joining in. One of the great things about this is that people can join in.

[00:24:11] So, and honestly, this is interesting, I’ve seen so many people do it, I can’t remember the mechanics of how they do it, but I can tell you how I do it when I’m introducing it to teams is that we take it in turns with a timer. And exactly how long that timer lasts is gonna depend. Exactly how you decide who goes next is also going to depend. But typically that timer is going off between three and 10 minutes. Every three to 10 minutes. Could be as long as 15 minutes. It really… different teams will build up their own rhythms, and that’s really important that it is bespoke. You do what works for you.

[00:24:51] Zoe Cunningham: Yeah.

[00:24:51] Clare Sudbery: You don’t follow a template. There isn’t, there isn’t a, a rule that you have to do it like this. It’s very important that people constantly review. So I think at Hunter they have daily retros. It might be weekly, but I think they do have a little thing at the end of every day. Certainly when you are introducing it to a new team, you want to do it daily.

[00:25:11] At the end of every day, you’re like, how did that go? What worked? What didn’t work? What was great? And we wanna do even more of it. ‘Dial up the good’ is one of Woody’s great sayings and let’s try doing it differently tomorrow. We didn’t like three minute intervals so they were too short. Let’s try five tomorrow.

[00:25:27] And then, or maybe we try tens more and then we’d say, no, actually ten’s too many. Or it’s still not enough, let’s try 15. Depending how much trust there is, you’ll be able to have longer time periods. You need to really, really know that nobody is feeling left out and nobody is feeling insecure because, for instance, if you have a 15 minute time chunk and there are four people that’s 45 minutes out of every hour that somebody is potentially not engaged and also worrying that they’re not quite sure what’s going on. So it’s very important to, to really believe that everybody is, is on board. Nobody’s feeling left out and nobody’s feeling insecure.

[00:26:10] So being kind to each other is another one of Woody’s absolutely top rules. And I, I would say if there was any casting die, like absolutely you have to do this, being kind to each other very, very important, paying attention to how people are feeling, how they’re doing.

[00:26:25] Zoe Cunningham: Mm-hmm.

[00:26:26] Clare Sudbery: So you take it in turns on a timer. And again, you can do it in different ways, but a really common way of doing it is that every time the timer switches over, you just have a list that you go cycle through. So it’s always the same order.

[00:26:39] One person is the typist and one person is the the speaker. And again, people use different terms to describe ’em. I like to say typist and speaker. ’cause that’s unambiguous. Yeah. So one person is typing one person. When you use things like driver and navigator, you have to understand something about how racing cars work and like, it’s not obvious.

[00:26:59] So speaker and typist. So the speak and… and not everybody does it that way, but it’s a nice way of doing it because, and it’s, it’s also useful for pair programming because if the typist is not the speaker, then that means that the speaker has to be very clear about what they want to do next. Like, and it can literally be right this line of code.

[00:27:22] Again, one of the techniques you quickly learn is you don’t want to say, write this character now, write this character. Now write a semicolon, because that’s very difficult for people to follow. Other people get disengaged very quickly. So you, you wanna be able to have a natural way of describing what you’re doing, at which you become more or less detailed, depending on how easily the communication is happening.

[00:27:45] If the person who’s speaking is not the person who’s typing, then they have to be very clear about what they’re doing and why. And if the typist is not the person making the decisions, then you don’t have that thing of somebody just going, oh, and, and it’s all happening in their head, and it’s going whooshing by on the screen.

[00:28:04] And everybody else is like, what?! Whatcha doing? Why are you doing it? Because you want everybody to be involved. And there are also different processes for allowing the two people who are not in those two roles to also be active. And again really depends, how active they’re going to be. But it’s very important that everybody’s engaged, that everybody understands what’s going on.

[00:28:26] But because you have such a fast turnover, it means that what’s happening is in everybody’s head, everybody knows what’s happening. So somebody can nip out to make a phone call. Somebody can go and get something to eat, somebody can go to the toilet, it’s fine. It doesn’t matter because they’ll pick it up again when they come back into the room. Somebody can go away for a week or a day or whatever, or half a day, they’ll pick it back up again when they come back into the room.

[00:28:52] And it, it means that it’s not just stuck in that one person’s head. So the, the slightly unpleasant term ‘bus factor’, you know, what would happen if somebody got run over by a bus? It’s much less impact.

[00:29:04] But also what will happen is, that every now and then they will come up against something. They’ll be like, oh, actually, is this what we’re supposed to be doing? Is this what the users want? Is this what the product owner wants? Did we understand the requirements? What if it might need to change slightly because of this? You don’t need to wait for a meeting. You can just call the product owner in. Call the tester in, call the relevant party in, call somebody from another team in. That was something I noticed a lot at Hunter. There was a lot of movement between teams, like bring somebody else from another team into our ensemble because they’re not crucial to their ensemble, so they can come into our ensemble and they can answer our questions about how we’re going to integrate with their thing.

[00:29:50] It definitely sounds like surely it’s inefficient. Surely five people being paid five wages and only doing one thing. How could that possibly be efficient and effective? But it is because people underestimate how costly it is to have handoffs. How costly it is to have tons of meetings, how costly it is for there to be a delay between making a decision and acting on that decision, how costly it is to have communication gaps between different people and between different teams.

[00:30:27] And what this does is massively reduces that friction. Now most people don’t do that. Most people don’t do it all day, every day. And even the people that do it all day, every day, people will still go off and do individual tasks. So people will leave the, the ensemble to go do their time sheets or, yeah.

[00:30:44] Or to answer their emails or, or, or, you know, it, it, it, so people do still do individual work and some people, rather than do it all day, every day, in fact, it’s much more common for people to use it in specific circumstances. Mm-hmm. And the two most obvious ones that are people are most likely to use it for are onboarding and training.

[00:31:08] So if you have a new member joining your team, it’s really effective to get the whole team. And this applies to pairing as well, so people don’t use u pairing ubiquitously, but they’re much more likely to use it for onboarding and training. So ensemble is just an even bigger version of that. And more effective in my view.

[00:31:26] But if you’ve got a new person joining the team, then you all work together on a feature for a period of time. Maybe only an hour, maybe half a day, maybe a day, maybe a week, but with gaps and breaks and… . But, but it means that new person gets to know everybody, gets to know what everybody knows and everybody gets to introduce them to the code base all at once or what, you know, not everybody works with code bases, but whatever it is that you’re working with,

[00:31:52] Zoe Cunningham: Right.

[00:31:53] Clare Sudbery: So onboarding great context for, for ensemble working.

[00:31:58] Training, also, if you, if a team is being introduced to a new tool or a new technology, if you’ve decided you’re gonna switch to a different language or you’re gonna start using a new thing, do it all at the same time. Get together in a room and learn together, it’s really effective.

[00:32:13] You might work through official training resources or you might not. You might just say, listen, let’s build a thing using this new technology, and together we’ll work out how it works. Typically, in that kind of scenario, there’s somebody to one side Googling stuff and you might take it into or looking stuff up, which actually happens in, in any ensemble.

[00:32:31] There’ll be somebody who’s like, oh, we, we are not quite sure about this. Don’t worry, I’ll go and Google it while you, you like, carry on. Then I’ll come back and tell you what I’ve learned. Or you’ll all Google it together. You know, you’ve all got a screen in front of you. So it, it again, massively depends, depends, depends, depends. It would be different in so many different circumstances.

[00:32:49] But onboarding, training, two really good ones. And then the other one is starting a new feature. So quite often people won’t normally work as an ensemble, but when they’re starting a new feature, they’ll all get together so that they can all see what’s going on all at the same time, and they can have those conversations all together instead of wasting time in, in meetings and huddles, and all the rest of it.

[00:33:11] And typically ensemble, people who do it all the time, they don’t have meetings as such because it’s all a meeting.

[00:33:17] Zoe Cunningham: Right, exactly. Yeah, yeah, yeah.

[00:33:18] Clare Sudbery: You know, so they don’t have to have planning meetings and, and backlog refinement and all of that stuff. ‘Cause they’re all there at the same time and it means they’re doing things just in time.

[00:33:28] And that, the thing that I’ve always hated about backlog refinement and planning meetings, it’s that even if it’s weekly, and typically it’s more like fortnightly, you’ve got two hours in a room and you’re just like being bombarded with one feature after another, after another, and you’re trying to like make sense of all of it all at once.

[00:33:45] And then it could be two weeks before you work on it, by which time you’ve forgotten what happened in that meeting anyway, so yeah.

[00:33:53] Zoe Cunningham: Oh, Clare, thank you so much. It’s been such a whistle stop tour and your enthusiasm for the topic is so infectious, and I think that, the way you’ve highlighted how it’s not one thing that’s done.

[00:34:09] It’s not a set of rules, and it’s not about following a set of rules. It’s about finding out what works and what works for your team, which is not what works for you as an individual. It’s what, what works in these complex interactions that we all have, we all have to have to make, like you say, large pieces of software together.

[00:34:29] And I just think it’s so… I am excited and I hope that everyone else is excited about the potential to go and play and have fun and see what, what they can do on their teams. And there is a great, anyone who’s listening to this on release date, there’s a great opportunity to go and see Clare in Manchester at the Outpace conference.

[00:34:54] And is there other places where people can, you know, other resources you have, they can go and learn from?

[00:35:00] Clare Sudbery: Oh, like so many lots of videos online of me doing talks, on this topic and, and other related talks that we’ve talked about today. In November in Amsterdam, I’m going to be running a two day workshop on test driven development and ai.

[00:35:15] So how to do a real deep dive into how to make the most of a agentic coding, by using test driven development and other techniques to make sure that the code that’s developed is robust. And I’m also, that same week in Amsterdam, also for Trifork Academy, doing a one day workshop on how to handle the technical in technical leadership.

[00:35:39] Zoe Cunningham: Oh, amazing.

[00:35:39] Clare Sudbery: And if you’re, just look me up online, everything’s linked to everything. You’ll be able to find this stuff.

[00:35:44] Zoe Cunningham: Oh, fantastic. Thank you so much, Clare.

[00:35:47] Clare Sudbery: Pleasure.

[00:35:48] Zoe Cunningham: This Digital Lighthouse episode was edited by Steve Folland and produced by Patrick Anderson. The theme music was written and recorded by Ben Baylow.

[00:35:56] A huge thanks to our sponsor Softwire for their continuing support from the inception of the show in 2019 to the present. If you love the podcast, please let us know with a rating and a review on your platform of choice. We are always looking for feedback to ensure we’re making the best show possible.

[00:36:12] And if you’d like to take part, please drop us a line at [email protected]. You can catch Clare in person this October at Outpace Conference, an affordable one day conference for senior technologists by senior technologists. Clare will be diving deep into everything we’ve covered today, ensemble working, to help deliver high quality software products and will be joined by over 12 speakers sharing stories around the big thorny challenges that we’re all facing today.

[00:36:44] You’ve been listening to The Digital Lighthouse with me Zoe Cunningham. Thank you for sharing your time with us and stay safe on this wild technological ride that we are all on.