Interview: Technical Agile Coaching using Samman Method with Emily Bache & Sofus Albertsen

Emily (00:04):

I've been doing surveys, and I can definitely see changes in attitude, and I can see that people are more inclined to write tests and they're more inclined to do refactoring or work in smaller steps, that they agree that these are good goals to have. That's after very little coaching, actually. Changes in attitude, you can definitely see.

Lauri (00:24):

Hi. I'm Lauri, and you are listening to DevOps Sauna podcast from Eficode. This time, we are joined by Emily Bache, a technical agile coach and an author, and Sofus Albertsen, DevOps consultant and the Eficode Academy headmaster. Emily has recently published a new book called Technical Agile Coaching with the Samman Method. She has earlier published another book, The Coding Dojo Handbook. Let's tune in to listen in on the conversation on the themes and topics of the book between Sofus and Emily.

Sofus (01:03):

Hi, Emily, and welcome to the podcast, and thank you so much for joining.

Emily (01:06):

Hello, Sofus. Thank you so much for inviting me.

Sofus (01:09):

You and I have been remote colleagues in a prior company before, and one of the things that especially has blown me away by the ways that you do things is that you take needs from the customer and then you make it very applicable to them. So, you gamify or you make scenarios where it becomes tangible for them, some things that are sometimes very intangible. One of the best examples of one of the things that are really close to my heart is the pipeline game that you created, which, in simple terms, is a small game that helps technical or nontechnical people reach a deeper understanding on the process of making a pipeline, making a build pipeline, and giving them a way to discuss this without the nitty gritty details of around how Maven works, or how Gradle works, or how to do this and that in the language that they are using, but still in the overall idea, so how do we deliver our software, how do we build it?

Sofus (02:07):

So thank you so much for that one.

Emily (02:09):

Yeah, I mean, I really enjoy making little games and exercises, it's one of the things I find really amusing, just to try and come up with these things, so I'm really happy that the pipeline game has been so successful and is still being used. It's a few years since I did it, and you were one of the people who play tested it, I remember.

Sofus (02:26):

Yes.

Emily (02:27):

Way back.

Sofus (02:30):

Yeah. And I used it a lot by going out and being a consultant, especially because it connects the technical and non-technical people, and I have a small surprise that the physical game has now gotten a digital twin on pipelinegame.eficode.com. So ...

Emily (02:46):

Oh, cool.

Sofus (02:46):

Now, in the COVID-19 situation, we can all actually play it still. Yeah. It's pretty exciting. I just had a premiere with it a couple of days ago, and it went fairly well from a first trial to good. It's all free and online and it's open source as well.

Emily (03:03):

Oh, great. I really need to have a look at that. I think that could be pretty useful. I mean, I've been playing it with the decks with some of my customers since then, but I haven't been able to use it since the pandemic, so that sounds really good.

Sofus (03:16):

It's COVID safe to use, at least.

Emily (03:19):

Yeah.

Sofus (03:20):

So the reason why you are in this podcast is because you've written a book. Can you tell me briefly about the name and the title of the book, but also what it is for people who don't know your competences and experiences?

Emily (03:36):

Right. So I've got a copy of it here, it's called Technical Agile Coaching with the Samman Method, and I wrote it to talk about the way I work, really, and try and encourage other people to improve the way they do technical coaching. Now, when I say technical coaching, I mean, kind of ... I mean all of the stuff that you need to do around the code and the pipeline and getting the software developers to work in an agile way with tight feedback loops, in a way that's going to enable the whole company to be more agile, and to deliver better software sooner, faster, all of that.

Emily (04:12):

So the technical coaching that I've been doing is, I've been doing it for a few years now, it's quite a specific style and I just really wanted to write that down as something concrete that people could do to do technical coaching.

Sofus (04:24):

Yeah. And the reason why you called it Samman Method? Is that ... I know you're living in Sweden, even though you can't hear the Swedish accent.

Emily (04:32):

Yes. Yes. I've been living in Sweden for over 20 years now, but I'm from the UK. But yes, so "samman" is a Swedish word and it means together, basically, and I wanted to give the method a name so that people would be able to search for it on the internet and so on, and a big part of it is this ensemble working, which is where you get the whole team together working together as a team, and ensemble is a French word that means together, so I thought, "Well, let's take the Swedish word that is kind of equivalent." So that's why I chose that word, because it's all about working with the whole team together to improve the way they work.

Sofus (05:09):

So in the book, you have two pillars that are the most important, or, correct me if I have misread it, but you have the learning hours and then you have the ensemble work, so one of them is gaining new features and the other one is the mob programming or ensemble working, as you were saying.

Sofus (05:28):

What are those two types of learning and why are they so important? Why are they the pillars that you've chosen for your method?

Emily (05:34):

So I've been involved with coding dojos and code katas and doing exercises to learn programming techniques. I've been doing that for a long time, I mean, that's what my first book was about, The Coding Dojo Handbook, about how you can use exercises in a group to learn these skills, and that's still a really useful thing to do, if you're going to learn technical practices like tests during development, and refactoring, and working in small steps iteratively, it helps to have really easy pieces of code to work on, to practice on, code katas.

Emily (06:08):

So the learning hour is basically the latest evolution of that, it's ... But with the learning hour, as you can hear from the name, it's only an hour. Coding dojos are generally a little longer, but I find doing it shorter and more often is more effective, and also really thinking about the structure of that learning hour and using active learning measures. So I've been taking a lot of inspiration from this book, Training from the Back of the Room, and ways to engage people and get them really to learn effectively.

Emily (06:40):

So the learning hour is really, like it's a lesson that I prepare, and the ensemble working, that is where you get the whole team together and we actually do some work in their production code, on some task that's typical for that team. And the reason I added that basically on top of the coding dojo thing is that I found that there was this gap. People would get good at doing code katas, and then realize that they could do TDD if it was an easy problem, but their production code was not an easy problem, you know?

Sofus (07:11):

It never really is.

Emily (07:13):

No. It's a bit of a gap between the exercise and the production code, so this is a way to try and bridge that, to have the coach sitting with the team in their normal daily code base, working on something that's familiar to them and trying to say, "Okay, well, given this is a task we're trying to do, how do we apply TDD in this situation? How do we do refactoring safely here?" All of these agile techniques, how can we apply them? And with the coach next to them and helping them, the team can succeed where they perhaps would have if they'd been left to their own devices.

Sofus (07:46):

So is it really that if you take pair programming, for example, the thing that misses in that context is the facilitator, like you say, but also that you are more people, so sharing the knowledge? Or how do they compare towards each other, pair programming and mob programming, or ensemble working, as you call it?

Emily (08:02):

Yeah. I mean, you're quite right. Pair programming, it's the natural ... It's a natural evolution of when you have more than two people, it turns into a mob or an ensemble, and a lot of the skills is the same. And you don't technically need to have a coach or a facilitator for an ensemble either, but I would recommend it when you are first trying it out, honestly, because with two people, you can be very fluid and it can just be quite natural and who's taking control and who's speaking, but when you get more people, particularly if it starts being six, seven, eight, nine people, which you can have in an ensemble, you need a few more kind of rules and a bit more structure, and it helps if somebody is explicitly, "Yeah, I'm facilitating. I'm going to stop everyone talking at once."

Emily (08:47):

And you get these additional roles as well, so that you divide up the time so that you still have one person on the keyboard, just like in pair programming, somebody's actually typing, and I would call them the typist, and then you've got the navigator role, because the typist is not supposed to decide what to type. That's got to be a whole ... Kind of the whole team needs to contribute to that decision about what to type into the computer, and the navigator is like the spokesperson who is actually speaking instructions to the typist about, "Please write this code. Please design it like this." Or the navigator says, "I don't know what to do now, somebody help me." And then somebody else in the ensemble will step in and perhaps just give them a bit of advice and then step back, or perhaps take over as navigator, if they've got an idea about what to do.

Sofus (09:39):

So the ensemble work is not only a bunch of people sitting together, there are actually some specified rules beforehand and roles to make sure that it's efficient, that you actually gain the knowledge that you need, right?

Emily (09:51):

Yeah, I mean, I think, I'm sure people do just get together and kind of hack in a group and call it ensemble working or mob programming, but in my experience, it can be so much better if you've got a few ground rules and roles. Yeah.

Sofus (10:04):

In my professional experience, when I talk to people about pair programming and mob programming, they all tend to say, "Yeah, yeah, it's good, I've tried it before, but I'm not really using it in my current job." And they have many different reasons why not to take these measures in. Typically, they say the performance is not the same as individual contributions, so, again, if you are pair programming, then you are only gaining one of the person's productivity during that time, and I mean, with ensemble working, you get an eighth or whatever it is of productivity, or the other one saying, "Oh, but I'm uncomfortable sitting together with somebody else. I mean, they're nagging me, or the other way around. I don't like the way that they coach, so we argue too much." And all of that.

Sofus (10:49):

What's your thoughts around that? How can you break the ice? Because this is also a lot about ... It's not only about programming, it's also about human interaction, right?

Emily (10:58):

Yeah. Absolutely. And, I mean, I've heard those kind of things too, I agree. So there's quite a big question there. Firstly I want to point out, in the Samman Method, I'm using the ensemble working very specifically to train techniques, to transfer knowledge, basically, from me to the team. We only do it in 2-hour sessions. So if you're really, really concerned about productivity, the team has the rest of the day, basically, to go and do the work individually and carry on. I'm only asking them to do this two hours of ensemble working each coaching day, and the learning hour, of course. And you can kind of slip that in with the managers as just, "This is training." They don't have to worry about the losing productivity, but ensemble working is such a bigger technique, you can do this all day every day, and some teams do, and they find it productive and that can be more difficult for people to believe.

Emily (11:53):

But I would, just point out, if you have everyone working individual, you're kind of assuming that the individual has all the knowledge that they need to complete their task in their own head, and they don't need to ask for any help because they can do it all, and that assumption, for modern software development, when we live in such a complex world of so many tools and frameworks, what are the odds that one person knows all the tools and all the things they need to write all the software themselves without asking anyone else?

Emily (12:26):

I mean, and the size of the problem that you're asking them to solve, today's problems in software development, aren't they bigger than what one person can solve alone? Maybe the whole problem with productivity in software is that we're trying to get one person to solve a problem that needs seven people to solve, because that's what software development is, it's constantly solving problems.

Emily (12:47):

So that's basically what I ... The argument I make about productivity is software development's learning, solving problems, it could be easier in a bigger group, it could go faster.

Sofus (13:00):

I think you have a very valid point there, saying that we try to do, as software developers, are not doing things that are known, just like building a bridge or making a house. We do it with unknown materials, we do it with unknown end-goal, with changing requirements, and for one person to be able to grasp all of that every single day, every single time they are productive, it's a huge thing, at least, to say that we can do that, and I think that very, very few people have that ability. And for the mere mortals, the rest of us, we could use some help from our friends.

Emily (13:35):

Yeah. It's kind of like we're going to go well, we're going to go well together. And the other point you made about people not wanting to sit with that person because they don't like them, or it's socially awkward, or ... I think team work is really important in software, that's what ... All the best software is built by teams these days, so there is definitely a point where you have to learn to work with other people.

Emily (13:58):

This ensemble working, I've found that, because it's got these clear roles and clear rotation, I know what role I'm in, I know the kind of things I'm supposed to say when I'm in this role, it's socially, even for people who are a little socially awkward, or shy, it's kind of freeing. You know what you're supposed to say and do, and my experience is that people actually take to it, and when they don't even expect to, you know?

Sofus (14:26):

Because they have rules in the roles that they are having, they know what to do, they know their part in the play? Yeah, sounds about right. But still, if I may play the devil's advocate one more time, you have an example in your book around one person being the boss factor, or the key person to do Kubernetes roll outs, or whatever it is, it doesn't need to be anything fancy. But the person with the knowledge, the one with the keys to the castle, and by having that, you are being very vulnerable as a team, and as a company. If that person either finds another job or doesn't want to do that anymore, then you, all of a sudden lose the ability to maybe release your software, which is, I mean, very, very important for you.

Sofus (15:11):

So there you argue that you have the mob that can actually go in and distribute the knowledge, so now you're not having one person but you have the entire team that are able to deploy or configure, or whatever it is. But does that mean that with this method, with the Samman Method, that everybody should know everything? Or is there a fine line between having one person and having an entire team knowing everything, because if we go back again to say that we don't think that the individual person can know everything, then is this not implicitly requiring them to know everything if they are introduced to all the bits and pieces of the entire process?

Emily (15:52):

Right. So, yeah, are we just exchanging one problem for another? One of the goals of the ensemble is that everyone should be able to work with the code that's written together, so that after the ensemble, everyone feels that they kind of, in some way, own the code that was written and understand it, and could go forward with it. But it's not necessarily the case that everyone in the ensemble could have written that code themselves.

Emily (16:16):

So if you've got the expert in the ensemble who knows all about Kubernetes or whatever it is, the technical details, and they have navigated the code that was written in that area, somebody else has been the typist and typed that in, and everyone else has watched and seen the code being written, and they've heard the explanation, and they got to ask questions, but that doesn't mean that they're as expert as that person, but they could probably at least maintain that code, even if they couldn't produce new code like it. So, but over time, if they did enough, then, yeah, they would turn into experts eventually, I'd imagine.

Emily (16:53):

So I don't think I'm claiming that suddenly the whole ensemble becomes the experts, it's just the expertise will flow into the group, but it's not going to be immediate. Hopefully you'll be in a better position than if that person was coding by themselves.

Sofus (17:08):

I think that's the key point here, being in a better position, because if you are suddenly seeing something for the first time and your deployment failed and you need to change it right away, then you first need to be acquainted with it, make the exploratory kind of look and feel, and then afterwards, if you don't know anything about Kubernetes, then you need to go in and Google or YouTube something and, I mean, it's going to take you so much time to be just a teeny, tiny bit pro-efficient in this, in order for you to change something that will help you. Where, if you have seen it a couple of times before, you know the vocabulary, you know the terminology, maybe you haven't set up a Kubernetes cluster, well, okay, fine by me if you haven't done that, but you know some of the things, so you are better off helping out than you were if you have never heard about it before.

Emily (17:57):

Yeah.

Sofus (17:58):

So that's the first pillar, or that's one of the pillars, the ensemble, but you also have the learning hours, and as you talked about before, it's not just having one hour to watch YouTube videos and then you are done with it, there are some more things about it, right? Just like that we're not just a group of people doing whatever we want and then calling it ensemble work, then we're not just having an hour for ourselves to go and read whatever we want.

Sofus (18:21):

So could you tell me a little bit more about the learning hours?

Emily (18:24):

It's like a short lesson that I've prepared as the coach on a topic that I think is relevant for the team. So it's carefully chosen to be something that's relevant, and the training from the back of the room technique is, I've got the book here as well, actually, it's a book by Sharon Bowman and she's written several books about active learning techniques, and she's not a software developer at all, but she knows how people learn and she's got this model with 4Cs, to try ... And the learning hours are structured according to this model, because before someone's prepared to learn a new thing, you have to connect, they have to connect with what they already know about that thing. So that's the first C.

Emily (19:09):

You have to connect with ... I already know something about this topic, I'm going to connect with the people around me in the same learning experience, because we're going to learn together, part of learning is social, and then, so when we're in a good state, receptive to learning a new thing, the next one of the Cs is concept, and that's where I have to introduce a new idea for the team. And I could do that by just standing there and talking about it, or showing some slides, or showing a demo or something, that would be one way of doing it, or I could try and get them to find out about the concept by getting them to go and do some searching around or looking at stuff that they already know, or examining some materials, and interacting with the thing they're trying to learn about.

Emily (19:53):

And then the third C is concrete, and that's where you actually get them to try and use the new knowledge in a concrete exercise, and that's usually the, in the learning hour, that's the longest part, we spend probably half an hour or something writing some code on a little code kata exercise, and trying out the new technique.

Emily (20:14):

And then the last C is conclusions. If people are going to remember what they learned, I mean, all of these ways of getting people to remember things, making it tactile, making it spacial, making it visual audio, you've got to try and reinforce it in many ways. So the conclusions is a way, you might get them write down what they learnt, or you might get them to speak to someone and tell them what they learnt, or you might just get them to review what they did earlier and mark it and come up with their own exam questions and give them to one another, so that's kind of all about trying to get them to remember what it is they learnt.

Lauri (20:52):

Hi! It's Lauri again. We want to offer you the opportunity to learn from Emily. This is why we are handing out a few copies of her book to our listeners. All you have to do is send an email to marketing@eficode.com.  We'll send books on a first-come, first served basis. Anyway, you always have a better chance when you participate. As they say: you have to be in it to win it! Now, let's get back to the show.

Sofus (21:22):

So revisiting the same topic over and over again to reinstate and reinforce the learning experience here, with different kinds of methods, with video, audio, and, as you said, tactile, trying it out on a dojo.

Emily (21:36):

Yeah, so the 4C method is really trying to play with the strengths of our brains. People love to learn, actually. People like spotting patterns. People enjoy feeling that they're more competent today than they were yesterday, and you're just trying to tap into that, to make the learning fun, and sticky.

Sofus (21:56):

Sweet. So there is this book that you mentioned, but is there other places where you can you say, "Well, I want to be better at conducting these training materials."? Where do you want to highlight for people? Where can they go?

Emily (22:08):

Right. Thank you. I would like to advertise my website, Sammancoaching.org. So Sharon Bowman, as I said, she's not a software developer. She's got all these ideas about how to structure learning, but on Sammancoaching.org, you can find some prepared learning hours with this structure, and you can find activities and quizzes and things that you can do that are about software that link into this way of learning. And, of course, in the book, there's ... I've got 10 learning hours in the book written out fully, and on the website, I kind of maintain them and add more stuff, and it's all released on Creative Commons, you just have to credit me if you use it.

Sofus (22:47):

Sweet. Nice. It's always good to have good resources for this. I mean, we create a lot of training ourselves here in Eficode, and it's what makes a good training course is when people get it in their hands and can feel it and can try it out and can fail and learn from that as well, finding out, "Okay, this was not the way that I should use Docker, okay, then if I try this instead, how can I do that? How can I tackle this problem?" As an example.

Emily (23:15):

Yeah. Yeah.

Sofus (23:16):

But with all good training, and with all good learning, for me, at least, you can find ... There's so much difference between coming into a group that is well oiled, that is a good cohesion with them, that have good communication, trying to convey knowledge to them is just butter-smooth, it works so well, it's fantastic, but if you come into a group where you can see there are internal struggles, there are people that are afraid to speak up, there are shadow leaders and real leaders that don't really position themselves as they should, then it becomes almost impossible to do these kind of thing, because everybody is so occupied by all the other things that are in the room rather than the training itself.

Sofus (24:06):

So is psychological safety and a good working environment, is that a pre-condition for the Samman coaching or can this also be a tool to improve the psychological safety, as a by-product of the coaching, because you are a facilitator there?

Emily (24:22):

I mean, you make a really good point, Sofus, I'm sure that you've seen this, and I recognize what you're saying that, yeah, absolutely, some teams, you walk in and you start working with them and you realize, "Oh, this is fun, they like each other. This is ... They're actually cracking jokes and the work is proceeding smoothly." And other teams, you're like the work is not proceeding smoothly, and that's because there's underlying conflicts here, or they just don't like each other.

Emily (24:48):

So that's challenging, I agree with you. I've definitely seen that, and the thing with ensemble working is I'm there as a facilitator and sometimes the focus, my focus is taken up hugely by just trying to get the group to work, just trying to get people to not say the wrong thing at the wrong time or talk badly and dis one another and say, "Shut up, I'm navigating." Things like that. You want to try and get them to work together well before you can really start teaching them the rest of this stuff.

Emily (25:25):

So, yeah. I see ensemble working as, as a facilitator I can start to do some things about that, but, I mean, I'm not really an expert, so that's one of the things I'm looking to maybe improve about the Samman Method is how can I make it even more effective by working together with team facilitators or agile coaches or people who really understand the people dynamics, and are good at creating that kind of psychological safety. So I wouldn't call myself a real expert there, I just ... I really know when it's working well, it works well, and when it's not, it's hard.

Sofus (25:57):

And sometimes you just need a true expert in psychology to crack some of these things open. In my experience, at least, with the technical agile coaching that you introduced as well, and other people have taken up and continued, is that if you don't have a truly toxic environment, but just not a well-oiled communication platform, then doing these things will improve the communication, will improve the overall happiness of people, because they are talking together, and all of a sudden they are not making the same mistakes as they did before, they're not making the same communication errors as they did before, because they have now gotten used to, actually, talking together, also around the technical parts, and it's not as scary anymore to say, "I'm uncertain about this problem. I'm uncertain about the new feature that I am going to implement. Could you please have a look at it together with me?" So the barrier to help becomes quite a bit lower.

Emily (26:57):

I'm really happy to hear you've experienced that, yes. I've also seen that, yeah, with teams, it's one of the things that teams report, actually, and I do a survey after the coaching and they report that, "Yes, I think our team work is better now." At least most of the teams, yeah, but some of them were really, really hard.

Sofus (27:12):

Again, we can't fix everything.

Emily (27:13):

Yeah.

Sofus (27:14):

But as you said with the surveys that you're trying to measure this, which is ... We are, at least with the introduction of the Accelerate book with Nicole Forsgren and the rest of the team, we now see statistical scientific surveys that prove that, for example, having the dev ops practices coming into your company will improve your bottom line. I'm quite sure that they phrase it in a quite bit different way, but that's at least what I take out of it.

Sofus (27:43):

So how can we ... Do you have anything like that? Do you have scientific studies that will show that the Samman Method will make your company more profitable, or at least how do you see that this actually works? How do you prove this to a potential new customer?

Emily (27:58):

I wish I had the thing that would say, "Yes, Samman Coaching will improve your bottom line. You will make money." No, I don't have that, I'm afraid. I'm also really excited about the Accelerate research and the way they've managed to link all these technical practices to actual real world, bottom line outcomes, because I think that's really encouraging. And test driven development is one of the things that they point to as driving success with continuous delivery, which drives success with the business and reduces burnouts and stuff like that.

Emily (28:30):

So TDD is definitely in there in that research, but what with the Samman Method, I want to ... What I'd like to have is some kind of research that shows that the teams that go through it, end up being better at TDD afterwards, and I have to say, I haven't really done very much of that so far. I mean, I've been doing surveys, and I can definitely see changes in attitude, and I can see that people are more inclined to write tests and they're more inclined to do refactoring or work in smaller steps, that they agree that these are good goals to have, and that's after very little coaching, actually, people ... A change in the attitude, you can definitely see. But I think it does take a while for people's actual behaviors and ways of working to change to the point where it's observable in terms of metrics like lead times, or quality and bug counts, and so on. Those effects take longer to filter through, and I haven't been measuring stuff long enough to have those kind of numbers yet. But I hope that some day, this will be there.

Emily (29:32):

At the moment, it's just anecdotes, it's like I know teams who, after some coaching, have really embraced TDD and I've seen that it can have big effects, but I haven't got any measurements.

Sofus (29:44):

But the agile manifesto was also just hunches and stomach feelings from very experienced people, so, I mean, and that revolutionized our business quite a bit, so that is definitely something. And as you say as well, I mean, these looks like, or it sounds like that the Samman Coaching is also going to touch about the culture of the company, or at least the team that you're working with, and culture is always super hard to change. I mean, what is it, Peter Drucker, that had the quote, "Culture eats strategy for breakfast." So I think some of the same things applies here, right, that it is hard to change the culture, and you are trying to change the culture by teaching people how to cooperate in a very structured way.

Sofus (30:29):

To come back to trying to be the devil's advocate here, because it's no secret that I'm a fan of your methods, I think that they are actively helping people to do better, not only by self esteem or the niceness of being at work, but actually because it provides very good value for the customer. But when is this not the method to use? Because, I mean, now you're selling it, and of course you are ... You have written an entire book about it, but is there places where you'd say, "Well, the Samman Method is actually not what they need right now." Or, "They are not ready to adopt the method."?

Emily (31:05):

Right. So if the team is working loads of overtime, because they're in so much pressure to deliver stuff, then they're not going to be able to do this coaching, and that's a problem I've been having with one of the companies I've been working for, that the teams have signed up for the coaching and then at the last minute had to say, "No, sorry, we've got this deadline and we're all working overtime and we can't do this." And that's ... I'm glad they've realized that, not just work more overtime, but, yeah, that's a situation where I definitely pull back and say, "Okay, you need to have the space to slow down a little so that you can learn some new skills and invest in your team, and then speed up later, and avoid that overtime for the next deadline, but possibly it's not going to help you for this deadline." You know? So that's when I definitely wouldn't go ahead with the coaching.

Emily (32:00):

And also, yeah, there's another situation I had where the feedback loop on the compiler was just so, so slow, the compilation took so long that five people sitting on the ensemble waiting for the compiler for most of session, it's like ... We, actually, with got round that in the end by finding a very small piece of code that we could compile by itself and work on that, and we got through it, but that can be challenging too, if the technical environment is just too slow.

Sofus (32:28):

When your feedback loop is longer than what your heart can take, then it becomes very, very hard. Yeah. So you talked about this when teams are stressed or working overtime, and I could see that some new potential customers would also say, "Well, how long should I do this, or should we do this, in order for me to see the benefits of it?" So do you have any measurements around how long does it take for a given team to reap the benefits of the Samman Method?

Emily (32:58):

Well, in my experience, the first thing that is happening is usually the team needs to learn the ensemble working roles and how to behave in each role and how to mange whole team programming, but in my experience, most teams that are mostly functional before the coaching can get the hang of that within the first coaching block of 10 coaching days. And then the second coaching block, then we can really start to focus more on the technical practices than on the way of working.

Emily (33:31):

So I would always try and book at least two coaching blocks with a team right from the outset. Ideally, it would be kind of just on a timetable of they'll keep having the coaching every so often until they feel it's no longer valuable, or they would like to try something else.

Emily (33:48):

So, yeah, I think that's kind of what I would say. I don't know how long it will take for your team to become expert with TDD, but I think they'll probably learn ensemble working in the first block, and then after the second block, we can see how things are going.

Sofus (34:03):

So just like anything else, riding a bike, you need to first learn how to do that in order for you to actually reap the benefits of it.

Emily (34:11):

Yeah.

Sofus (34:11):

The first time you put into a new method, you are not going to reap the benefit of it. Seems about right. So who is your target audience for the book? Because when I read it, I felt like I was one of the target audiences there, because there's a lot of practical exercises, but also geared towards the facilitator. So you use a lot of time in explaining how you would present a given exercise, instead of just saying, "Read this through and try to do it on your own." So who did you have in mind when you wrote the book?

Emily (34:42):

Well, I'm really pleased to hear you say, Sofus, that you felt that I wrote it for people like you, because that's really encouraging. Yeah, because I know that you are an experienced trainer and experienced software developer, and you're just the kind of person who I think should be benefiting from this. So, yeah, I'm writing for people who are technical, who write code, and also people who would like to make a difference beyond just improving the way they, themselves, code. Perhaps they want to help their team, and perhaps they're already in some kind of coaching or training role, and would like to do that even better. So that's really who I'm writing for.

Emily (35:18):

But I also had this experience a couple of years ago, which is one of the things that led me to try and write the book, where I was coaching a team and I was talking to their scrum master, and it turned out that she had only just become a scrum master, and only a couple of months previously she had been a developer in the team. And I asked her about that, that career choice, that she'd just made that decision, and she said, "Well, my manager encouraged me to go on a scrum master training course because he thought I might have a flair for it, and I'm interested in making a career for myself, so I tried it out and thought, 'Well, yeah, I could do it. I can do facilitating and building teams.'" And she'd chosen to change her role. And I was obviously very pleased for her that she'd found a role that she'd liked, but I was a bit sad that she's given up coding, and that was probably the right decision for her, but I was like, "Did anyone point out to her that she could have become a technical coach, that there's this other career available, that you didn't have to drop the coding and become purely a kind of coach or facilitator manager?"

Emily (36:23):

I wanted to make it possible for there to be that other option, be just as obvious, just like if you want to become a scrum master, there's any number of training certifications and career paths and really explicit for you to go and look at, but if you want to become a technical coach, I mean, there isn't so much. It's more of a kind of vocation that people fall into, I don't know, that's how I got into it.

Emily (36:47):

So I'm kind of thinking there should be, if by writing down the Samman Method, and making it accessible in a book, you're pointing out. "There's this other option. You could be a technical coach, you could use the Samman Method, look, it's really concrete and easy. This is how you do it." Well, easy, I don't know, but, you know, at least it's a ...

Sofus (37:02):

It's concrete at least.

Emily (37:04):

It's concrete at least, yeah. So I'm kind of thinking that that manager, instead of advising their bright, young software developer, "Become a scrum master." They might pass them this book and say, "Have you considered a career as a technical coach." And I'm thinking this particularly for women as well, you know, who, I don't know, if you've never seen a technical ... A career as all the technical leaders in your organization are all kind of men, they're all ... Being an architect means growing a beard, which you'd have no trouble with, Sofus, but I'm a bit challenged in that department, so I would like there to be kind of an option for all the women in the industry as well, to see that they could become a technical leader, and this might be a good fit.

Sofus (37:48):

I think there are two very distinct, important things that you're saying here: that being an agile coach or scrum master or something like that, it's all about the process, but it's not really about the technical part, but before you introduced technical agile coaching for me, I didn't know that that existed, so it was like a void where you could say that there should be something there, because being good at programming is not something that you just do. It's something that you train, just like anything else, so why don't we have a coach for the technical part, just like we have a coach for the process parts as well?

Sofus (38:21):

And, yes, for people that might not be super nerdy into a very specific topic, but is good at also explaining things, then the technical coach partner fit is very intriguing.

Emily (38:34):

So I hope that it will be ... More people like you will think, "Oh, yeah. I could be a technical coach, and I don't have to give up coding. I can use all my people skills and facilitation abilities, and that's going to be a fun career for me." I think it's a fun career for me, so it could be for other people.

Sofus (38:51):

For those who haven't read the book yet, I think what I find very interesting in it is that you are not only sharing the method itself in a very narrow scope, but you actually fold it out, just like you're saying now, saying, "How do you conduct a facilitation? Here's some examples of the exercises you can do. It's important when you do this and this, that you keep contact with the given people that you're working with." So it's also around a field guide towards becoming a technical agile coach, and not only saying, "This is a method, follow this method and you will be successful."

Emily (39:26):

Yes. So I'm trying to give a few hints to how to make this into a career, and that's another thing, I'm thinking how to develop that, how to make it even easier for people to get going with this kind of thing, because I think it works, it's valuable, people need it. There should be more technical coaches out there.

Sofus (39:43):

I think definitely as well, yeah. Thank you so much, Emily, for joining. It's been a pleasure talking to you, and I hope that the book will be read by many, many people. I think technical agile coaches and Samman Method is a thing that we should have more in, in the world. So is there anything you would like to say, just before we end this episode?

Emily (40:04):

It's been really great talking to you as well, Sofus, thank you so much, and if, I just wanted to pointed out if you are interested to find out more, there's the book, and I work for ProAgile, which is a consultancy company, and we offer this kind of coaching and maybe that could be useful to you or someone you know. Thanks.

Sofus (40:21):

Fantastic. Thank you so much.

Lauri (40:23):

Thank you for listening. If you haven't already, please subscribe to our podcast and give us a rating in your platform. It means the world to us. Also, check out our other episodes for interesting and exciting talks. All I say to you right now is take care of yourself, and keep zero day delivering.