We talk Esther Derby about why organizations find change difficult, how to lead positive, productive change, and the role of retrospectives in making teams better.
Transcript
Frank Days 00:02
Joining us is Esther Derby. She’s a consultant and author who draws on four decades of experience leading observing and living organizational change. She has been particularly active in the Agile community serving two terms on the board of the Agile Alliance and co-authoring a book called Agile Retrospectives: Making Good teams Great. Her latest book is Seven Rules of Positive, Productive Change: Micro shifts, Macro results. Esther, thanks for joining us today.
This episode, we’ll talk about why organizations find change difficult, how to lead positive, productive change, and the role of retrospectives and making teams better. So let’s get started. Jim.
Jim Ewel 01:07
So Esther why exactly is change difficult for many, if not all, organizations?
Esther Derby 01:13
Well, I think there’s a lot of reasons. But if you think about it, you know, people make changes all the time, right? So, change is not inherently difficult, you know, change happens all around us all the time. People choose change all the time. Often, it is the way companies go about it, that creates friction and makes it more difficult. For example, I see a lot of changes where a dictate falls from the Elysium, the corporate Elysium. And people have really no context, no understanding about what it’s about, you know, they might get some talking points, but they don’t have a deep understanding of the rationale. So you know, that makes it more difficult. Sometimes people are asked to make, you know, enormous changes, but yet keep up their previous workload. That makes it more difficult. Sometimes companies say they want to do something very, very different, like maybe, for example, that they want to be Agile. And so they overlay a process on top of all of their existing patterns. And they don’t address the patterns. And so the patterns reassert themselves that makes change feel difficult.
Jim Ewel 02:31
In some sense, I hear you saying it’s that people resist being changed. It’s not that they resist change. Is that right?
02:39
Well, I think that’s generally true. I mean, I don’t think any of the three of us here would particularly like it if someone we don’t know particularly well comes in and tells us to start doing things very differently when we have developed expertise in it for many, many years, which is often how it feels in organizations. Someone who doesn’t understand your work comes in and tells you to do it differently. I’m not crazy about the word resistant, people don’t resist change, they respond to change. Most people don’t like being pushed or told to change, as you just said.
Frank Days 03:15
In your latest book, you talk about two lessons you learned early on about change, that any given change might be positive for some and negative for others. And the second one being that change is ultimately a social process. Can you elaborate on those two lessons a little bit more?
03:34
Sure. Well, the story I tell in the book is about the first program I put into production, which was a program to automate an estimating process to making the decorative tape that goes along the sides of cars, I don’t know if it’s still a thing. But you know, that used to be a thing. You manufacture these decorative tapes and going cars. It was a very mathy program. And I overheard a conversation between the chief estimator and the head of the company the day before that went into production. And, you know, the chief estimator agreed that it worked, and it was faster, and that was accurate. And he still hated it. Because it was going to completely change the way he did his job. And his job had involved, you know, a lot of interaction with customers a lot of interaction with the shop, and, you know, working out estimates by hand and he loved it, he loved his job. And we changed that. So it meant to you know, less time talking with people more time sitting in front of a computer. It was a good lesson to learn early in my programming career. So, I think that going back to why change is sometimes difficult is people often don’t take that negative space into account that even if the change is great in the long run. It may have temporary losses, people, you know, may feel like “I don’t know how to do my job anymore. I feel incompetent,” which most people don’t like, or they may lose their routines or their social network may break. So there’s always, always some kind of loss. And it very often gets ignored and not acknowledged except to push people harder.
Frank Days 05:25
I agree with you on that. I had a boss who used to say that people aren’t afraid of change. They’re afraid of what potential impact is of that change. And I think you’re definitely right on with that.
05:35
I think when we talk about change, it’s important to acknowledge those things. And, you know, we don’t necessarily have to make everything happy for everybody. But acknowledging that goes a long way. Just acknowledging that, yeah, it’s going to be different, it’s going to be difficult. And we’ll have to figure it out together.
Jim Ewel 05:55
Yeah. And sometimes I think we can make small changes that can accommodate those things. I mean, absolutely. When I was running a company, we reorganized. This is an interpreting company, we had interpreters that sat in cubicles, and we reorganize them according to language instead of where they sat. And it turned out that people like sitting next to the person that they’d sat next to for three or four years, you know, and it wasn’t a big deal, we can make some changes to do that. And we ended up doing that.
But we had some struggles until we realized that we were unintentionally causing pain. In your book, you have seven rules, or you call them and I like this, you call them heuristics, okay, so not a fixed rule, but heuristics, right, for effecting change. So we don’t have time to cover them all. But I do want to talk about the first rule, striving for congruence. And I was particularly struck by that, because in a book I wrote called The Six Disciplines of Agile Marketing, I advise people to start with alignment. And I was thinking about that I was saying about the difference between congruence and alignment. Do you think there’s a difference between those two? And if there is, what’s the difference? And why start there?
07:16
Well, tell me a little bit about how you’re thinking about alignment.
Jim Ewel 07:20
I was thinking about it in terms of like, for example, if people are going to implement Agile, I tell them first get aligned on why are you implementing Agile? What does success look like? You know, what are the conditions for implementing Agile, you know, get everybody to talk about that and get aligned on that. I also suggest that they talk about what they like about how things work today, so that they can accommodate those as much as possible. And so I just, I just say up front, you need to get aligned on some of that stuff.
08:00
That’s really interesting. I think it ties in very closely. The first part of what you said ties in very closely with the first topic we discussed, which is why change is sometimes difficult, because people don’t understand what problem they’re trying to solve. And people don’t understand what outcome they’re trying to create. It’s very, very difficult for people.
Jim Ewel 08:20
I also say that people support what they help create. So I think it’s important, absolutely right. It’s for people to get aligned in terms of that, you know, their voices heard in ways.
Esther Derby 08:35
And I think your insight about paying attention to what people value about the present is also super important and often overlooked. Think about what you want to keep as well as what you want to change. So I’m going to answer your question about congruence. But first, I want to say it sounds like we’re kind of aligned on change.
Jim Ewel 08:58
Yes, maybe we’re congruent.
Esther Derby 09:02
Or maybe we’re both approaching change from a stance of congruence. So congruence is a concept that comes from the work of Virginia Satir, who was a pioneer in looking at families as systems. So when someone would come to her with a problem, she wouldn’t just look at the identified patient. She’d look at the whole, the whole family system, and while I am not trained as a psychologist or a social worker, a lot of what I have learned from studying her work is very applicable to human systems. So congruence is this idea that in any interaction, you have to balance the needs of your own needs, skills and capabilities. You have to consider those of the other people you’re working with. And you have to look at the context. So self, other and context. And those need to be roughly in balance. And it’s never perfect. It’s you know, I say strive for congruence rather than, you know, be congruent, because it’s always easy to get kind of knocked off and you know, kind of get back on track. I think of it kind of like a wobble board, you know, like you’re near never perfectly balanced, you’re always making adjustments. But those are the things you have to consider. And I think that’s actually, there’s a lot of commonality in the way you’re talking about alignment. Understanding the rationale has to do with the context, like we are in an organization, we’re in a business that needs to stay in business, the world around us is changing, we need to respond differently, therefore, we need to make some kind of change within our organization. So that’s the why piece that you’re talking about with alignment. And then what, you know, what do we value? And what do we want to keep, I think is very similar in some ways to let’s, let’s look at the other people involved in this change. You know, what are their wants and needs and capabilities and desires. And then the sell part comes from how you approach going about change. So I think there’s it, I think there’s potentially a lot of similarity in how you talk about alignment and how I talk about congruence.
Jim Ewel 11:23
It’s interesting to me the differences because what you’re saying for congruence is that it’s also about meeting the needs much as possible, of the different I’ll call them interest groups for the different parts of the organization, we need to meet the needs of, of management, we need to meet the needs of individual contributors, we need to meet the needs of middle managers as much as we can and still achieve our goals.
Esther Derby 11:51
We certainly have to consider them. Right. If they’re if they’re not considered at all, then you know, you’re not likely to meet any of them. And I don’t think you can always do it perfectly. I don’t think you can meet everybody’s needs perfectly, but I think it’s helpful to consider them, you’ll end up with a much more robust idea of how to go about change, if you give them consideration due consideration, and adjust how you’re approaching things based on that. What other differences do you see, I’m curious about that,
Jim Ewel 12:24
Those are the main differences, I think we’re aligned on aligned, right, where we are aligned on the general approach, but I like the strive for congruence that you you’ve mentioned. And I also like your analogy of the Wobble Board, you know, you can’t meet everyone’s needs, and it’s not a static system, it’s going to, it’s going to change a little bit, and you have to adjust your balance, you know, to stay upright and respond to those things.
Esther Derby 12:58
Yeah, I also think it’s, um, you know, it’s an individual stance, but it can also be the characteristic of companies. I visit some companies where they do generally try to balance those things. And I visit companies where they don’t, and that shows up in the company culture a lot. Like I see a lot of companies that are that have a very blaming culture, which is an incongruence stress stance, because you’re not considering the needs of other people. Generally speaking, if you’re in a blaming, if you’re in a blaming stance, but from an individual standpoint, I think it’s important because that’s where we can access our best thinking. And that’s where we can access our empathy. And it’s hard to access empathy. When you’re blaming, it’s hard to access empathy when, though you’re blaming someone else, or you’re blaming yourself or when you’re not considering anything but the context.
Frank Days 13:51
In your book you have Rule Five is “experiment”. As you say, little changes, limit disruption and allow people to learn. Can you share with us an example of an experiment that one of your clients took that was particularly effective?
Esther Derby 14:07
I can tell you about an experiment that in some ways failed, but was super useful because we’ve learned something from it. And what was learned from it allowed us to take a different approach and discover some other things. I was doing some work with a company who like many companies, they were trying to do Agile, do the Agile, and their sprints were almost always overstuffed. So we started asking questions about what was going on with that. So we did some little experiments to see if we could shift the dynamic in the commitment meetings. The teams weren’t actually present, as it turned out, so people would talk about the team’s commitment, but the teams were never actually in those meetings. And there’s, there’s one problem right there. But we started trying to make the team velocity visible. This is how many stories the team has committed on average in the last six Sprint’s, so let’s not commit to more than that. And having that information visible, we thought might change how people behaved, but it didn’t.
So the next thing we tried was we gave people physical tokens, we gave them poker chips and said, Okay, you can, you know, move a move one to the next to the other pile each time you add something. And when you’re out of chips, that’s it. And that also didn’t have the effect, we thought it might, which led us to look at some look at some different areas about what was going on in the system. And it turned out that while the teams actually had a very consistent velocity, they also very consistently got stuck in the middle of a sprint because they had some big technical issues. And so the teams would take in extra work. So they had something productive to do when they were stuck on these big technology problems. But it masked the impact of these technology problems. And it created this dynamic where the teams were saying, oh, let’s do 100 But they only finish 70. And so people were mad at them, because they were only finishing 70 Why don’t you follow through on your commitments? So that was really useful in learning something about the system?
Jim Ewel 16:37
Well, Esther, I can’t leave this interview without talking about retrospectives. Okay, you co-authored a book on that. And I find that a lot of teams, they either don’t do the retrospectives, or they do them ineffectively. So why are retrospectives important? And how to teams make them something that’s a meaningful meeting?
Esther Derby 16:57
Well, first, I want to say there are also a lot of teams that are doing really great retrospectives, and having great results with them. Sure. So it’s not that, you know, everybody’s failing with them, I have, I’ve seen a lot of teams that are really making good use of them. And there’s a company out in Southern California that I think has actually experienced some significant transformations because of their retrospectives. But you’re right, a lot of teams are getting really shallow results or no results. And I think there’s a, you know, a handful of reasons that happens. After looking at many, many companies and talking to some friends who have data on it, a lot of teams have been taught that a retrospective is just you make a list of what went well, what, what didn’t go, and what we would do differently, and then you dot vote. And those teams typically have very shallow insights, they are not really understanding what’s contributing to their issues. So they’re very superficial, they tend to get bored and think they’re useless, because they kind of are.
Jim Ewel 18:09
Yeah, you know, I mean, okay, so what should they do instead?
Esther Derby 18:13
So it is possible, if you have really great facilitation, to have a good discussion based on making three lists. It’s possible, but I find it much more effective to one to have a focus. Because very often, those lists are scattershot, right, there’s just a kind of grab bag of everything. So have a focus, you know, this week, we are going to look at our patterns of defects. Or this week, we are going to learn look at our relationship with this other team that we need to work with. Or this this iteration, we’re going to focus on our technical practice or whatever it is, but have a focus, and then have some data. You can have subjective data, which is how people feel about things, people’s perceptions about things, are you going to have hard data but have some data? Because otherwise, you know, you’re not grounded. And then once you have some data, you know, that’s related to your focus, you can actually apply your analytical brain to it and have some insights about the nature of the issues you’re experiencing. What is getting in the way of achieving what you hope to achieve? What is the goal that you want to move towards? And with that, then you can think about what are we going to do about it? And then you choose one or two things to do about it.
Frank Days 19:35
It’s interesting, too, because it feels a little bit like you know, obviously we got to change the behavior to get different results. Right. I know I’m a guilty party when it comes to retrospectives that we’ll go and make some insights and then we’ll try to make some changes, but then ultimately, behavior. We come back a month later and we still overstuffed to the sprint with too many tasks. And I think you’re right. It is like trying to ask different questions and look and look at it from different angles. instead of just the staid, same old, same old, what went well, what didn’t go, Well, what can we do differently kind of questions.
Esther Derby 20:08
And what does that mean? It’s also important, like we talked about this at the beginning, you have to look at what holds the current pattern in place. You can’t just expect people to change their behavior, if everything in the system is only to all the other incentives in the system, formal and informal, are holding current pattern in place. If everything is influencing the pattern in one direction, you know, individual skill and will is often not sufficient to switch it. There were a lot of things that kept that old patterns in place. And often you really, it’s necessary to look at those that retrospectives don’t do anything. Another is that the expectation is that teams are always working on features, and that any improvements from the retrospective are, you know, done in all in all of the copious extra time that people have after they’ve worked a sixty hour week.
Esther Derby 21:07
Don’t overstuff your sprint. One, because things are going to come up, they always do. People don’t build in time where the expectation is people are going to be using this time to learn, to work on improvements, to figure out how to do something differently. Because all of that learning takes time. We all went we and we all went to school at some point we put in some time studying why do we forget that when we get to work?
Podcast: Play in new window | Download
Subscribe: RSS