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. This is part two of our recorded interview with Johan Abildskov from Eficode. This week we get into a particular topic near and dear to my heart, the ladder of inference, or ‘test-driven development for people.’ So let’s get into it.
Johan: One of the many things that I like about your content is how you move from very fluffy, vague ideas and turn them into concrete techniques that we can apply. You have been sneaky enough to phrase some of your things in technical terms, you have this concept of TTD for people, where we kind of cheat the phrasing to make it more digestible for technical people. One of my pet peeves that I’ve heard Emily Pash mention is that sometimes when we want to do something fluffy about conversations, culture, anything like that, we take all our loving geeks and engineers and we pull them out of their comfort zone and over to our court. Now we are in charge. We are in our home court. Emily mentioned one of the key powers of mob programming or ensemble programming would be to 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 to inject into their domain the co-creational or conversational practise. Do you have any thoughts on that?
Jeffrey: It’s brilliant, I hadn’t heard that framing of ensemble or mob programming before, so I do love that.
Squirrel: Absolutely. Test-driven development for people came about because Jeffrey and I learnt about these techniques from action science, from Chris Argyris, and when I was looking at and practising with the ladder of inference, it was amazing how much it felt like when I learnt TDD. Because I had that direct experience, I could say ‘these things are closely related.’ It’s not that I’m forcing it in, and it’s not that I’m warping the experience or language to make it palatable and nice for developers. It’s actually the same thing. What you do in test-driven development is to 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. The feeling that I get whenever I’m doing TDD is comfort and ease and certainty. I know that I’m going to be making relatively slow progress, I feel rather than running across some thin ice, I feel I’m walking carefully and testing at each stage and I know where I am. The feeling I had been getting in my conversations was absolutely running across thin ice. You’re having a conversation with someone and you have no idea whether this is going to blow up, now you’re going to talk about this person and how they’re acting and how that makes you feel? They may scream or leave the room or fire you or something else. I’ve had that over and over again, as probably many folks watching and listening to this have. Then I tried with the ladder of inference and I said, ‘oh, this is testing! This is just checking at every stage what’s happening.’ I’m just going to illustrate it with the previous discussion, 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 camera record? What data do we have in common? This is a test that can fail. I might say, ‘hey guys, I observe that this Zoom call we’re on is running really well. I’m hearing you perfectly, your video is great.’ And you guys say ‘Yeah Squirrel, but you sound like a robot chipmunk and 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 any logical progression from my unverified observation is worthless. I might conclude you guys are ignoring me, but in fact you can’t hear me. That would be a useful thing to get right first. Then after having verified that and received a green test, ‘Yes, we both see that. We both agree that you sound like you might be sad,’ then you can take each of these steps on the 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 recognizing an identical process. 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 just one of the small ways where words matter, right? I love the phrasing you have, where TDD 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 diverge. As you said earlier how ‘frustration is an opportunity,’ and frustration 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 Fredrick you told me that.’ So if we can figure out that at a completely foundational level, we are not seeing the same things, then that’s tremendously important.
Squirrel: So many of the misunderstandings that people have come from that lack of common understanding. I was seeing a client of mine who said, ‘I don’t understand why this person had this view. He said that there were too many meetings, I looked at his calendar. There are no meetings in his calendar. What’s he talking about?’ And I said, ‘well, I asked him.’ Curiosity helped me discover what was going on. It turns out he meant ad hoc ‘hey, can you help me with this?’ And my client 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 with him. They could have had a completely different conversation about addressing the problem of too many meetings if the manager was went 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 foundational level of understanding where they had differend understandings of what the words meant.
Creating Habits for Better Conversations
Listen to this section at 08:35
Jeffrey: And that kind of misunderstanding generally happens instantaneously without people recognizing that there even could be a misunderstanding, that the word ‘meetings’ has more than one meaning is not intuitive. When I say I have too many meetings, a little movie plays in your head 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 is triggered to ask, ‘oh, what does he mean by meetings?’ There’s many possible meanings that don’t occur to us, and they shouldn’t! 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 else, I should ask and enquire and find out.’ That would not function. We couldn’t function.
Jeffrey: Absolutely. In Thinking, Fast and Slow by Daniel Kahneman, he provides a framework that is not biologically accurate per se, but which very helpfully groups the ways we think into two systems: the fast one, which is happening unconsciously all the time, and the slow deliberate one that’s there to help you learn and catch errors and whatnot. The challenge is knowing and understanding when that deliberate system is needed, not that we should be using it all the time. We have all these habitual routine activities that we reduced down to patterns we execute automatically. That’s good and necessary. What we are saying is we can become sensitive to cues that it’s time to bring in a different mode of thinking. In particular, if we start observing ourselves being frustrated, angry, upset, rather than continuing our habitual ‘I’m right, they’re wrong,’ there is the opprotunity for 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.’ Cultivating that kind of curiosity and learning to activate it on the trigger of something like frustration and pain and upset and boredom is really what we encourage. One of the things people are very surprised by is that when we talk about this, is that it can apply to when you’re in a meeting and you might say aloud, ‘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?’ It 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 the one Squirrel mentioned earlier. That sounds different, but it’s the same. It’s going back to that sensation of ‘something’s not quite right. Can I express what I am noticing?’ So if you can learn to share what you’re seeing and at the same time to be curious about what other people are seeing, this is the foundation of good interactions.
Speak Up
Listen to this section at 12:34
Squirrel: Some of this can seem quite theoretical. ‘Oh yes, it would be nice if I could understand why the developer was sad, but maybe I could implement the feature slightly differently, so it doesn’t matter if I understand.’ For another example, I was sitting in on an executive team with the founder of the company and a number of high-powered folks who were running all the big departmental teams. We all went around and the salesperson said, ‘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, ‘we know how we’re going to train people.’ The tech folks said, ‘we’re ready to support it.’ 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 was 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 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, what’s wrong?’ Then we went around the room again, and the salesperson said, ‘actually, our intelligence is that nobody is going to buy this. But you all told us it was great. So we’re ready to go sell it, if it will work.’ The marketing people said, ‘we’ve already done surveys. Nobody likes this. This isn’t going to go anywhere. But you said to, 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, ‘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 staring out the window said, ‘actually, there’s something I see here. I don’t know what it is, but it’s not working.’ All of them were thinking, ‘well, if everyone else thought it was OK.’ It wasn’t OK. We didn’t launch the product. 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. 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 no trouble.
Jeffrey: And they happen at all scales. People who are technical might feel like this is not for them, ‘well, that’s managers and managers are about talking in boardrooms.’ This happens all the way down to when people are coding, to what the design is. 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, ‘do I feel comfortable raising this and raise my concerns or am I just going to carry on and hope for the best?’ This kind of insight and courage and contribution can happen at every level from implementation to strategy. Some times people dismiss this, ask ‘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 in over long discussions and long arguments they had that were very challenging, and they realised after analysis, ‘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 if your first response early on in that conversation was, ‘you know, I’m afraid that…’ Complete the sentence. 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. 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: It goes back to what’s important to you. I remember reading in Kent Beck’s Extreme Programming Explained, which was really transformational for my career, in the epilogue he made the observation that every methodology is rooted in fear, and XP reflected his fears. One of the fears that he had was making software that didn’t matter, shipping software that didn’t provide value. That really resonated with me. So what do you fear? We all have our fears about interpersonal communication and risk and how people might see us. But I really fear spending my life in teams where I’m not enjoying myself, making things that don’t matter. I’d rather risk some interpersonal discomfort in the moment to avoid that outcome. That’s why for me, investing in conversational skills has been a good investment. 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. I’m just soaking it all in. One thing that you mentioned a bit earlier, Jeffrey was the fantastic book, Thinking: Fast and Slow. One of the biases that he mentions is ‘what you see is all there is,’ where we have a tendency to believe, contrary to all evidence and all experience, that we have full information, right? If we try to tie that back into the original chronic DevOps conflict, the conflict between developers and operators? They say ‘as a developer, I worry that you are doing this 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, can see no good reason why you keep pushing this unstable, nonperforming, non-compliant B.S. over this fence for me to struggle with.’ We as an industry still have tons of functional silos, both horizontally and vertically and randomly dotted across the organisational landscape. So I think the thing that you’re bringing together here is just so foundational for all the things that we do in DevOps. 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 x, y, z.’ That’s such a powerful starting point for including people at the table earlier. 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?
Successful Structures
Listen to this section at 20:58
Johan: What I understand from your book is what I as an individual contributor can do. I think Atkins wrote Teamwork is an Individual Skill. But I know at this session we probably have some people who are managers who live in meetings and conversations. Could you talk a bit about some of your favourite structures or setting the frame for individual contributers. 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?
Jeffrey: It’s interesting because you talk about structures and this is not something that I talk about very much, because I think they’ve all been written. You mentioned yourself. More cross-functional teams, colocation, earlier collaboration. I think those structures are well documented.
Squirrel: 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: *Laughter.* But the problem is that, as I read many, many years ago from Alistair Cockburn of software methodologies, ‘every methodology can work and every methodology can fail.’ Now, some are more likely to succeed than others. I think ones that have colocation and early collaboration are all more likely to work. So it’s not about the structures. Actually I would say, 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 managers are just like 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 to understand what’s going on and that gives 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.