This is a transcript of episode 303 of the Troubleshooting Agile podcast with Jeffrey Fredrick, Douglas Squirrel.
What to do when your tech team isn’t arguing (productively!)?
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Podcast Feedback
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: So you had some constructive feedback I hear on our recent series.
Jeffrey: Yeah, that’s right. I have the great benefit of working with some people who listen to the podcast and, could get, you know, direct feedback on it. And so I wanted to share that. And then I think it leads to something, a bit of a follow up on the series we’ve just done. So this is, “I wanted to give you some feedback on your latest four part series. Overall, amazingly good stuff,” so I’m already very happy. This is clearly going to be good feedback. “Now, what makes it good is specific. So there’s two. One is, I liked part three on engagement, particularly, as that is an area I have the most to work on.” Okay, cool.
Jeffrey: And then they offered some constructive criticism. “Part four on the other hand,” this is on constructive conflict. They said “part four was very dense and more theory than practice versus part three. So even though I’d already seen the cat,” meaning they’ve already have covered this before, “but maybe I need to re listen to part four once more.” So on the basis of this feedback, and thank you very much for it. I went back and re-listened to part three and four to try to understand the difference. And I think what happened is in part three, we were very much giving people some concrete things to do. But then in part four we went very, very quickly and covered lots of models and frameworks and we mostly did it by referencing past episodes. So we brought in our own previous material.
Squirrel: You mean our audience hasn’t memorized every one of our previous 300 episodes?
Jeffrey: That’s exactly what came out of this! That somehow they didn’t have it really, you know, necessarily at the tip of their mind. So I thought-
Squirrel: I can’t remember most of them, so I’m not surprised.
Jeffrey: Right. So I thought on the basis of that feedback, we might actually do a bit of a coda to our series and maybe like a part four B where we can take that last episode and constructive conflict and just be a little bit more concrete. So if someone has never listened to any of our episodes, but they like this idea of constructive conflict, what could they actually do? What are some examples of introducing constructive conflict where it’s needed? So, no reference to past episodes. Just start from the beginning. What do you think about that, Squirrel?
Squirrel: That sounds great. So do you have any examples that we can work on?
Jeffrey: Well, I do actually, and this is something that came up very recently and it’s a really good example I think, because we talked about, you know, how you can have both unconstructive conflict and constructive conflict. And so this is kind of the process of going from one to the other. So the scenario is this, and I think it’s going to be one that I like because it’s very familiar. It’s one of the oldest conflicts in software development, which is, it was a scenario where essentially the product owner was upset because some feature delivery was taking too long and the developers felt blamed for that. And they said, “well, the reason it’s taking so long is because you keep changing what you want. You keep changing the requirements.” Have you come across this before, Squirrel?
Squirrel: Maybe about 200 times.
Jeffrey: Yeah. At least. At least so the they each had this unproductive conflict where based on they each had their own story and were blaming the other. You know, “you told me it was going to be done.” “Well yeah. But then you kept changing it.” So on back and forth. So the question was, how to move from unconstructive conflict to constructive conflict. So the constructive conflict is the idea that we’re going to bring in the differences of opinions, people’s different experiences, and get something positive out of it. So how can we do that when it seems like people are just at such loggerheads?
Timeline Retrospectives
Listen to this section at 04:05
Jeffrey: And so here’s what I did. I recommended to that product owner and I said, “well, look, here’s what I recommend you do. You have these different stories, what I would expect would be productive for you would be if you could bring those stories together. Meaning you could have each person tell their story and try to get to a set of shared facts. So that’s your goal. But the way that you’re going to get that set of shared facts is to get the facts that each person currently has independently. And I said, this is a little bit like what we do in a blameless postmortem. When we have an outage, we go and ask people, ‘what was what was your experience, what would you saw, what was the impact that you could see.’ And we collect things and we create a timeline even like here’s how things unfolded. So we’re going to do that.”
Jeffrey: And we did what’s called a timeline retrospective. And so what happened is each person was invited to add what they consider to be significant facts to a timeline that went over last quarter and up to today. And so what we had then was facts like, on this day we shared this document, we had this design, we did a breakdown. We created these stories, we had this specification document and so on. And each person could then tell their story. An important part here is that when they had their retrospective, I was facilitating. One important part is what I knew as a facilitator, and this is very important if you’re trying to get to constructive conflict, is when people would say something generic, I would ask them to make it more specific. So an example is they would say something like, “well, you kept changing requirements.” And I said-
Squirrel: On which day, in which document, and how.
Jeffrey: -Yeah, exactly. Give me one example of anything that changed. And then they would find something. It didn’t need to be the most important thing. It didn’t need to be the crux. It could just be like, “here’s an example. Here’s something that changed Tuesday,” you know.
Squirrel: And this is an important trick. So if you’re going to use this method, listen to what Jeffrey’s saying. Because what people will often say in this circumstance is, “well, it just happened all the time. I mean, it was every week, all the time, every sprint.” And then you’d say, “okay, great. So that means that we can identify one. So just tell me about one.”
Jeffrey: Exactly. Yes, exactly. So the idea is that when when someone says like, oh, this happened all time, great. Then, then we should have lots to choose from. But let’s just choose one. Let’s get a specific one down. And it was really interesting. And I think there’s two things that happened here. Well, first of all, there’s the obvious one, which is, different people had different facts. They could see different facts at different points in time. So for example, the product owner who has product managers working for him might be making changes that he wasn’t aware of. So, you know, essentially each person had part of the story. And then by seeing other facts that other people referenced that they hadn’t been aware of, they themselves already had a better view of the world.
Jeffrey: And I think this is actually often the the core of constructive conflict, which is when we bring in different facts that we weren’t previously aware of, our view of the world changes, and that’s what’s constructive. That’s where the constructive part comes out of it, is our world view changes because it expands to incorporate these other facts. But there’s a second thing that happened, I think that was more subtle, which is often when people would tell their own story and lay out the timeline with key facts, they often had insights that they hadn’t thought of previously, because they’d never put their own story together in a kind of concrete fashion.
Jeffrey: They had lived it. They had come through with different sort of opinions as a result. But seeing it laid out gave them a different perspective. And so that was that’s what we did. The retro lasted about 90 minutes because we actually did two parts. We first did, we covered one thing that went well and we said, “let’s talk about the elements that went well.” And then the second part was this, “let’s talk about, you know, what we think were events that contribute to things going poorly-“
Squirrel: There we go.
Jeffrey: “-On different feature sets. Yeah, exactly. So in 90 minutes, though, the product owner said, “well this is amazing. We’re never going to go so long between retrospectives again because this was so valuable,” so really demonstrated the value of that investment, a relatively small investment, you know, 90 minutes for a project that had gone on for, you know, more than a quarter. And people all felt as a result at the end, everyone felt very good about it. I got many feedback from different people in different roles saying “that was hugely helpful, that was very valuable,” and it went from a situation where many people were feeling very negative to one where people felt very positive. That sort of constructive conflict being exactly what we’re hoping for as the output.
Squirrel: And I would predict that the team now will not only feel better, but produce better, because, for example, they can say, “well, isn’t this like what happened in late August that we had on the timeline? And in that circumstance we did X and we said we’d do Y instead.” So they have the shared facts to refer to.
Jeffrey: Yeah, they have the shared facts, and they also now have the shared experience of having gone through something difficult and had a positive result. There was this story in their head that would be ‘those people seemed really unreasonable. But then we talked about it and actually, you know, we had a positive result.’ So they’ll have more faith in the future that they can work things out. You know, having having worked things out once, they’re more likely to be successful, have belief they can be successful again.
Squirrel: Excellent. So there is a bit of theory here. So we’ll just point to it without going into any depth. But something called the ladder of inference is an extremely helpful concept here, and we tend to call it for developers purposes, test driven development for people. So there’s this whole method of discovering someone else’s story and understanding it. And it starts with shared facts. It starts at the bottom of the ladder, where you agree on what you observed and what was important about it, and not what it means, what beliefs it led to, what actions resulted, but just what actually happened. And so many unproductive conflicts, and I bet many listeners will recognize themselves in their teams in this, start with non-shared facts, where one person believes one thing about the world and someone else believes something else.
Follow the Money
Listen to this section at 10:42
Squirrel: Now, this reminds me of a question that came up in my consulting practice where someone came to me and said, “boy, I just can’t get a handle on what’s happening in this team. Everyone tells me something different and there’s lots of conflict, but I can’t get a shared story.” So in that case, I didn’t use a timeline method. What I advised him to do was to go to the Chief Financial Officer. And figure out financially what was happening and to follow the money and what was helpful in that circumstance. He was going all over the whole organization, hearing different things from marketing and from sales and from technology and others. And you couldn’t track down the problem.
Squirrel: But it’s kind of like going to the doctor. If you go to the doctor and you say, “I just don’t feel like myself.” The doctor will not treat you, or give you a pill that’s labeled for people who don’t feel like themselves. The doctor will do some tests to get down to the bottom of the ladder of inference, and identify things that might be symptoms of a problem, like an elevated heart rate or a temperature or something like that. And if you don’t have any of those, the doctor will send you away and say, “tell me when you have some of those symptoms.” Because doctors can’t treat you for just kind of feeling yucky, or at least not good doctors, not legitimate doctors.
Squirrel: So in a similar way, almost every problem that I can think of in a business that’s important and in a nonprofit as well, wherever it might be, is going to show up financially pretty quickly. There’s going to be reduced revenue, increased attrition within the team, greater churn among customers, something like that, that the CFO or somebody in the finance department should know about. And so you can think of the finance department as kind of the vital signs of any business. And so if you really can’t figure out what to do, try talking to the people who are looking after the pounds and pence and the dollars and cents, and they should have some insights for you that can lead to shared facts. Because if you show up and say nobody’s buying our product, that’s a fact that’s difficult for people to see differently. Now they can see different reasons for it. You can go up the ladder of inference from there, but you’re unlikely to have disputes about whether people are buying the product or not.
Future Facts
Listen to this section at 13:05
Jeffrey: Yeah, that’s right. And it occurs to me too, is that even if the symptoms haven’t shown up yet. So look for the symptoms first. But even when you have these people’s stories, you can often ask them, well, how will that have financial impact? Because in my experience, when people are having conflict, because there’s something that they’re afraid is going to happen if it doesn’t get fixed, you know? And so even if it hasn’t shown up yet, you can ask them, well, what? You know, kind of in a sense so what? What will happen if we don’t fix this? And then you’ll hear stories like, well then this person’s not going to sign their contract, you know, and or see consequence X, you know, we’re going to have more attrition or we’re going to have churn or whatever it’s going to be. Those things, even if they haven’t happened yet, are often the basis of people’s conflicts and concerns, because they can they foresee these things happening.
Squirrel: Indeed. And that gives you a greater understanding of their thinking. Be careful, though, because often you’ll get inflated versions of the future. “Oh my gosh, if we don’t adopt this new software library, our entire software stack will fall over and no one will be able to log on at Christmas when our biggest sales are.” And if you go investigate that, you find out that they’re basing that on Facebook and your company is not Facebook and you don’t have the volumes that they do. So take it with a grain of salt, what you hear when you ask for future facts and the future beliefs of people in your team. Objective facts that are actually happening that you can point to on a balance sheet, those are stronger, if they exist.
Jeffrey: Yeah, 100%. That’s a really good point in how you go from actually then even then to say like, well, you have this story, but you know, the facts don’t support it. But that’s finding current facts that are actually happening does have a fantastic way of sharpening people’s minds and then getting to that constructive thing. “Okay. Yeah, we know we agree. These are the facts. We agree this is a problem. Now what are we going to do about it?” Which is where all the the juice comes in of constructive better outcomes.
Squirrel: There we go. Well, if more listeners would like to critique us and tell us that they don’t understand what we’re talking about, that would be wonderful. That would be a very constructive conflict. So we’d very much like to hear from you. And then the other thing to do, of course, is come back next week when there’ll be another edition of Troubleshooting Agile and we’ll have more constructive conflict and ideas for you. See you then. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.