This is a transcript of episode 164 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

In the second of a two-part series, Johan Abildskov of Eficode has a conversation with Jeffrey and Squirrel about tools for using conversations to implement agile and DevOps methods, including Test-Driven Development for People (aka the Ladder of Inference).

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Test Driven Development for People

Listen to this section at 00:14

Squirrel: Welcome back to Troubleshooting Agile. So this is Squirrel here, I’m introducing our interview with Johan Abildskov from Eficode. This is part two. Last week we had a bit of an intro to some of our ideas about action science and conversations, improving Agile development and lots of other good stuff. This week we get into a little bit more of the detail in particular topic near and dear to my heart, the ladder of inference, better known, at least to me as test driven development for people. So let’s hear it.

Johan: One of the many things that I like about your content is how we take it from being very fluffy, vague and turn it into some concrete techniques that we can apply. And you have been sneaky enough to phrase some of your things in terms of technical terms. If you have this concept of TTD for conversations

Squirrel: Test driven development for people.

Johan: Test driven development for people excellently, where we kind of cheat the phrasing to make it more digestible for the technical people. Putting it perhaps one of my pet peeves that I’ve heard Emily Pash mentioned is that sometimes the fluffy ones of us, every time we want to do something that’s about conversations, a culture or anything like that, we take all the engineers, our loving geeks, and we pull them out of their comfort zone and over to our court, right? And now we are in charge. We are in our home court. And where Emily mentioned this is one of the key powers of mob programming or ensemble programming. We would take the collaboration exercise and actually put it into the hands of the developers, put them not at the whiteboard with Post-it notes like all the Agile coaches. But you inject into their domain the co-creational or conversational practise. Do you have any thoughts on on that?

Jeffrey: Well, I hadn’t heard that framing of ensemble or mob programming before, so I do love that.

Squirrel: I like that as well. Absolutely. And test driven development for people came about because I was learning about, Jeffrey and I learnt over and over many years about these techniques from action science, from Chris Argyris and when I was looking at and practising with the ladder of inference, I’ll illustrate it in a moment. It was amazing how much it felt like when I learnt TDD and because I had that direct experience, I could say these things are closely related. It’s not that I’m dragging it in, and it’s not that I’m warping the experience of applying it in order to make it palatable and nice for developers. No, it’s the same thing. So what you do intentionally illustrated, what you had to do in test driven development is to write a little bit of code. You write the test,sorry, you write the test and then write that little bit of code. It’ll fail. And then you write some code and you see whether it passes. And you keep repeating that pattern, of course. And the feeling that you get, at least that I get whenever I’m doing TDD and I really enjoy doing it is comfort and ease and certainty. I know that I’m going to be making relatively slow progress compared to if I just banged on the keyboard until I got something that works, I would feel that I was producing more lines of code, but I have no idea whether they worked, whereas I feel like I’m stepping cautiously instead of running across some thin ice, I feel like I’m walking carefully and testing at each stage and I know where I am. And the feeling I was getting in my conversations was absolutely the running across thin ice. And I can imagine that Johan you’ve probably experienced that where you’re having a conversation with someone and you’re like, I have no idea whether this is going to blow up next, now, I’m going to talk about this person and how they’re acting and how that makes me feel. And they may scream at me or leave the room or fire me or something else. And I’ve had that over and over again as probably many folks watching and listening to this have. And then I tried with the ladder of inference and I said, oh, this is testing.

Squirrel: This is just checking at every stage what’s happening. And I said, I would illustrate it. I’m just going to illustrate it with the dialogue that I was describing before with the role play with the product manager, because I was taking the first step on the ladder of inference. The first step on the ladder is really to say what you see. What would a video camera record? What data do we have in common? And then you ask after having verified that and get a green test. Yes, we both see that. We both agree that you sound like you might be sad and you say, but the important part for me is “your feelings are important to me. I think your feelings are important, do you agree?” And that is a test that can fail. Right? And you can fail at the observation point, I might say, “hey, guys, you know, I feel like I observe that this Zoom call that we’re on is running really well. You know, I’m hearing you perfectly, your video is great.” And you guys say “ Yeah Squirrel, but you sound like a robot chipmunk and you know, your emotions are all jittery and we’re not seeing the same thing that you’re seeing.” That would be useful for me to know, because anything I then reason about after that might not be useful. You know, ‘you guys are ignoring me’ well you’re not ignoring me, you can’t hear me. Right. Would be a useful thing to to get right first.

Squirrel: So then you take each of these steps and the ladder, you can see more about it and read more about it on That’s our website. And there’s videos and links to our own websites and so on our 162 episodes of the podcast. But the point is that as you take steps along this ladder, you’re gradually making more and more certain that you’re on firm ice, that you’re not going to fall through, that you’re acting in accordance with what the other person’s reasoning is, and you’re building trust all the way along because you and the other person are saying, yes, we see this the same way. I might not agree, but at least I know what your view is and how you reach that conclusion. So that’s an example of taking a experience I had as a developer and applying it in this very different field and saying, ‘actually, this is the same thing’. And the comfort and ease and joy that you’re getting in writing code is something you could also have in your conversations.

Johan: Fantastic, and that’s also just one of the small ways where words matter, right? Words matter. The words we pick and getting that sense and I love the phrasing you have, like where it’s like TDD because it is taking that sensation that you’re just running across [thin ice]. You have no control or it might go off in all directions and actually getting some iterative approach at figuring out where the tracks they diverge. And that again, fits back to like you said, I don’t remember unfortunately, who of you mentioned by saying ‘frustration is an opportunity’ and frustration that often comes from some sort of conflict, whether it’s a conflict of mental models of values or of seeing different things. “Well Squirrel you told me this and Fred you told me that.” So even if we figure out of that completely foundational level, we are not seeing the same things, then that’s tremendously important.

Squirrel: And so many of the misunderstandings that people have, come from that lack of common understanding. I was just before coming on here, I was seeing a client of mine writing and saying, “I don’t understand why this person had this view.” And I said, “well, I asked him, and the person had the view that there were too many meetings.” And he said, “I looked at his calendar. There are no meetings in his calendar. What’s he talking about?” And I said, well, I asked him. That was the curiosity that helped me discover what was going on. And it turns out he meant ad hoc ‘Hey, can you help me with this?’ And the person said, “aha, that makes sense. He’s always complaining about being distracted from his coding.” That’s what he means by too many meetings. He doesn’t mean something in his calendar. He means somebody chatting him. They could have a completely different conversation about addressing the problem of too many meetings. Whereas if the manager was going to come back with “you don’t have too many meetings, your calendar is empty. Stop complaining.” That wasn’t going to be very productive. That wasn’t going to help very much. So it was that level of understanding at the very basic level of understanding what the words meant.

Creating Habits for Better Conversations

Listen to this section at 08:35

Jeffrey: And the thing is that kind of misunderstanding generally happens instantaneously without people understanding that there even could be a misunderstanding, that what is meant by the word meanings has more than one meaning, that’s not intuitive, because what happens is the way our brains work. When I say I have too many meetings, you get a picture in your head, the little movie plays and you’re like, oh, OK, this is what a meeting is. This is what he means by too many? I’ve had too many meetings before. I know what that’s like. No curiosity comes up like, ‘oh, what does he mean by meetings?’ There’s many possible meanings that doesn’t occur to us and it shouldn’t. By the way, I’m not saying, if all of our lives were run in a very deliberate process like this, we wouldn’t get anything done.

Squirrel: I wonder if that traffic light means that I should stop or go it normally means stop but red could mean something- I should ask and enquire and find out. That would not function. We couldn’t function.

Jeffrey: Yeah. I remember reading the book Thinking, Fast and Slow, which is the Daniel Kahneman book that talks about the way our minds work in these different systems and that the overall message there is there’s two systems, the fast one, which is happening unconsciously all the time, and the slower deliberate one that’s there to help you learn and catch errors and whatnot. And the challenge then is knowing and understanding how to bring that system to into to help when it’s needed. Not that we should be using it all the time, it just wouldn’t work. We navigate our world in a quite literal way. We cross the street, get where we’re going, you know, check stuff out of the code base. We have all these habitual routine activities that we do that we reduced down to patterns that we can execute automatically. And that’s a good thing and that’s a necessary thing. So it’s not that we’re saying that’s bad and we should give it up. But what we are saying is something different, is that we can become sensitive to cues that it’s time to bring in a different mode of thinking and in particular, if we start feeling ourselves being frustrated, angry, upset, it’s a chance to rather than continuing our habitual response of “I’m right, they’re wrong.” That there could be a better response, to say “I’m right and I think they’re wrong but, you know what, they probably think the other way. They probably think they’re right and I’m wrong. I wonder why. Even though I’m pretty sure I’m right. I’m curious what they’re seeing differently.” I’m curious what’s different about their experience and cultivating that kind of curiosity and learning to to activate it on the trigger of something like frustration and pain and upset or boredom. Right? One of the things that people are very surprised that when we talk about this is this can apply to when you’re in a meeting and you might say, “I notice that I’m feeling bored right now.”

Squirrel: One thing that will definitely happen is you will no longer be bored.

Jeffrey: That’s right. From that moment, I don’t know what’s going to happen in that meeting, but it’s not going to be boring. You can say “I’m feeling bored. I wonder how everyone else are feeling about this. Is it just me, are you all riveted? I’m wondering if we should be doing something different?” That can be tremendously exciting to realise that’s a possibility, that you can do that and you can get much better dynamics in the group when you’re able to sense what’s happening and share your point of view. It feels very different. This kind of intervention feels very different than one Squirrel brought up earlier of, “I notice you’re looking down. I know your voice has gotten quieter. I’m wondering if you might be sad?” That sounds different, but it’s the same. It’s going back to that idea of something’s not quite right. Can I say what I am seeing and ‘seeing’ might be what I’m sensing internally, how I’m feeling. So if I can learn to share what I’m seeing and at the same time to be curious about what other people are seeing, then this is the foundations of good interactions between people.

Speak Up

Listen to this section at 12:34

Squirrel: And I have an example which I’d love to share where I observe this having tremendous effects. So some of this can seem quite theoretical. And you say “oh yes, it would be nice if I could understand why the developer was sad, but maybe I could implement the feature slightly differently. OK, what’s the real benefit?” So in one case, I was sitting in an executive team with the founder of the company and a number of high powered folks who were running big teams that were doing all the things for the company.

Squirrel: And we all went around and the salesperson said, “yep, we’re ready for the new product. We know the sales pitch. We have the decks ready.” Marketing said “the blog posts are ready to go, all we have to do is push the go button.” Product said, “yeah, we understand it. We know how we’re going to train people.” The tech folks said, “super, we’re ready to support it.” And all the way around the room with everybody saying what they were going to do, we got back to the founder. The CEO was sitting there staring out the window, which is kind of strange. We were thinking, why? Why are you looking out the window there? And he said, “there’s just something that bugs me about this. I can’t put my finger on it, but I feel like I should tell you that there’s just something that doesn’t feel right about what we’re about to do. You all just gave me the greatest set of reports ever, but what’s wrong?” And then we went around the room again and the salesperson said, “well, actually, our intelligence is that nobody is going to buy this. But you guys all told us it was great. So we’re ready to go sell it. If it will work.” and the marketing, people said, “yeah, we’ve already done surveys. Nobody likes this. This isn’t going to go anywhere. But you said, So we’re going to try it.” The product folks said, “yeah, the training, nobody seems to understand it. It’s not really working.” And the tech folks said, “yeah, and we can’t even get the servers up.” So everyone around the circle said this isn’t going to work. None of them said anything until one person said staring out the window, “actually, there’s something I see here. I don’t know what it is, but it’s not working.” All of them thought, well, all the rest of you thought it was OK.

Squirrel: I’m here in sales, you in marketing, you in tech, you and product, you’re all telling me it’s OK. It wasn’t OK. We didn’t launch the product. Right. So that was a tremendous turnaround for the company and saved huge amounts of embarrassment, not to mention cost, launching something that wasn’t going to work. We launched something else that did work. So if you’re looking for examples where this kind of action can have tremendous leverage, can have tremendous effect, I can tell you ten stories like that with with no trouble.

Jeffrey: And they happen at all scales. Right, because this is not to go back to Johan your earlier concerns that people who are technical might feel like this is not for them, like, “well, that’s managers and managers are about talking in boardrooms” but this happens all the way down to when people are coding. You know what the design is.

Squirrel: Your pairing partner.

Jeffrey: Yeah, it could be your pairing partner. You could be by yourself and feeling uncomfortable with some code you’re looking at and not quite sure “like, well, do I feel comfortable raising this and raise my concerns or am I just going to carry on and hope for the best?” And so this kind of insight and courage and contribution can happen at every level from implementation to strategy.

Jeffrey: And the other thing that comes up, people say like who has time for this? And the answer is, everyone, this is free. This more than pays for itself. I’ve done lots of conversation analysis with people and very often they’ve come over long discussions and long arguments they had that were very challenging. And they realised after they analyses they go, “wow, this could have been solved in like three lines. If I had just asked this question at the beginning.” In fact, we saw this pattern so often that it’s almost always, if your first response early on in that conversation was, “you know, I’m afraid that…” Complete the sentence. And it could be, “I’m afraid that this won’t scale” or “I’m afraid that we won’t be finished in time” or “I’m afraid that no one’s going to buy this” or “I’m afraid that I don’t really understand”. Any number of things would have made a much more productive, shorter conversation. And so that’s why I say this is something that people definitely have time for if they have the appetite for it.

Finding your Fears

Listen to this section at 16:31

Jeffrey: And it goes back, what’s important to you? I remember reading in Kent Beck’s Extreme Programming Explained which was a great book and really transformational for my career. And what thing that stood out for me is in the epilogue he’s talking about, he made the observation that every methodology is rooted in fear and XP reflected his fears. And one of the fears that he had was, was to making software that didn’t matter, shipping software that didn’t provide value. And that really resonated with me. And so it comes back to what is it you fear? Now we all have our fears about interpersonal communication and risk and how people might see me. But I really fear spending my life in teams where I’m not enjoying myself, making things that don’t matter. And I’d rather risk some interpersonal discomfort in the moment to avoid that outcome. And that’s why for me, investing in conversational skills has been a good investment. And it’s from that which I can say, if you’re similarly concerned about how you spend your time, do you want to be working on more exciting things, having more fun, being more effective? If those things matter to you, then we’d recommend learning the skills of Agile Conversations, because in our experience, it can make a tremendous impact in these areas.

Johan: Thank you. And again, I’m just soaking it all in. One thing that you mentioned a bit earlier, Jeffrey was the fantastic book, Thinking: Fast and Slow of Daniel Kahneman.

Squirrel: We’ll put it in the show notes for the folks watching your podcast.

Johan: Yes. And it even one of the biases that he mentions that they bring is is what you see is all there is bias, where we have a tendency to believe, contrary to all evidence and all experience, that we have full information, right?

Jeffrey: Yes.

Johan: And if we try to tie that back into the original chronic DevOps conflict.

Jeffrey: Yes.

Johan: The conflict between developers and operators. Right?

Jeffrey: Yes.

Johan: They say “I as a developer, I worry that you, for no good reason at all. I can see no good reason. I am unaware of any good reason that you should not just put this in production right away.”

Jeffrey: Yes.

Johan: And the other way around is “I as an operator, I can see no good reason why you keep pushing this unstable, nonperforming, non-compliant B.S. over this fence for me to struggle with.” And tying that together and even in terms of KPIs that might be in conflict and we might need to go a huge direction up and down the organisational charts for getting people the right way. And even though we might be getting more into team, squad, tribes, whatever we call them, we still as an industry have tons of functional silos, both horizontally and vertically and randomly dotted across the organisational landscape.

Johan: So I think the thing that you’re bringing together here is just so foundational for all the things that we do in DevOps, because it is exactly- we are always afraid of things we can’t control and I love stating “I’m afraid that you will reject my change and I will be scolded because I did not deliver my feature.” Or “I am afraid that you will break my production systems because you have not considered.” And that’s such a powerful starting point for shifting left or including people at the table earlier. Like why don’t we have the operators, the security people, the testers, the business, the whatever functional role we have. Why don’t we talk together at the beginning while it’s still cheap to digress? Why do we have to have a CEO doing his job, looking out the window before we figure out that something is off? Right. So perhaps as one of the final things, I think the time is getting around our end.

Successful Structures

Listen to this section at 20:58

Johan: Even though what you have talked about here and what I at least understand from your book is what I as an individual contributor or what I as someone who has understood, I think Avery wrote Teamwork is an Individual Skill or something like that. Jeffrey you mentioned something about you get the sense that the dynamics are not right. But I know at this session we probably have some people who are those managers who live in meetings and conversations. Who are those people here. So could you talk a bit about some of your favourite structures or like setting the frame for us individual contributers, us ICs. What are some of the things that those higher up in the charts can do to make it easier or safer or more natural to work with some of these frustrations or styles or patterns? Then I would be very happy.

Jeffrey: That’s a good question, I’ll just say it’s interesting because you talk about structures and this is not something that I talk about very much about because I think they’ve all been written so, you mentioned yourself. More cross-functional teams, colocation, earlier collaboration. I think those structures are well documented.

Squirrel: Jeffrey what we just need is we just need to all adopt the Spotify model, right? That would make everything better. If we just adopt that structure, It’ll work because it works so well for Spotify. Right?

Jeffrey: But the problem is that, and I think this goes back to when I read many, many years ago from Alistair Cockburn, which is he was at the time looking at software methodologies and roughly said something like, “every methodology can work and every methodology can fail.

Jeffrey: Now, some are more likely to succeed than others. And I think ones that are more likely to have colocation and early collaboration are all more likely to work. So it’s not it’s not about the structures. I think the much more important skill for the managers and for leaders in general. Actually, I would say this, anyone who is able to sense the dynamics and act on them becomes the leader. now the hierarchical position you have gives you a bigger lever, gives you more leverage when you spot something to make a change. So it does make a difference whether you are an individual contributor or the CEO or director or somewhere in between. It’ll make a difference in your leverage, but not in your ability to be a leader and not in your ability to see the problem, speak the problem and start the conversation. The managers will have instinctively a larger audience, they’ll have more senior people, and they’ll have more opportunities to ask the question. But I think that’s the point for the managers, is the same as everyone else. If you want to make things easier for your team to have good collaboration, the best thing you can do is learn your individual skills of conversations so that you can ask these questions and start understand what’s going on and then give you a position to change the dynamics. That’s my view.

Johan: That’s so uncomfortable for the manager and leaders who now have to change and learn all those uncomfortable truths about themselves. Thank you so much. Squirrel do you have any follow up on that or are you happy?

Squirrel: I’m happy with what Jeffrey’s described. I agree completely.

Johan: Fantastic. Thank you so much for spending this time with me and for allowing me to be a guest on your podcast when we get there. It’s been such a pleasure.

Squirrel: Both host and guest, excellent, glad to have you.

Jeffrey: All right. Thank you Johan.

Squirrel: Thanks Johan.

Johan: Thank you.

Squirrel: All right, well, that brings us to the end of this interview, two part interview with Johan Abildskov, very interesting interviewer from Eficode in the Nordiques. We really appreciated hearing from Johan coming to the Eficode DevOps conference and otherwise getting a chance to exchange ideas. If you have different ideas, if you disagree with us, if you agree with us, if you’re not sure, we’d love to hear from you at We’ll be there with Twitter and email and phone numbers and who knows what else, videos, all kinds of fun stuff that you can check out to get more in touch with us and hear more from us. And, of course, we’ll be back next Wednesday. Special hint in the next couple of weeks. We have a couple of very special guests. So watch out for that. And we have some very interesting folks coming up. So you won’t want to miss the next few weeks in April.