In this podcast episode, I welcome Emily Bache, Author, Technical Agile Coach with ProAgile. We talk about agile coaching, the Samman Method, peer reviews and various communication techniques and methods. Listen to our insightful conversation or read the edited transcript.
What we talked about:
- The Coding Dojo Handbook
- Starting a career as an agile coach
- The Samman Method
- How long does it take a team to embrace something new?
- Communication techniques and methods
- How to begin with ensemble working
- How to improve soft skills and team work in an organization
- How to deal with flaky tests and large test suites
Connect with Emily:
- on Twitter
- GitHub
- Emily’s website and sammancoaching.org
- Emily’s books on Leanpub
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited Transcript
Darko Fabijan:
Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I’m excited to welcome Emily Bache. Emily, thank you so much for joining us. Can you please introduce yourself?
Emily Bache:
I’m a software developer and technical coach based in Sweden, although I grew up in the UK, and I’m delighted to be invited to talk to you.
Introduction
Darko Fabijan:
Great! Can you maybe give us some of the stepping stones through your career that led to you becoming a coach?
Emily Bache:
My career began in 1998 when I graduated with a degree in engineering and I got a job as a software developer doing Java. Then quite soon after that, in 2000, I moved to Sweden with my husband, and we’ve been in Sweden ever since.
And I landed on my feet because the first job I got in Sweden was a startup and it was Java again, and it was using extreme programming.
So, I really landed in this team of very good software developers. We were learning to write unit tests together and talking to the customer frequently in pair programming, and it was such a good experience.
I really got onto this whole agile and testing thing pretty early.
The Coding Dojo Handbook
Emily Bache:
Since then, I had got a job doing some Python and worked some consultant for many years, and started training people in test-driven developments using the Coding Dojo. I wrote a book about that in 2011, The Coding Dojo Handbook. And then I spent some time doing some architecture and test strategy.
Emily Bache:
And then in 2018, I was invited to pair coach with Llewellyn Falco in the US. He showed me how he was not only teaching teams TDD but also refactoring, handing lazy code, etc.
I was so inspired by that I thought, “Right. Well, this seems to work.” So, I started doing technical coaching myself, and that turned into another book that was published about a year ago, “Technical Agile Coaching with the Samman Method“.
So, that’s what I do these days. I do technical coaching.
Darko Fabijan:
Great. And we are going to dive further deeper into that.
For some of the people who have been doing software development for a while, there are paths that they can take. They can move into management. They can stay in the software and do hands-on stuff.
Coaching is something that’s less frequent. Did it come natural to you over the years because you were helping people and enjoying that? How did you end up being a coach?
Starting a career as an agile coach
Emily Bache:
At first, it was self-preservation. I was ending up on a team where I was the only one writing any tests and I was like, “This is not fun.”
The tests are breaking all the time and nobody cares so I’ve got to do something to persuade my colleagues to pay attention. So, it kind of grew from there that I found I actually quite liked holding little trainings and dojos. That’s where it started.
Emily Bache:
The thing is, I could have gone into coaching full-time but I think as I really liked writing code, I didn’t want to give that up. And I still don’t.
So, this thing with coaching and teaching is a way to have influence and be senior, and show technical leadership without losing touch with the code. It combines this people stuff with technical stuff in a really fun way, in my opinion.
And I think I have more influence as a coach than I would have as an individual contributor. I certainly meet more teams and interact with more people.
Darko Fabijan:
Yeah, yeah. And hearing you’re fit in both areas is super important. Now that you said that, because I did meet a lot of people doing trainings one way or another, and it can really show if this guy or girl haven’t touched the code in a while.
Emily Bache:
Yeah. You know, this industry moves so fast. You really have to be writing a lot of codes to keep up with all the latest frameworks and tools, and languages, and everything.
The Samman Method
Darko Fabijan:
You’ve also published the book about the Samman Method. We don’t know anything about it. Could you please tell us more?
Emily Bache:
I just felt it needed a name for the way I’m working, just to make it easier to find out more information and find other people who are doing this kind of thing. The name came long after the coaching approach, which I’ve been doing for a few years.
Emily Bache:
As I said, Llewellyn Falco is a great inspiration for me. And there’s a whole community of coaches who are doing ensemble working or people call it mob programming as well with teams as a way of transferring knowledge and skills and writing better code, and having more fun at work.
That’s a major part of Samman method is doing ensemble working. That’s the whole team programming together on one task and delivering that code, trying to get everyone in the team to contribute to that piece of code so that we get the best of all of us into it.
The major part of the Samman method is doing ensemble working. That’s the whole team programming together on one task and delivering that code.
-Emily Bache, Technical Agile Coach, Author
Emily Bache:
And as a coach, you’re there to facilitate that, to make sure that the team is able to collaborate in that way. But you also need to contribute what you know about how to write tests and how to refactor safely so that the team learns those things as well.
So, working in the production code with a team in an ensemble is one part of the Samman Method.
Emily Bache:
And then the other part is, if you’re going to learn something like TDD or refactoring, there’s theory, skills, vocabulary, and exercises that you can do that will help to you to learn those things in a more effective way.
So, the other part of the Samman Method is these short teaching sessions, where we do exercises and we learn skills, and we practice.
Emily Bache:
Those are the two main parts of the Samman Method. As a coach, I come to a team and I facilitate ensemble working, and I lead learning hours. And I don’t do that full time, the team has to have time to do their other stuff, get tasks done up with me not being there.
Emily Bache:
As a coach, I can work with several teams concurrently or I can work part-time, and I can go to a lot of conferences and stuff, if that’s what I feel like doing.
As a coach, it’s a great lifestyle, in a way. And for the teams I’m coaching, it’s the most effective way I know so far for introducing this kind of technical practices in teams that aren’t using them.
How long does it take a team to embrace something new?
Darko Fabijan:
As you were speaking about this, I was contrasting this with my experiences and how I learned it, how I helped other people to just get on that strain of TDD. I would say also writing tests in general, because that’s also where our industry tends to struggle.
Can you please talk more about the timeline that you are seeing with the teams but introducing anything new?
Emily Bache:
There’s a lot of variety. I mean, most of the teams I go into and I start working with, they already have some unit tests and often, other integration tests and continuous delivery pipelines.
Often, they’ve got basic infrastructure. Also, quite often, I’ll find that maybe there’s one person in the team who is a bit more experienced and actually does really know their stuff already, and can write good tests, and do refactoring, and stuff.
But at the same time, the rest of the team is much more junior or perhaps less experienced with these techniques, and it’s not always easy for even one experienced person in a team to spread that.
And of course, sometimes you come to a team and nobody knows anything about this, and they’ve been told to write tests but they’ve no idea how to write good tests.
Teaching collaboration techniques
Emily Bache:
So, as a coach, I come into this kind of situations. If the knowledge is already in the team and somebody there is experienced, then as a coach, it’s just a question of teaching collaboration techniques, really, so that they can learn to spread that knowledge and learn from one another.
That’s the biggest thing I contribute some of the time – the collaboration techniques, which is great in itself. I mean, ensemble working is a fantastic technique even without the rest of the learning hours and stuff that I do.
Teaching how to design good tests
Emily Bache:
But then of course, if there’s really a lack of knowledge about how to design good tests and what TDD actually is.
It’s not just writing unit tests, TDD is a design technique. It’s a way of developing code and test together.
Then there’s, perhaps, a lot more focus on the learning hours at first of what is TDD. And quite often, you come in and the codebase is built in such a way that it’s really hard to write good tests.
And then, at that point, it’s a lot more like, “Well, can we do safe refactoring here?” Even with the tests we’ve got, perhaps we’re better off focusing on the refactoring techniques before we try and learn too much about testing.
So, the approach I take does vary according to the situation the team is in, definitely.
Communication techniques and methods
Darko Fabijan:
Clear. And in ensemble practice, you mentioned your communication techniques or methods. Can we perhaps dive a bit deeper there?
Emily Bache:
Yeah. So, I don’t know if you’ve ever tried to program with six developers in the same room with one computer. If you just try and do that with no guidance, it could get a little but chaotic.
Every software developer has opinion about what the code should be and different ideas about where we should start and what we should focus on.
And so, a lot of the ensemble working technique is just working out how should we talk to each other in a way that actually means that we’re collaborating and not fighting with each other.
A lot of the ensemble working technique is just working out how should we talk to each other in a way that actually means that we’re collaborating and not fighting with each other.
-Emily Bache, Technical Agile Coach, Author
So, when I’m teaching it to a team that hasn’t done it before, we’ll go through, “Well, there are some roles. If you have this role, then you should say this. Otherwise, you’re quiet.”
So, it’s like I’m quite strict to the start. And then when you’ve got the hang of it a bit, you can start to loosen up the roles a bit.
Ensemble working technique in practice
Emily Bache:
So, the way I teach it is that the person with the keyboard, who’s controlling the computer, that’s the typist. They are typing in the code that the rest of the team has decided on, not the code that they have in their head that they’ve decided on. That’s important.
The person with the keyboard is not driving the direction. They’re not making the decisions. They are just typing in the code. So, that’s the first thing.
Emily Bache:
And then the other thing is that in order for the typist to know what to write, they need to get some clear instructions from the rest of the team. So, we have the spokesperson who is called the navigator, and they’re the person who is supposed to be primarily directing the whole ensemble and making the decisions.
And they, of course, need to get help and input from the rest of the team. But they should be the person initiating that so that everyone else is mostly quiet until they get asked, or unless they really, really have to say something.
And then of course, you rotate these roles so that you don’t get completely stuck in one person taking over the whole time.
How long is a typical session?
Darko Fabijan:
And what’s the duration of the session?
Emily Bache:
I would definitely take a break every hour for at least a few minutes. But when I’m coaching a team, we normally do a two-hour session on the ensemble.
And I think if you’re a beginner, that’s a nice length, two hours with a short break in the middle. And then when you’ve got used to the technique a bit, maybe you can vary that.
Darko Fabijan:
And on the topic, “Okay, what we are going to work on?” Because they have much deeper insight into their codebase. I understood that you are working on their codebase so this is not something which is examples or fictional.
How to begin with ensemble working
Emily Bache:
Yeah. I mean, if you’ve really never done ensemble working before, it can be useful to begin with toy codes, katas, exercises just because it makes it so much easier to go focus then on the communication patterns rather than the code.
Darko Fabijan:
But you do progress?
Emily Bache:
Yeah. As a coach, I’m hoping to get to the point quite soon that we can go into their codebase.
The thing is, with something like refactoring and TDD, you can do it on the example code relatively easily. After a few sessions, you can be competent.
But then you go to your production code and suddenly it’s like, “Wow, this is so much harder.” And that’s the point where you really need somebody with a bit of experience, like me, to come in and help just say, “Okay, this is not straightforward but trust me a bit. Let me navigate for a minute and help you get started with this test.”
I think we need to focus on refactoring and try and prompt them into doing in small steps, and committing often. But yeah, you need to get some assistance, I think, in a lot of production code situations from someone with experience.
I think we need to focus on refactoring and try and prompt them into doing in small steps, and committing often.
-Emily Bache, Technical Agile Coach, Author
Darko Fabijan:
Yeah. Clear. And then this would go on for once, twice per week and then for a couple of weeks or…
Emily Bache:
Yeah. When I started doing this, it was like we’ll do two weeks, 10 days and then we’ll have a break. And then come back, do another 10 days. But I found that it works better for me to spread it out more, 10 days over three weeks, 10 half days, in fact.
And then I’m working with one team now, where we’re just doing one session a week. I think frequency is up for negotiation. It’s partly how quickly the team wants to get input and how much they are managing themselves, I guess.
Darko Fabijan:
Yeah. Yeah. I’m asking primarily because there is that moment when you are learning something and you think you get it, and then, “Oh.” A month and a half later, “Ooh, now I get it.”
Emily Bache:
Right. So, the engagements I have with teams, I would like it to be more long-term. So that when you realize, “Ah, now I get it,” or “Actually, now I’m stuck,” that the coach is still somewhere available and you can still get some help.
Darko Fabijan:
Yeah, exactly. If I were receiving the training, I’d like to be able to call the coach a month later and ask for help.
Emily Bache:
Learning takes time. It takes practice and effort. And actually, it’s not just learning new skills, it’s the whole culture change that you’re trying to get.
Emily Bache:
When you’ve got an agile team that really understands TDD and refactoring, and working in small steps, and incremental design, and all this, that’s a team culture, as much as skill. It’s a way of working that is so embedded in the habits of that team.
When you’ve got an agile team that really understands TDD, working in small steps, incremental design and all this, that’s a team culture as much as skill.
-Emily Bache, Technical Agile Coach, Author
That’s just the way they work. And that kind of culture change doesn’t happen after two weeks with a coach or a two-day training course. It’s a much longer term kind of prospect so you need a bit of continuity and somebody to be pushing for that.
How to improve soft skills and teamwork in an organization
Navigating through code reviews
Darko Fabijan:
On those cultural patterns, I do remember, when GitHub introduced pull requests, the majority of the civilization got access to code reviews as a good and accessible tool to do them.
I remember back then some people were taking those reviews personally. It’s not a communication pattern, though. It also depends on how someone is saying things.
In terms of soft skill patterns, do you intervene and help people improve communication?
Emily Bache:
Of course. I mean, yeah, teamwork. Software is built by teams these days, and teams need to be able to communicate in order to collaborate.
I mean, this is a constant challenge for me as coming in as a coach as well, just getting accepted by the team as somebody who’s worth listening to. So, there’s all those soft skills and culture, and communication, it’s really important.
Emily Bache:
And I won’t just drop into a team and say, “Right now I’m coaching you.” I always try and get to know them first, find out about their situation and try and discuss with them the challenges they’re seeing, and where I might be able to contribute something.
Code reviews and the Samman method
Emily Bache:
We started here talking about code reviews. I mean, on Samman working, here’s kind of a constant code review. It’s kind of intense.
Darko Fabijan:
Yeah. Real-time code review.
Emily Bache:
Yeah. You need good people skills and good relationships for it to work smoothly.
How code katas work
Darko Fabijan:
Yeah. And I think that it’s widely known and, hopefully, also accepted. Just that element of doing dojos or kata, or doing something over and over, it is a small thing and then improving over time.
I was introduced to that two years after I finished university. And during my university years, it never crossed my mind to solve one problem, write a function class, whatever element, entity of software over and over and got better at it.
So, could you introduce that concept to listeners who are not aware of it yet, please?
Emily Bache:
Yeah. If you were given a university exercise, why would you do it more than once?
The thing with code katas, what you’re training is not your ability to solve a problem or to demonstrate that you can use a technique at all.
The techniques that you are learning from the code kata is the way of working. It’s the process of producing code and tests. That’s what you’re actually trying to achieve.
The techniques that you are learning from the code kata is the way of working.
-Emily Bache, Technical Agile Coach, Author
Emily Bache:
And when you’re doing exercise at university, you do like 10 exercises, all kind of similar, until you’ve shown that you understand the technique.
With a code kata, what you’re practicing is the flow of code from your brain through your hands, into the computer, and how you do that in small steps, and how you choose the next test to write, and how you transform the duplicated, messy design into something that’s clean and dry in the refactor step, and how you do that safely.
Emily Bache:
So, it’s really the process of programming. It’s not the end result that matters. So, that’s why you do it more than once, because that’s actually what you’re getting better at.
It’s not doing 10 different exercises, doing the same exercise 10 times, but the process that you use is perhaps slightly different each of those 10 times, and you learn, you get better.
It’s not doing 10 different exercises, doing the same exercise 10 times, but the process that you use is perhaps slightly different each of those 10 times, and you learn, you get better.
-Emily Bache, Technical Agile Coach, Author
Emily Bache:
When you do it on the code kata, the idea is you can do it in your production code, and it’s harder in the production code.
But if you can do it really smoothly and without thinking about it in a code kata, then you’ve got so much more brain capacity to spend on your actual production code and its quirks and difficulties, and understanding what the customer wants.
The importance of setting daily habits
Darko Fabijan:
Yeah. And then over time it, I guess, evolves into pretty much a habit formation, and that’s the main idea.
And with your coaching, the first part is very much a team and communication effort.
The second part can be done to pair programming, right? Over and over again.
How does that look in practice? How would you advise doing that?
Emily Bache:
I do these one-hour learning hour sessions. I structure them as a lesson that’s thought through and is trying to be engaging. And I use the 4C model from Sharon Bowman as a way to structure this and to make it interactive, because people learn by doing and by talking much more than they learn by listening and watching.
We’ll work that in pairs, sometimes all together. That is your chance to practice and to see the technique.
If you can get that kind of daily bit of practice, you’ll soon see some results that make it all worth it for your company. You’ll be so much more effective when you’re working the production code.
How to deal with flaky tests and large test suites
Darko Fabijan:
In the last couple of episodes, I was touching upon the health of the codebase and the structure of the testing pyramid. A lot of teams that I end up talking to are asking for help and advice, like, “What are they doing to attain their test suite?”
Usually, people end up having the majority of their tests to be brittle and complex that are running through the whole stack of the application whereas what they wanted is to test something simple.
So there are two major things – the duration of those tests and how flaky they are. We’d love to hear your approach to this.
Emily Bache:
Yeah, I recognize that problem. The test pyramid is set up so that what you really want are fast tests that are cheap to maintain. And what you get, often, is slow tests that are really expensive to maintain and brittle.
Why writing unit tests is not
Emily Bache:
And usually, people say the way to get fast, cheap tests is to write unit tests.
The thing with that is, of course, you need to design your code in such a way that it’s possible to have unit tests. There have to be units, and a lot of codebases aren’t built that way, unfortunately.
So, if you’re in that situation where you haven’t got units and your tests are all big and slow, and brittle, it’s very annoying to have someone come to you and say, “Right. Well, you need to write unit tests.” Because you’re like, “Yeah, but that’s really hard. I can’t do that.”
What is approval testing?
Emily Bache:
There’s a technique that I’ve been using a lot lately, well, not just lately, approval testing. This is a technique that people I know, including Llewellyn Falco and my husband, Jeff, have been pioneering this way of designing tests.
And I’m really excited about it right now, because I think it presents a middle way between slow and brittle tests and unit tests, but it does involve architecting your system slightly differently so that you can extract this kind of big units or subsystems.
And there’s a lot more to be written about this, but I’m really excited.
Emily Bache:
I’ve just been designing a new training for O’Reilly about this technique. I’ve called it hands-on agile software testing, and it’s really about architecting in a way that enables this kind of testability with approval testing.
I think it’s going to help so many people. And it’s one of the things I introduce often when I’m working with a team who I can see, hasn’t got units and refactoring is difficult.
This is one of the techniques that’ll bring in approval testing.
How to connect with Emily Bache
Darko Fabijan:
For those of us interested in hearing and learning more about this technique, about you, can you tell us what are some of the ways that we can find and engage?
Emily Bache:
Yeah. So, I’m on Twitter – Emily Bache. And from there, you can probably find the rest of my stuff on the internet.
I’m on GitHub, and I’ve got a website also, sammancoaching.org, which goes with my book, which is published on Leanpub.
And this stuff I was just talking about, approval testing, as I said, I’m doing a live online training with O’Reilly and also with TechTalk, and more in-depth training on the same topic in March. Follow me on Twitter, and hopefully, you’ll get this kind of links.
Darko Fabijan:
Yeah, that’s a good starting point. Yeah. Emily, it was super interesting to talk about all these topics. Thank you so much. And yeah, good luck.
Emily Bache:
Thank you. It’s been really fun talking to you.
