Making Software Development Teams Hum with Ron Lichty

Episode 41

Is your team running so smoothly that it hums? In this episode of Programming Leadership, Marcus and his guest, Ron Lichty, discuss what makes high-performance teams versus what makes low-performance teams. Most teams already know which category they fall into, but the solution to a low-performing team isn’t always clear. Drawing on 20 years of Agile experience, Ron narrows down the three root causes of low-performing teams as well as solutions that managers can implement to improve them.

 

Show Notes

• Learning what makes software development teams hum (1:40)
• What prevents a team from humming (3:31)
• Building effective stand-ups (10:32)
• Do < Accomplish (15:43)
• The high value of predictability (19:28)
• Implement the “fist-to-five” to your stand-up (23:50)
• How to observe psychological safety (29:28)
• Misunderstanding so-called “introverts” (31:31)
• Planning is every team member’s job (36:58)
• Providing value for stakeholders is an infinite game, not a finite one (38:44)

Links

• Finite and Infinite Games, James P. Carse
• Managing the Unmanageable, 2nd Edition, Ron Lichty
• https://ronlichty.com/
• http://managingtheunmanageable.net/

Transcript

Speaker 1: Welcome to the Programming Leadership podcast, where we help great coders become skilled leaders, and build happy, high-performing software teams.

Marcus: All right, welcome to the show. I have Ron Lichty here. Ron is an amazing, amazing resource that I am so excited to bring to you today. But before I introduce him, I need to do a little bit of housekeeping. I just want to ask if you’re listening and you enjoy the show, please support it by giving us a review wherever you listen to podcasts. You can also drop us a line at Marcus at marcusblankenship.com. Let us know your thoughts or any questions you’d like us to answer on the air. We appreciate your support.

Marcus: Ron, thank you for coming on the show. I know we hit record in the middle of our conversation, so we’re kind of backing up, but let’s back up to the beginning. What is it that you do when you help companies?

Ron: My goal is to help software development teams to help product teams, those software development teams that are developing products and those that are developing services across the board help software development teams to hum.

Marcus: Hum. That reminds me of when I was a kid and my dad would say, “Hey, come listen to this engine. I’ve got it really tuned up,” and it wasn’t knocking and it was quiet. Of course humming has a variety of means, but when you think about a software development team that hums, what kind of attributes come to mind?

Ron: Most people on software development teams have a sense of whether their team is humming or not. So I co-author the study of product team performance and we are launching a sixth survey of people on product teams all over the world. We do a survey of developers, and product managers, and product owners and scrum masters, and testers, and just all the people who are on product teams. And we ask them, “Characterize your team. Is it a high performing team or a low performing team or somewhere in between?”

Ron: Then we ask them about practices and we correlate to see what practices that those teams that are high-performance or low-performance do or don’t do. And so it’s been a very interesting process over the course of the last five or six years doing that. What we find is that people have a pretty good sense of whether their team is humming or not, whether their team is high-performance or not.

Ron: I talk to developers. I give a lot of talks. Aside from talking to you, Marcus, I give a lot of talks and in some of those I’ll ask people to characterize the best team you’ve ever been on. And generally speaking that is a team that hums. It’s a team that’s high-performance. It’s a team that and the two words that always come up are trust and respect. We may have words like “psychological safety” come up. We may have phrases like, “My team had my back.” Oftentimes we’ll have a really clear understanding of shared mission. There are a lot of things that constitute humming.

Marcus: Wonderful. This sounds like a really amazing study. You’ve been doing it now for six years, is that right?

Ron: Yes.

Marcus: Are there some anti-patterns you hear when people feel like their teams aren’t humming or is it just the opposite of everything you listed?

Ron: I’ll give you a few. One of them was really interesting. I was not a co-author of the very first study. This will be six now, that I was not a co-author of the very first study. The very first study they came up with five things that correlated with high performance teams. One of those was onboarding, effective onboarding. I sort of complained about how there wasn’t a software development voice in this survey. It was heavily product managers and project managers who were stating the findings. And so they promptly recruited me. So be careful what you ask for.

Ron: In the second one, one of the things we observed was, well, if onboarding is one of the things that correlates with high-performance teams, well, let’s ask teams about, do they characterize their onboarding as a best practice? What we learned was, and I don’t remember the exact number, but it was something like 7% of teams are willing to call their onboarding practice a best practice.

Marcus: 7… let me make sure I understand.

Ron: 93% do not.

Marcus: We got a hundred people who respond, seven of those people are raising their hand and saying, “I think the way we onboard people is one of our best practices.” Which tells me it’s working, it’s effective, it’s efficient, whatever the metrics are, the best part. 93 people leave their hands down.

Ron: Yeah. You think it might be a low hanging fruit?

Marcus: I’m starting to see an opportunity here.

Ron: All right. Let me go onto a second one. You asked about several, so let me give you two more and then we can talk. It occurred to me, so I’ve been training teams in Agile for 10 years now, a little over 10 years now. I’ve been engaged with Agile for 20. And very early on, maybe from day one of 20 years ago, I don’t know, but somewhere early on I learned about Definitions of Done, that teams create a Definition of Done for all of their work. Every single story meets their Definition of Done. And we would do that because if we don’t do that, we’ll have some developer who says, “Well, I’m done. It works on my machine,” or, “I’m done. It compiles.” I’ve actually heard that.

Marcus: Me too.

Ron: Or, “I’m done. I checked it in.” I’ve heard that one too. And so we get all of these really broad range of Definitions of Done as opposed to having one that we all agree on. About three or four years ago, it occurred to me, this may be one of the most powerful practices at Agile. And so I thought, “Why don’t we test that? Why don’t we ask in the study about Definitions of Done?” Instead of asking, “Do you have one?” We asked, “Who creates your definition of done?” We got some really interesting results.

Ron: What we found was that those teams that do not have a Definition of Done at all, correlate with the lowest performance teams. Just having a Definition of Done does not correlate with a high-performance team. The Definitions of Done that were written by the team correlate with the highest performance teams.

Ron: This correlates probably with some experience you’ve had of senior management somewhere handed you a Definition of Done and said, “Here’s what done means.” You probably read it, I read it, probably most of us read it. We promptly 3-ring binder-punched it and put it in a 3-ring binder and put it up on the shelf and never saw it again.

Ron: When we create a Definition of Done together, we’re going to craft that onto a flip chart page or something of that equivalent. We’re going to put it up in our team room. We’re going to all look at it every day because it’s an agreement that we all have with each other and we’ll hold ourselves accountable to it. Very different from being told what the Definition of Done is and very different from not having one. So there’s a second example.

Marcus: Yeah. That’s really interesting. So if you don’t have one that’s not necessarily correlated with the worst teams, but-

Ron: It is. Not having one correlates with the lowest performance teams.

Marcus: Okay. Having one handed to you, does not. But just like you said, just having one doesn’t really make a difference. It’s how it comes to be.

Ron: Yes. It’s the creation of it.

Marcus: As you facilitate, I’m imagining then it’s probably part of your work is to help teams create their Definition of Done, I’m sort of assuming here. But as you do that you are oftentimes in the role of VP or fractional CTO or you’re the person who’s, I’m guessing the highest “ranking” person amongst the team. What do you look for in a Definition of Done that a team creates for itself?

Ron: I ask the team that, and the team has developers, testers, product managers, product owners, sometimes a documentation writer. It could be, whoever is on the team can together define what that is. I’ve discovered that Intuit has a couple of acronyms for things that they look for when they build Definitions of Done. I’ve forgotten what the acronyms are, but they look for things that often go wrong and they look for things that might go wrong that they can’t afford to have go wrong.

Marcus: Okay. So they’re taking the perspective of, what’s happened in the past? What would be a terrible thing to happen? And so we want to make sure we cover those items in our Definition of Done, so those get included. All right. Do you have a third item that you’ve learned from this study that sort of stands out, that is a big differentiator?

Ron: Yeah. Stand-ups. It turns out that those teams that do not hold stand-ups correlate with the lowest performance teams. Let me clarify that. That say they do not hold effective stand-ups, correlate with the lowest performance teams.

Marcus: I think that’s an important word.

Ron: Then, those teams that say we do have effective stand-ups, the relationship to performance is linear with the frequency of the stand-ups, up to daily. So those teams that are holding effective stand-ups every day, correlate with the highest performance teams. It sort of makes sense, right? I mean software development is a team sport, then it sort of makes sense that we talk to each other at least once a day?

Marcus: It does. I want to find out, do you have some opinions or have you found some practices that build effective stand-ups? Because I hear a lot of complaints about stand-ups.

Ron: The two things that are most egregious are, stand-ups that last longer than 15 minutes and stand-ups that are not held standing up. I run into that every once in a while. No, and a third one, which is stand-ups held by a Slack.

Marcus: Well, that’s very popular with the right, I mean remote teams, I hear them called asynchronous stand-ups. But you’re saying that people who like these asynchronous stand-ups, well at least that’s how I’ve heard them called when they’re in Slack or even if they’re synchronous. But what is it, do you think about that form of communication or that channel? Something’s going wrong there.

Ron: It’s not the channel, it’s the fact that what the stand-up has devolved into is a status meeting, and given that it’s a status meeting, why not just share it on Slack? Now, the problem is the stand-up is not intended to be a status meeting. Stand-up is intended to be a re-planning meeting.

Ron: If you go look at the definition of “scrum” in rugby, scrum is a way of restarting the game. In fact, the stand-up is called a daily scrum by many teams, and it’s called a daily scrum because we restart our game every day. The goal of restarting the game means that we’re coming back together to find out how we’re doing on our two-week plan, and I’m saying two weeks because that’s what most scrum teams do these days. But it could be our one-week plan or our three, or four-week plan depending on how long our sprints are.

Ron: But we’re coming back together just to ask the question, how are we doing on that? And so there’s some status that’s got to do with that, but there’s some responsiveness that has to do with that too. If I report in Slack that my two-day task is turned into an eight-day task, I’m in deep trouble. Two, our sprint plan’s probably in deep trouble because I probably have six other days I had thought that I was going to work on something else, then I’m not going to work on something else if I keep working on the thing I am now.

Ron: And so the question is, is there somebody else who can ride into the rescue, who can help me out, who can have my back? And that happens in real time meetings. It does not happen effectively by asynchronous channels.

Marcus: It reminds me of so many projects where I did not find out that a two-day task had become an eight-day task until day eight. And at that point it seemed very hard to make a change, because you’re now looking backwards saying, “This thing I thought was two days has taken me eight days and I think I’m almost done.” What I oftentimes heard was for seven days I heard, “Yeah, I’m working on it.”

Ron: Right. And so that’s part of the problem. And so in training I ask teams all the time, “So what are the three questions?” And the answers I hear back all the time are, “What did I do yesterday? What am I going to do tomorrow and what’s standing in my way?” Now, what’s standing in my way is pretty clear, and most of us do a pretty good job of that part or a reasonable job of that part, at least.

Ron: The problem with do and doing is there’s no… Well, what I want to hear is “accomplish.” What did I accomplish yesterday out of that two-day task? What do I need to accomplish by tomorrow and what do I intend to accomplish by tomorrow in order for that two-day task to take two days? That’s useful information so I’m all the time walk into teams and somebody will say, “Well, I worked on the blank blank subsystem yesterday and I’m going to keep working on it tomorrow.

Ron: Well, it gives the team no insight whatsoever on where that person’s at. The goal is always, how are we doing against our plan? This is a time for the team to come together and identify whether it’s still on its plan or not, and whether any other members of the team can help out those who are in trouble. Because software development is not easy. It’s not predictable. It does have two-day tasks that take eight days. There’s nothing wrong with that, except that what’s wrong is if we don’t identify that this is happening and respond to it. Do some re-planning.

Marcus: Yeah. When you hear somebody say, “I’m going to work on this again. I worked on this yesterday and I think I’ll work on this again today.” And they’re very vague. Kind of trying to use the same example you used. If you’re the coach in the room, if you’re the executive, whatever it is, if you’re in there trying to help them improve, how do you draw out? Do you have some favorite ways that you sort of draw out more detail that you help the team recognize what it’s doing and then improve right then?

Ron: I just change the word from “do” to “accomplish.”

Marcus: So then they say, “Well, I didn’t accomplish anything yesterday.”

Ron: Okay, and so can you accomplish the rest of what you intended to accomplish in your day two-day task by tomorrow?

Marcus: And they say, “No, I can’t. I cannot accomplish it.”

Ron: All right, so can anyone else help?

Marcus: Now, that-

Ron: You’re going to be signed up, you’re going to be signed up for 10 days of work, probably in a two-week sprint. That’s logical. It might be nine days or somebody might be optimistic and say, “I think I can squeeze 11 days of work into 10 days.” Which is not a very good idea, but it does happen. But usually you’re signed up for two weeks worth of effort and you’re saying, “Hey, I’m not on plan.” So the question is, can somebody else help? Somebody else may be ahead of plan. Susie, or Sally, or Bob, or George maybe in fact have accomplished what it is that they needed to accomplish in three days and two and they can come riding and help.

Ron: On the other hand, if no one, if everyone’s over, then this is instead of getting to the end of the sprint and randomly not having something done, why don’t we give that heads up to our product owner to say, “We’re not going to finish something. Which thing should we not finish? Let’s make a choice. Let’s be conscious about this and about what it is, what it is we need to finish in order to convince our customers that we’re making progress. In order to convince our executives we’re making progress. In order to convince our stakeholders that we’re making progress.”

Marcus: Yeah, I hear from executives, I mean I’ve heard this a lot. I’m sure you have too. The idea of, “Well, our team hasn’t made its commitment in six sprints and so we’re just really hoping they finally figure out how to do this.” There seems to be something I don’t think they’re acknowledging in the middle when there’s a problem. They’re probably waiting till the end and they’re like you said, and it seems like it requires a certain amount of safety in the room to be able to say, “I’m not going to get it done and I need help,” or “We’re all not going to get it done.” This whole thing didn’t, and it’s even harder maybe when it’s like… and this is not the first time. This is sprint four in a row that we’re not going to get it all done because it seems like at some point people start saying, “Well, who’s the low performer?”

Ron: If this is sprint four in a row, we’re probably, this is a telltale sign of inability to plan, and so we need to work on planning. It could be a telltale sign that the team is doing stretch goals for itself. It could be a sign that there’s outside pressure for the team to do stretch goals for itself. It could be that we’ve allowed velocity to leak outside the team and somebody is watching from outside the team says, “Oh, well, velocity should go up.” Not the case, but somebody is saying that and the team is responding by posting a higher velocity of stuff to do in the next sprint and consistently doing that.

Ron: What teams too often don’t realize is the extent to which predictability is valued, and that predictability is way more valuable than delivery. Progress, the ability to predict progress, the ability to show progress, gets executives and stakeholders and customers to say, “These people know what they’re doing.” They predict what it is that they’re going to do and then they deliver that.” Teams need to be doing that at about maybe 80%, you can miss one out of four, one out of five. That’s reasonable. We’re in an unpredictable kind of thing. But if we’re missing more than one out of four, one out of five, then our planning process sucks and we need to fix it.

Marcus: Yeah, I was going to say, well, first I’m curious, why do you think teams devalue predictability?

Ron: I don’t know that they devalue it as much as they just don’t understand the extent to which that counts for executives, and stakeholders, and customers.

Marcus: So it’s tremendously powerful. As soon as you said it, I thought, well, yeah, I mean every person I’ve talked to who feels like their software team isn’t doing as well as they thought wasn’t necessarily asking for more. But it was just a matter of feeling like nothing ever gets done on a schedule I can plan for. And so it all seems like it’s at the whim of somebody.

Ron: What teams hear, what I think most of us hear, when we hear from our stakeholders and our executives, is more, as opposed to predictable. Most of us need to switch that to think about what we really need to deliver is predictable and progress, and it’s visible progress. It’s why Agile emphasizes, why Agile stories emphasize every story should show business value. And it’s because if they show business value, if there’s some visible value to every story, then you can demonstrate, you can visibly demonstrate progress, and you keep your executives and your stakeholders, your customers out of your team room.

Marcus: When you come in, let’s switch gears and you work with the team and you help them and things start to hum, because you are a wizard and a guru and you really help these people. I know you don’t like those words, but now the reality is that they definitely get a lot of help out of it. How do [inaudible 00:22:13] feel when things go from clanking to humming?

Ron: Relieved. Relieved. Usually relieved. Relieved, inspired, enthusiastic, excited to be coming to work again.

Marcus: Really?

Ron: Yeah.

Marcus: I’m curious of your thought on this. I have kind of a belief that, and I think I talked about this a little bit at the nice conference you asked me to speak at, but that all these wonderful people building software are really highly motivated. It’s just that all that knocking around, maybe you think about it like that, the lack of humming, the lack of predictable and productive and feeling like we’re high performing, it really does rob us of our motivation.

Ron: Yes. All that knocking, that’s really interesting. Knocking in that engine that you were talking about your dad letting you listen to. That’s a good addition to the metaphor. It’s painful to listen to an engine knock.

Marcus: That’s what I was thinking.

Ron: It’s painful to be on a team that has knocking, and everybody knows it. They’re just not sure what to do about it. There are so many. I mean, changing the word do to accomplish, is so nuanced. It sounds, well, you’re just changing a word, but words have meaning. It’s the smallest nuance and yet it’s really significant.

Ron: The other thing that I’ve been teaching teams to add to their stand-ups at the end of every stand-up is to do a fist-to-five.

Marcus: What is that?

Ron: Every member of the team holds up some number of fingers to represent their response to the question, “Do we have confidence that we’re going to make our sprint plan? “

Marcus: Do we have confidence? So then like a fist is zero?

Ron: A fist is zero, and if I hold up five fingers, I am totally confident we’re going to make our sprint plan. Four, I’m pretty confident we’re going to make our sprint plan. And so if we don’t get fours and fives, let’s keep talking about this until we do. It may be that we’re going to take something out. It may be that Sally’s going to have my back because I’m behind and what I accomplished isn’t enough to make the sprint plan, and somebody else needs to step in and it’s Sally, or Sue, or Bob, or George because they’re doing okay or we need to take something out and we need to talk to our product owner now about it so that they are explicit about which thing to take out that will still show our stakeholders, executives, and customers the progress that we need them to see in order to have confidence in us.

Marcus: I feel like you’re creating these little… my dad actually at times listened to the engine. It wasn’t quite a stethoscope but he would have ways of listening to different parts of the engine. I don’t know why I keep going back to this metaphor but like the fist-to-five is a way of getting information. Confidence is important. The team knows when they start to erode confidence. Asking what did we and what will we accomplish? Those are like ways of sensing, of getting that information.

Marcus: Do you have any other tricks for… because sometimes it seems like for a manager the team can seem a little bit opaque. It’s just kind of happens in there. I love these tips you’re giving us these ways we can find out earlier than at the end what happened.

Ron: Yeah. I’m going to add one more thing about doing the fist-of-five at the end, is that the go-around and as part of why teams say, “This is just a status meeting.” And end up relegating it to Slack, that go-round is about me. Even if I say, “What did I accomplish? What am I going to accomplish and what’s standing in my way?” Even if I do that, it’s about me. It’s not about how we are doing on our sprint plan.

Ron: Fundamentally, the stand-up is not about me, it’s about us. It’s about us as a team. It’s about what we’re going to accomplish. It’s about how we’re doing on our sprint plan. And if I’m behind, can the team have my back? And if I’m ahead, can I have somebody else’s back? That only happens by having a meeting. It only happens by us being together and having that conversation together.

Ron: The fist-to-five makes a fundamental shift if we do the go-round and then we do a fist-to-five, it makes a fundamental shift from, how am I doing to do I have confidence that we are going to make our sprint plan? And it’s made the shift from I to we. I think that’s a really significant, really important shift for teams to be able to make, and one that brings us back into the we-space, back into the high performing team and that best team that we’ve ever been on kind of space.

Marcus: Everybody wants that. Then after stand-up, maybe we have some more discussion but people sort of peel back to their computers or they start on their work for the day. I love this idea-

Ron: We only take 15 minutes out for the stand-up and it’s, yeah.

Marcus: It’s fast, right?

Ron: Yeah. Or we identify some issues and Bob, and Sue, and George are going to go explore those and does anybody else need to do that? But we’re not going to do that during the stand-up and waste everyone’s time.

Marcus: I’ve noticed that probably because the way we educate humans starting from grade one that work is individual going through college, don’t cheat. Projects are individual and you stand on your own merit, that programmers have some sort of default assumptions when they enter the workforce that it’s not a team sport. I’m curious to go to that topic if you found that there are ways to… it’s a great phrase that software development is a team sport. I’m sure it’s true, but I think there’s a lot of people who would not feel like they’re acting that way. They’re not even maybe sure they want that. Do you see this and how do you start to move that mindset?

Ron: Well, the moving of the mindset is partly that fist-to-five, that shift in everyday so that we’re actually acting like a team every day. It goes to working as a team. Google did this wonderful study three years ago, the Aristotle study. I find remarkably few people have heard about the Aristotle study. You and I both have, but remarkably few. I’ll ask for a show of hands and I’ll only get a couple of hands. And yet the two words that came that have become enormously common in our parlance did not originate there, but moved from two words that we didn’t hear in software development to two word hear every day in software development, and that’s “psychological safety.”

Ron: One of the interesting things about the Google study was they basically said you can, we, you and I can, anyone can see whether there’s psychological safety, because psychological safety can be visually observed because those teams with psychological safety have about an equal amount of turn-taking by every member of the team.

Ron: Every member of the team speaks for about the same amount of time. There’s no dominant speaker, there’s no silent person on that team. Everybody speaks about the same amount of time. And so we can actually observe whether our team is a psychologically safe team.

Ron: Now, I should back up a step and say, what was the Google study? The Google study, the point of the Google study was that Google, like everybody else has high-performance teams and low-performance teams. Google, unlike everybody else has a ton of money and they study everything. And so they set up this study to study, why are some of their teams high-performance and some of their teams are low-performance. What differentiates those?

Ron: They went into it thinking that they were going to find, “We have a 10X developer or they’re all 10X developers or there’s some percentage of 10X developers, or there’s some amount of diversity or there’s some lack of diversity. They were looking at team makeup thinking they were going to find it there. They didn’t find any correlation there at all. What they found was those teams with psychological safety tended to be the teams that were the highest-performance teams. There was a direct correlation between psychological safety and high-performance.

Marcus: This idea that it’s visible means you don’t have to have a fancy survey instrument or you don’t need a statistics degree. It means that if you start paying attention, whether you take little tick marks with how often, how many people talk, if you were to record the number of minutes, but you start to get a sense of, is the space really shared?

Marcus: I think that’s so interesting and important because when I talk to most people that have a few team members that don’t speak, what do you think they think about those team members?

Ron: What do they think about those team members, Marcus?

Marcus: They think they’re introverts. They say introverts don’t speak. They just don’t like to talk. They’re introverts or they’re checked out. I mean, they either attribute it to personality, introversion, extroversion, something that they look at, or they attribute it, I don’t want to almost say malice, but this idea of they’re not engaged.

Marcus: But the idea might be me, there is no more air left in the room, that someone else has taken all the cycles that it isn’t shared. I think you’ve got to just leave space as a starting point to allow other people to have anything, a place to speak.

Ron: Both space and expectation. I talk to teams during training and as a trusted advisor, I talk to teams about psychological safety. I talk to them about being self organizing teams where the team itself will be deciding how to tackle stuff. Not their manager, not their product manager, but the team itself will figure this out. And the way to figure that out is to be a self-organizing team, and the self-organizing team means that every single member of the team needs to be a leader.

Ron: When the Google study came along and said there’s psychological safety and there’s equal turn-taking among all of the members of the team, I thought, “Oh, that’s really consistent with what I’ve been thinking about self organizing teams.” The metaphors I’ve used have been jazz groups in music and improv groups in acting. Because what you see in jazz groups and what you see in improv groups is, every single member will lead.

Ron: In a jazz group, everybody solos. No two people solo at the same time, but everybody solos. Similarly in an improv group, everyone will lead. And if you’ve ever done improv, you know that you’re listening for an opportunity to continue but turn the group in some way. If you find the opening to do that because it’s the right thing for the group to be doing, and you’ll start that leadership, you have to continue listening for somebody else to do the same thing. And so the leadership passes transparently back and forth among the members of an improv group or among the members of a jazz group.

Marcus: I love that there are some of the… I’ve heard both of those analogies before and it also reminds me what I’ve heard about how, this is a military metaphor and I like yours much better, but how the Navy SEALs have something called dynamic subordination, which says when we’re out on the field, all rank is removed. The leader is the person who knows the right next move. It’s kind of a flocking idea of if you know the right next thing, do it and the others through trust and a lot of training.

Marcus: This doesn’t come naturally to us. I mean, we know that jazz groups, and improv groups, and military squads do a lot of training with one another. But I think you’ve kind of boiled these into simple rules about listening and remembering that there’s no soloist at the front of the jazz group. Everybody is going to be given that time to shine.

Ron: Yeah. Absolutely. Absolutely. I’m no sports guy, but I had a management coach who put a sports connected book into my hands 20 years ago, a book by a guy named Phil Jackson, who was not a familiar name to me at the time. Phil Jackson took on coaching the Chicago Bulls when the only basketball player, probably whose name I knew, Michael Jordan was on that team. Michael Jordan was setting every record in shooting and the team was losing pretty consistently.

Ron: His job, Phil Jackson’s job as a coach was to bring them together as a team that won games. It wasn’t about shooting, it wasn’t about Michael Jordan, it was about being a team. He then went onto the LA Lakers and did the same thing with them. He talks about how when his team is firing, not only does the other team not know what they’re going to do next, “My team,” he said, “Doesn’t know what it’s going to do next.” Because they’re always playing in the moment and they’re always looking for the right next thing to do, and each member of the team is playing off of the others in an improv or jazz kind of way, or scrum team kind of way.

Marcus: I like how you brought that back, which means that if we go back to that basketball, Phil Jackson, it’s not that he had a great plan at the beginning of the game. It’s that he had team members that could re-plan as they went for what is right, what’s the right thing to do now.

Ron: That’s right. That’s right.

Marcus: I do get this sense amongst software teams that sometimes programmers do think that planning is someone else’s job because that’s been done behind closed doors, the scrum master, the whatever, maybe the manager comes and says, “Well, I have the next plan and your only job is to execute or maybe to estimate it.” I love this idea that maybe it’s everybody’s job to plan.

Ron: Absolutely. It is everybody’s job to plan. If we’re doing Agile well, our product owner has given us a really good picture of where the value lies. They have ordered the backlog in order of what’s going to deliver the most value to our customers, and all we need to do is pick stories off the top and put them into our plan.

Ron: But that may not make the best plan because the stories on the top might all be web development or they might all be database development and we’ve got a team that’s got a database developer, and a web developer, and a business logic developer. And if everything’s database development, then we’re going to be pretty inefficient. Our web developer and our business logic developer might be pretty inefficient at doing database development. And so as a team, our goal is what’s the most effective plan we can create?

Ron: The product owner’s job is to think about, and what’s going to deliver the most value that’s going to keep our customer, stakeholders, and executives at bay? I put it that way but the flip side of that is and keep them convinced that we are a successful team, that we’re making progress, that we’re doing the things we need to be doing and that we’re predictable.

Marcus: There’s a wonderful book that comes to mind called, Finite and Infinite Games. I think it’s James Carse wrote it maybe 20 years ago. He talks about how in a finite game, it’s like a soccer game. You know all the people on the play, there’s only a certain number of people on the field. The rules are clear. The rules don’t change. Winning and losing is clear and it has a start and an end, and everybody agrees when we start and everybody agrees when we end generally. That’s what winning looks like.

Marcus: But in an infinite game, the rule is to just keep playing as long as you can. It’s the idea that things are going to change. There’s always new players, new priorities, new strategies, things you didn’t think of. But instead of saying we only have a certain amount of time and then we’re done, an infinite game will continue, and that’s the whole goal is just keep playing.

Marcus: That kind of reminded me of the way you said that was, every time we consistently go to the stakeholders and we get to show them value, it’s almost like we are participating in an infinite game. We are saying, “Yes, we get to do this again. We’ve earned the right, we’ve continued to produce.” We may not be the best team in the world, but we are consistent. We’re showing value, and it’s almost like you get to do that, get to repeat that cycle, well, until something happens.

Marcus: I don’t know. That’s what it reminded me of, but the game is different. It doesn’t usually have like well, we’ll do this 10 sprints and then we’re done. At least most teams I’ve been on, if they try that, they don’t usually accomplish it in 10 sprints, at least.

Ron: I think whether it’s finite or it’s infinite, I don’t think that for the most part, teams have a good sense what the rules of the game are. Your discussion of that really prompted that thought and you named it, the rule of the game is getting to do another sprint. The rule of the game is getting to continue. The rule of the game is having your fans be fans and not down on the field booing or running onto the field to tell you what to do.

Marcus: Right, or leaving the stadium and saying, “We’re done with you.” Business kind of usually wants to exist in an infinite game. It says, “Well, you get a customer and you earn that customer’s loyalty and of course you want more customers.” I think it’s really interesting the way you framed it, what if scrum teams, if agile teams said, “Our goal is just to keep playing.” And in order to do that we have to understand the metrics by which that decision gets made. I think you hit the nail on the head, like consistency seems like it’s one of the unspoken simple rules that other people use to say, “Should we do this again?”

Ron: Yeah. Consistency in showing progress, and consistency in showing progress in delivering customer value.

Marcus: But it’s not talked about. Oftentimes the programmers, everybody thinks, well, the goal is something else, which makes it confusing to work in a system like that when then you don’t understand why certain rules are being applied.

Ron: Absolutely.

Marcus: Deep stuff, Ron. This has been great. Wow, I’m just sort of speechless. This was so much fun. I just want to thank you for coming on the show. Tell us the name of your amazing book and where people can find you online.

Ron: The book is, Managing the Unmanageable: Rules, Tools and Insights for Managing Software People and Teams. It is, I think last week came out in a second edition.

Marcus: Congratulations.

Ron: The digital version and the print version is coming out in two weeks, maybe three weeks at the beginning of December is the release of the print version. This is Addison Wesley, it’s Pearson, is releasing the second edition. In the first edition, it was through four printings and got translated into two different dialects of Chinese and one of Korean. So now we’re bringing out a second edition that has some new and interesting and updated information.

Marcus: We’re going to put a link to it in the show notes as well.

Ron: Great. The Study for Product Team Performance, we’re just launching a new survey and so I’ll give you a link and invite everyone to participate in the study if you participate. If you participate in the study, we are going to give out some Amazon gift cards. But the big thing that you get back is you get back the results. If you participate in the study and tell us about your team, we’ll share the results of the teams across the board back with you. That’s a really cool thing.

Ron: Then contacting me, I’m at ronlichty.com. R-O-N-L-I-C-H-T-Y.com. And at managingtheunmanageable.net.

Marcus: Wonderful. We’ll put all these links in the show notes. You know, Ron unexpectedly, I think just our little conversation today renewed my belief in Agile. I hear so many people talking about it, it’s not positive, they don’t believe in it. One thing or another. Just the way you talked about it, you made it so humane, and simple, and reasonable, and you reminded me of what’s important. I just want to say thank you.

Ron: So much opportunity for self organizing and a way of working that is very humane, and very team-oriented, and very human being oriented. There’s so much that masquerades as Agile out there that is, I think what gets the bad rap.

Marcus: Beautiful. Thanks for being on the show today.

Ron: Thanks, Marcus.

Speaker 1: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com in on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.