Agile Doesn't Work Without Psychological Safety

0:00:02.4 Producer: Welcome back Culture by Design listeners. It's Freddy, one of the producers of the podcast. And today we have an episode on why agile doesn't work without psychological safety. Tim and Junior will talk about some of the biggest obstacles to success for an agile transformation and what role culture and psychological safety play in the process. You'll find important links and references from today's episode in the show notes at leaderfactor.com/podcast. That will include a link to the book, The Four Stages of Psychological Safety by Timothy R. Clark. Thanks again for listening and thank you for your reviews. I hope you enjoy today's episode on why agile doesn't work without psychological safety.

‍

0:01:01.0 Junior: Welcome back everyone to Culture by Design. I'm here with Dr. Tim Clark and today we'll be discussing psychological safety and the agile movement. Agile has become a global movement, hasn't it Tim? It has. Well, it started out just for software development, didn't it? I mean that was the original thrust, the focus, the reason that these software engineers got together back in 2001 originally. But it spread into all kinds of areas so that's interesting. We can talk about that but yes, the answer is yes.

‍

0:01:25.9 Tim: It's spread, it's metastasized, it's just gone everywhere and there's a reason for that. I guess we're going to talk about that Junior.

‍

0:01:35.5 Junior: We are. It's enlisted thousands of organizations and as you said, it spread beyond software development and it's found its way into almost every function in the organization. Yet, here's the big yet, most agile transformations end in false starts and most agile organizations we would say are agile in name only. Why? That's what we're going to talk about today and we're also going to talk about how to fix it. So let's set this up. The Agile Manifesto. I'm assuming that most of our listeners have at least heard this term, the Agile Manifesto. Tim, where does this come from? Give us the setup and the stage.

‍

0:02:18.1 Tim: Yeah, it's an interesting backstory. Back in 2001, 17 programmers, software engineers got together. Matter of fact, I think they were meeting at the Snowbird Lodge just outside of Salt Lake City. Our backyard. Yeah, our backyard and they got together and out of their deliberations came a very short, succinct document known as the Agile Manifesto. That manifesto is very short, very simple. It includes three values. Well, no, four. Four values and 12 principles, but it's short, it's sweet and yet it's become a juggernaut. It developed all this momentum and it spread out, as I said before, beyond software development. So now we have Agile everything, don't we, Junior? We have Agile HR and Agile project management and Agile customer service and Agile sales and Agile operations and Agile C-suite. It goes on and on. It's amazing. So there's something to that. There's something to that. There's some value there. Otherwise, this would not have happened.

‍

0:03:31.1 Junior: Yeah. And it didn't come out of thin air. It wasn't like they were just all at Snowbird at the same time and casually decided to sit down and talk about this idea of Agile. This was a response to something. There was a problem. Right.

‍

0:03:44.7 Tim: And you're not going to put a document together and call it a manifesto. That's a strong word. That's a public declaration about a point of view that you feel very strongly about. You're not just going to get together and do that. So they were motivated. They had this sense of shared motivation about something that they thought was broken. Isn't that true, Junior? Yeah.

‍

0:04:06.7 Junior: So let's talk about the problem. Let's talk about what was broken. At that point, software development, I would say, was still in its infancy. If you look at the timeline relative to what it is today, certainly in its infancy. And what was done at the time was a fairly bureaucratic waterfall method in software development. It was very linear. You would define your requirements early on. Yeah. And you would plan out, think Gantt chart, everything that needed to happen in cascade form to reach the end objective. And sometimes these waterfalls would last months or sometimes years. And so you can imagine this linear, slow process that inevitably had rigidity. And that rigidity was what made this so difficult. Because if you think about the pace of change in 2001, that pace of change was fast relative to 1995. If you look at the pace of change today relative to that time, it's even faster. And so the problem with waterfall has become even more exacerbated as the pace of change has increased. And so what's the reality of the landscape? The reality is that the landscape changes and that it changes quickly. There's nothing static about a six month or a 12 month timeline.

‍

0:05:32.9 Junior: And that pace of change as time progresses has increased. So they were responding to this pain 20 years ago. And that pace of change has now ramped up. And because the landscape changes, requirements change. So you spend all of this time upfront defining your requirements, which you should do.

‍

0:05:54.2 Tim: And you had to document those, Junior. You did. And that all had to be documented. So think about that.

‍

0:06:00.5 Junior: It was very comprehensive documentation. And sometimes you would start working on the support documentation as you're building the thing. So it's very document heavy documentation heavy. So the whole premise of this idea is that the landscape changes, it changes quicker than it has in the past, and thus requirements change. So what do we need? If linear, slow and rigid is bad, we want speed, we want flexibility, and we want adaptability. So that's a little bit of the motivation behind this agile manifesto. So they sit down, they write the manifesto, they publish that. And since that time, agile has become a global movement. But many organizations struggle with agile. And that's where we're going to spend most of our time today is you look at the four values, which we're going to talk about a little bit later. And you think, okay, fairly straightforward, those seem like good things. Let's go ahead and adopt those. Let's put them into our organization. Let's adopt the tools of which there are countless. If you look at all the tools and approaches and systems that have spun off of that core agile methodology, there are tons. And yet those tools are only tools.

‍

0:07:21.7 Junior: We talk about them as infrastructure, we talk about them as scaffolding, but there are other core pieces that need to be in place in order for agile to be successful. So a question we often ask is what is the biggest obstacle to a successful agile transformation? And keep in mind, that's how many organizations look at this. We want to transform into an agile organization. We want to adopt the methodology so that we can reap the benefit of that adaptability.

‍

0:07:50.6 Tim: Junior, I want to go back for just a minute. There may be some listeners here that are not software developers, that are not technologists, and for which they're listening to this subject and they're wondering, well, what does this have to do with me? I work in marketing or legal or HR operations or whatever. Let's make the comparison to strategy because in strategy, we differentiate between deliberate strategy and emergent strategy. Deliberate strategy says, let's sit down, we're going to go through a formal planning process, we're going to put our strategic plan together, and that strategic plan is going to take us for, I don't know how long, Junior, for like a typical formal strategic plan. What are we looking at? It depends on the organization, depends on how naive you are.

‍

0:08:44.1 Junior: That's right. Some organizations would create a strategic plan and say, this is our, at a high, high level, five-year plan, or this is our 24-month plan or our 12-month plan. And depending on your industry, I don't mean to be facetious, it is more or less dynamic. And so those timelines can be more or less defensible, but suffice it to say, those long timelines have some inherent problems.

‍

0:09:13.1 Tim: Yeah. But historically, that's kind of how it was. You had a time, you had a planning horizon that was like three to five years, and you put your strategic plan together and you say, here we go. Well, what happens, I think it was Eisenhower that said, planning is indispensable, but plans are worthless. As soon as that strategic plan meets reality, it's wrong. It's wrong every time. The only question is how much? And so you got to revise. If you're in a static environment, you can plan for a longer period of time. If you're in a dynamic environment, you can't do that. So the more dynamic the environment, the shorter your planning horizon can be. So that difference between deliberate strategy where you sit down in a formal process and you knock out a plan, that's still important to do at some level, but you know that when that plan meets reality, you're going to have to make adjustments and you're going to have to switch over to emergent strategy. How would you describe that, Junior, emergent strategy?

‍

0:10:26.1 Junior: Emergent strategy is what happens when your plan collides with reality, because you put that plan out into the world and you begin executing, but then you find very quickly that the ground is shifting beneath your feet. And so the emergent strategy is what comes from identifying that shift in the landscape and then pivoting and making a small alteration to that strategic plan. And sometimes it's a big alteration. Sometimes the tectonic plates are making massive shifts beneath our feet, and sometimes they do that very quickly. We start out thinking that we're on top of Pangea, and before we know it, we have all of these new continents, and it happens in some cases very, very quickly. And so that emergent strategy becomes even more important in some cases than that deliberate strategy at the outset, because there can be so much change. Now, it's certainly true that industries like technology will experience this to a greater degree than some organizations, some other industries, but the idea is still indispensable. You might think that government is a relatively static thing. Let me tell you, it is absolutely not. You might think that healthcare is relatively static. It's changing every day.

‍

0:11:44.5 Junior: And so some of these industries that historically have been relatively static are still becoming more dynamic as time goes on. One of the things that I love to look at is the average tenure that an organization has inside the Fortune 500. And that lifespan decreases seemingly every year. Once you made that chart in 1980, you'd probably stay there for a really long time. Now you break into that category. Your average lifespan is going to be much, much shorter than it was in the past. And so the turnover inside lists like that is indicative of just how dynamic the environment is. And the shortening of that lifespan is indicative of the increase in the pace of change.

‍

0:12:29.2 Tim: Right. So, Junior, that difference, that difference between deliberate strategy and emergent strategy, that's the very thing that animated these 17 software engineers when they got together. They're just applying it to software development, but it's the exact same principle, which is what is the approach? What is the process? What are the tools and what are the behaviors that can allow us to be successful in a highly dynamic environment? What kind of adaptive capacity do we need to have? We've been subscribing to this old waterfall model that was so rigid and inflexible and it was just not working. That's what motivated them to come together and say, we've got to do this differently.

‍

0:13:16.1 Junior: So before we go any further, let's talk about what those agile values actually are. I'll read them. Number one, individuals and interactions over processes and tools. Two, working software over comprehensive documentation. Three, customer collaboration over a contract negotiation. And four, responding to change over following a plan. So that fourth one is what we've been discussing for the last few minutes, responding to change over following a plan. Now, individuals and organizations will look at these values and they'll say those are aspirational. We want those inside our organization. Let's bring them in. But that's where they start to go awry. So there are several obstacles to successful agile transformation. I'm going to list a few of these and I would like all the listeners to think which one do you think is the biggest obstacle? Skills, tools, processes, practices, training, money, leadership and culture. Those are all important, but there's one that we have identified over time as the most important and the biggest obstacle to successful adoption and transformation of these four values. And that is culture. Tim, why do you think culture is the biggest obstacle? We've seen this time and time again.

‍

0:14:41.9 Tim: Well, I think we could say it this way. It's both the greatest enabler and the greatest inhibitor. Love that. So what that means is it's either going to be your biggest obstacle. It's going to prevent you from being agile, being able to do what you want to do, or your leadership and your culture will enable you to do that. And that's what we've found. All of the other components, factors, elements that you just listed, Junior, all of those things represent scaffolding. They're important, but they're secondary. It's all scaffolding to the culture of that team. That's the way that we would put it. And I think the way that we put it in the article is that the central weight bearing mechanism is the way that we put it. The central mechanism of the agile approach is not the scrum or the sprint. Rather, it's the team's dialogic process, the way the team members interact that ultimately determines success. That's it.

‍

0:15:47.2 Junior: That's the key. So you could have all these other things, but you have poor culture, poor leadership. You're probably not going to get very far. So we're going to talk about what we can do as an organization to ensure that our culture is conducive to the adoption and the transformation of agile using those agile principles. So let's go back to the first value, individuals and interactions over processes and tools. I find this fascinating because it's the very first value. I'm sure, I'm very sure that most organizations attempting to adopt agile would not be able to repeat that to you. And if they would, if they could, the ratio of time that they're spending between those two things is probably not where it should be. So let's dive into that. We have these two things, individuals and interactions, which is what you're talking about, Tim, the way people interact, the dialogic process and the manifesto is saying that that is more important. Now, we're talking about them, processes and tools. So how have we done historically as organizations when it comes to these two things? Have we really put the way people interact over processes and tools?

‍

0:17:05.0 Junior: What I find is that as I look at organizations, as I look at all of the publishing that's done in the space of agile, what are we doing? We're focusing on processes and tools, which is so ironic to me because this is the first value inside agile, yet it's being tossed aside in favor of processes and tools, the very thing that it's trying to prevent. When we look at organizations and we look at the ratio of time, attention and resource that they're allocating across those two things, that gives us a really good indication of whether or not their transformation is going to be successful. If they're spending more time on process and tools, invariably they're going to fail. If they're spending resource on individuals and interactions, the likelihood that the transformation is successful goes through the roof. What do you think about that, Tim? I think that's right. And I think of the four values, this is the one that we have failed on most frequently over the last 21 years. And so we need to ask ourselves why. Let me just repeat it, individuals and interactions over processes and tools. Processes and tools are important.

‍

0:18:19.4 Junior: They have a very important role to play. But what the manifesto is saying is that the individuals and their interactions is even more important. The processes and tools will never save you. They'll never save you. And they cannot compensate for what you lack in the way that you interact as a team. But then we have to ask the question, well, why do we keep defaulting to processes and tools? Why is that our reflex? Why do we keep going back to that and emphasizing that more than individuals and interactions? I think there's some, I don't know, pretty straightforward reasons for that. I would say that the individuals and interactions are, it's more intangible. It's not as measurable. It's not as perhaps observable. It's harder to operationalize. And so we very soon, we just leave that. We stop worrying about it and we come back to the processes and tools because that's our comfort zone. That's where we can really measure accurately. We can track everything. We feel that we're on top of it. And so we go back to worshiping at the altar of technical processes and tools. Again, because the cultural considerations are abstract or they seem more abstract, more difficult to measure, more difficult to operationalize.

‍

0:19:50.6 Junior: And so you can see how the focus and the emphasis on individuals and interactions, it deteriorates over time. So what should we do about that? If that's our tendency and these are some of the failure patterns, what do we do? So let's jump into that piece of the conversation. Is there hope? Is there a light at the end of the tunnel? The answer is yes, there are absolutely things that we can do to make it more likely that we can successfully transform our organizations. Let me just emphasize this last point because I have to smile when I see this with teams. You ask them, so have you implemented Agile? And they say, oh yeah, we're an Agile shop. We completely do Agile. And what do they point to? Let me show you. They'll say, let me show you that we are completely Agile in our approach. We're scrumming, we're sprinting, we're Kanbanning, and we're Kaizenning. And if you can show me that, then you are Agile. And what we're saying is, no, you're not. That is not the measure of whether you are Agile because the core technology of Agile is neither technical nor mechanical. It's cultural.

‍

0:21:09.0 Tim: They just point you back to the tools and the processes and they say, we're an Agile shop. Let me show you. But to see they're missing the point, that is not the true measure of whether you're Agile. And that's what we're trying to say here.

‍

0:21:22.1 Junior: So let's jump into the true measure. What is the true measure? One of the things that we would begin by saying is to make psychological safety the center of Agile transformation. For those of you familiar with the four stages of psychological safety, you'll probably remember stage four, Challenger Safety. And in between stages three and four, Contributor and Challenger Safety, we have the Innovation Threshold. And it's only when you cross that, that you really have the ability to do Agile well. Why is that? If you're going to adapt to a changing landscape, you need to change. You need to be aware that the change needs to happen. You need to be able to communicate that the change needs to happen. And then you need to be able to implement and execute. And so there's some version of the status quo that you're putting on the table and criticizing. That can be a very difficult thing to do. And I think that that's part of the reason that many organizations stutter and fail or stall in this stage of implementation doing Agile. Because that core mechanism of being able to challenge the status quo is not there. And that's what must be there in order for an organization to adapt and to innovate.

‍

0:22:42.3 Junior: It's dissonance, it's dissent, almost inherent. It's baked into the process. It's part of the idea. And if you can't get that far, and if you can, maybe you adopt the idea, but if you don't get as far as actually doing the work and achieving that level of dissent, it's going to be very, very difficult. So that's the first thing that we point to. So I would say in connection with that, Junior, that in order to do that, that we frame the Agile implementation as a cultural implementation.

‍

0:23:17.0 Junior: So that's your frame. That's the way we frame what we're doing here. It is not a technical or a mechanical implementation based on tools and processes. It is a cultural implementation. Now, let me point out a hazard, though. We've seen this with team after team. They approach culture as a work stream. Now, think about that, a work stream. A work stream is a progressive completion of tasks. You start, you have a beginning, a middle, and an end, and you work through it. Culture is not that way. Culture cannot be completed. And so the deception and really the difficulty comes in if you approach culture as a work stream, you're under the impression that you put it on your Gantt chart and you follow your work breakdown structure and you complete it. You move through these tasks, and then you say, culture is done. Culture is never done. So what we're saying is don't approach culture as a work stream. It is not a progression of tasks that you're going to move through. The entire implementation of Agile is a cultural implementation. So you've got to frame it correctly to begin with. Otherwise, you're going to try to project manage it as part of everything else that you're doing.

‍

0:24:42.5 Tim: And it's not part of that. It's not a work stream. So I just want to make that clear because we see that all the time.

‍

0:24:48.5 Junior: So you might have seven work streams, psychological safety culture is one, but what you're saying is that you need a foundation of culture, a foundation of psychological safety, and the six work streams are built on top of that. That's right. That must be there first.

‍

0:25:04.8 Tim: And it has to be constantly supported and reinforced. And it never goes away. It's never completed. It's not something you project manage. It's not part of a work stream.

‍

0:25:18.5 Junior: I really like the idea that that healthy culture, that environment of psychological safety is perishable. There have been times that I can look at organizations that I've been a part of that we have helped that have had pockets of psychological safety or short windows of psychological safety. So it might be a small pocket inside the organization, might be the organization as a whole over a short timeline. But once you say we're there, that's when things start to unravel. That's when it starts to go poorly. And you have a tendency to do that if you look at it as a work stream because you hit the completion at the end, you've completed all the tasks inside of the project and you want to check the box, you want to check it off the list. We have successful implementation instead of saying, no, this is foundational and it's something that we need to nurture. It's a garden that we need to weed every day because if you don't, it becomes overgrown very quickly and it can become unruly. Something that's very difficult to prune if you've left it alone for a year rather than nipping some of those things in the bud when they're small and when they're relatively easy to take care of before you have a big pokey garden full of weeds and trees that you don't want.

‍

0:26:36.8 Junior: And Junior, let me come back to just pointing out a little bit more about the relationship between individuals and interactions on the one hand and processing the relationship between the processes and tools on the other.

‍

0:26:48.7 Tim: So I hope that the listeners are not getting the impression that we are being very dismissive of processes and tools. We understand how important they are, but we need to understand the relationship between the individuals and the interactions on one side and the processes and tools on the other. That relationship, I'm just saying this way, the individuals and their interactions lubricate the machinery of the processes and tools. So that's what gets everything to work. It's the lubrication. You're oiling the gears of the processes and the tools of Agile, your scrums and your sprints and doing. And so they go hand in glove. So we're not dismissing processes and tools, but if you neglect or you forget and you're not constantly reinforcing the culture, the nature of the interaction with the team members, then what are you left with? Your processes and your tools. Is that going to get you there? It's never going to get you there because again, it's primarily a cultural implementation. So there's the relationship that we need to understand.

‍

0:28:08.1 Junior: I'm glad that you called that out fairly recently on my own team. We completed a software audit. Basically we list out all of the software tools that we're using and obviously there's a financial audit, there's an efficacy audit, and there are some lenses that we look through to decide what we should keep, what we should get rid of, and maybe some new tools that we want to adopt. And I've seen that time and time again that there's nothing magical about a tool, a piece of software, a technology, a process. There's nothing inherently valuable about that thing that you're going to bring into your team. And all else equal, you want fewer tools. That's also something that I've learned. But what I found as I'm going through this is that the efficacy of each of those tools is tied back to the humans using them and the way they interact. And that was obvious to me. There are some of these tools that are incredible in terms of their functionality but are absolutely useless if the people using them cannot work together and if we don't have that lubricating oil as you mentioned of healthy relationships, interaction, and collaboration.

‍

0:29:17.9 Junior: And so I just wanted to call that out because that's something that I'm living and breathing currently as we look at the tools that we're using. Some of them very expensive tools and some of the tools inexpensive but they can be incredibly valuable based on the collaboration. And so tools will not save you. You can't spend your way out of a cultural conundrum. It's not something that you can just add more to and expect good outcomes. You have to be very, very intentional about this idea of culture being the foundation. You can do much, much more with a healthy culture and few tools than you can do with an unhealthy culture and all the tools you could ever ask for. And Junior, let me just point out a relationship or some definitions because we've used the word culture a lot in this discussion. And we've pointed out the first value of the Agile Manifesto that says individuals and interactions over processes and tools. The working definition that we use for culture is a four word definition. It's the way we interact.

‍

0:30:26.6 Junior: That is the official leader factor working definition of culture. Very scientific. Yeah. Well, it's a reduction of all of the elements that we normally identify as being part of culture. So if you look at culture from an anthropological standpoint, you're looking at values and assumptions and beliefs and traditions and mores and artifacts, and it goes on and on and on and on. So there's this huge basket of things that we put into to say this is all culture. Well, that's still a real, how do you get your arms around that? So that's just really abstract and really complex. And so if you reduce that to the way we interact, it makes sense because all of those things come out at the human interface. So it's very intriguing to us that those who came up with the Agile Manifesto used the words individuals and interactions. It's all about that. The way we interact is the essence of the culture. And so I just want to clarify those terms because we use the pattern of interaction and the way we interact as synonymous with culture. That's the operating definition of culture that we use. And so I think that those that signed this Agile Manifesto, they nailed it.

‍

0:31:51.4 Junior: They nailed it right from the beginning. And you can see why we keep pulling away from the first principle because it's hard. We're talking about maintaining that lubrication for the machinery of the processes and tools. And it's very easy to just slide over and focus on processes and tools exclusively and not worry too much about individuals and interactions. And we can kind of give it a little bit of a head nod, but we're not really doing anything. So part of the big problem with Agile is that they don't tell you how to continue to nurture and reinforce the patterns of interaction. And so people, they end up falling back, snapping back to old patterns. It's what we call a regression to the mean. They're snapping back to the old patterns of fear-based interaction, intimidation, autocratic styles, things like that. And then what does that do? You can have all the tools and the processes in the world, but if people are withdrawing, if they're retreating, if they're recoiling, if they're in a mode of self-preservation and loss avoidance and personal risk management, then what are the tools and the processes going to do for you?

‍

0:33:12.6 Junior: Not much because we're self-censoring each other. We're on this Agile team, but I trigger your self-censoring instinct, you trigger my self-censoring instinct, then we retreat, we're playing defense, we're giving a fear response. So here we are. Does everyone see the problem here? The processes and the tools cannot lift you out of that predicament. They can't rescue you and liberate you from those conditions. You have to solve it where the problem started, which was in the nature of the human interaction on the team. And that's why we talk about what, well, one of the tools that we use or processes in Agile is to have a retrospective, right? That's the meeting that you have after the sprint where you get together, you do a post-mortem and you say, how did it go? So we had this week-long sprint or two-week-long sprint. How did it go? Not just in the way of deliverables, not just in what we accomplished, but how did we behave? How did we interact? How did we collaborate and cooperate during these past two weeks? Let's do some pattern recognition. Did we get in each other's way?

‍

0:34:29.0 Tim: Did we trigger each other's self-censoring instinct? Did we push the fear button? That's a way to use the sprint retrospective very productively to look at the cultural side. But what we're saying is that teams are not doing that nearly enough. They're just not giving the time to the interactions, the culture of that Agile team.

‍

0:34:54.9 Junior: So what you're saying is, if I'm understanding correctly, that the interactions need to be healthy on the input side, but there's also this accountability mechanism inside the retrospective that needs to be cultural. It's most often technical. Did we accomplish the task? Did we meet the requirements? Were we on time? Were we on budget? But there's this cultural element that needs to be in there. So inside an article you wrote, you put, evaluate your dialogic process post-sprint. That term dialogic process I've been thinking a lot about, and I'm assuming that dialogic comes from dialogue. If that is true, think about dialogue. What is dialogue? It's two or more people having a conversation. And so for me, at least one of the ways that I look at this when I think about my own team is, how were our conversations? How did we talk to each other? Because that's so much of what this boils down to is when we're in a meeting, when we're having a conversation, when we're having dialogue, how is it? Is it healthy? Is it unhealthy? So much of that outcome can be tied back to the quality of the dialogue. So those are kind of the three buckets of inside what do we do.

‍

0:36:19.7 Junior: Make psychological safety the center of Agile transformation. Frame Agile as a cultural implementation, not a work stream. And this one very tactical, evaluate your dialogic process post-sprint. Now you don't have to be inside technology. Again, you don't need to be doing sprints per se. You could be doing anything. There needs to be some sort of mechanism by which you evaluate the dialogue, the culture, the conversation, the health of the interaction. And as you do that, as you open up for conversation, that idea can take hold and you can improve over time. But if you don't do that, you could have met the requirements. But let's say that there was some unhealthy dialog inside that went over the line, but it was there, but you met the requirement. If your only criteria for evaluation is technical, then for all intents and purposes, it was a win. As soon as you introduce that cultural variable, maybe it wasn't so glamorous. Maybe we didn't score as high as we thought we did. Maybe there are some things that we can tune. This can be very dangerous if we're just evaluating technical criteria because those issues that are on the front end in the dialogue can perpetuate.

‍

0:37:40.4 Junior: And pretty soon we could end up with a toxic or some degree of toxicity inside the environment that becomes difficult to root out. So I really liked that you called out that third one, kind of a post-mortem evaluation.

‍

0:37:53.4 Junior: Most teams, Junior, when they do their retrospective after a sprint, they're just looking at their deliverables. They're looking at what they accomplished and what they did not accomplish. Which makes sense. It makes sense, but it's a small part of what they should be doing. So let's go back to the basic definition of an operation. An operation consists of three elements, inputs, conversion, and outputs. That's an operation. Now, often we string operations together. So one feeds into another, feeds into another, and so on. But the basic components of an operation, inputs, conversion, outputs. Why does that matter? Well, when you're doing a retrospective, you need to evaluate all three elements of the operation, the inputs, the interaction, and the outputs, not just the outputs. And so the inputs would be the people, the conversion would be the nature of the interaction among the people and the work they put in, the labor, the effort, and the way that they're collaborating, the way that they're interacting, the way that they're working together. And then the outputs will be those deliverables. So what we're saying is, use the retrospective more effectively than you have in the past. Most agile teams, they just scratch the surface.

‍

0:39:24.1 Tim: They're not doing it. They're not going back and looking at culture and the patterns of interaction. But if you do that, that's a way to formally and systematically evaluate this part, this most important part of agile. So I would just go back and just remind everyone again that an agile implementation is a cultural implementation more than it is a technical or a mechanical implementation. That's fantastic.

‍

0:39:56.3 Junior: So let's recap. Let's summarize. Let's talk for a second about where we've been. We talked a little bit about the backdrop to this whole conversation, which is that we're in a dynamic environment that's becoming only increasingly dynamic. There's volatility in the environment that hasn't been there to this degree ever. And that was true even 20 years ago, which motivated the Agile Manifesto as an attempt to solve the problems that came with the waterfall method. That was bureaucratic, linear, slow and rigid. We wanted speed, flexibility, and adaptability. We wanted more agile organizations, hence the Manifesto. It's become a movement. It's been integrated into many organizations, but only a few have been ultimately successful. There's an obstacle and many obstacles to successful implementation. And what we're saying is that culture is the biggest one, can be your biggest barrier, and it can be your best enabler if you do it right. Individuals and interactions over processes and tools. That's the first of the four agile values and arguably the most important. I love that it says individuals and interactions over, not instead of. We still acknowledge the importance of processes and tools, but we don't replace them. Individuals and interactions are superior though, if we're looking at a place to spend time and attention, that's going to be where we want to go.

‍

0:41:21.0 Junior: What do we do? There are three main things that we talked about today. We talked about making psychological safety, the center of agile transformation, specifically stage four, challenger safety. We have to be there if we're going to be successful over time. Frame agile as cultural implementation, not a work stream. And that is probably the biggest recommendation that we've made today that encapsulates so much of the other stuff. And then three, as a mechanism for accountability and feedback, there needs to be some sort of post-mortem evaluation after a sprint or a project or anything that we're working on to look at our dialogic process. How's the interaction? Is it healthy? Is it not? If you do those three things, the likelihood that you have successful implementation of agile goes up tremendously. If you don't have those three things, either it's not going to work ever, or it's inevitably going to stop working because all of these things are delicate. They're dynamic. They're changing every day. We need to keep our finger on the pulse of culture to ensure that we have some longevity to this agile that we're trying so desperately to implement. I really liked our conversation personally at the beginning about the difference between emergent and deliberate strategy.

‍

0:42:37.1 Junior: That's where I love to let my brain wander into that category. And one of the things that we talked about as a final point is that the interaction, the collaboration is what lubricates the gears inside the organization, all of the tools and the processes. You could have a Pagani, a McLaren, a Ferrari engine, but if it doesn't have any oil in it, it's just a big paperweight, regardless of how good it is. And so you're not going to go anywhere regardless of the quality of your tools if you do not have oil in the engine. So Tim, that's kind of what I perceive to be the recap of today. Any final comments or words you want to leave us with?

‍

0:43:17.7 Tim: Yeah, I want to leave the listeners with a couple of questions. First of all, let's revisit the original question. What is the agile team trying to accomplish? The agile team is trying to harness intellectual friction to perform interdependent work. That's the nature of an agile team. It's interdependent work. So the question that flows from that or questions, let me take you through this. You look at your teams, look at your team members. Are you able to give and take, push and pull, talk and listen, question and answer, act and react, analyze and solve? The answer to those questions comes back to the level of psychological safety, the nature of the interaction, which is the essence of culture on your team. So that's something to think about as we conclude this episode.

‍

0:44:17.0 Junior: Love it. Thank you everyone. Thank you for your time today. If you found value in today's podcast, we'd invite you to share it on LinkedIn, tag us, tag a friend. There are a lot of people out there interested in agile. Today's episode might be valuable for them. And lastly, if you have an idea for an upcoming episode, let us know. As always, we appreciate your listenership and for everything that you do. We look forward to next week's episode and encourage you to tune in then. Thanks everyone.

‍0:44:47.0 Producer: Hey Culture by Design listeners, you made it to the end of today's episode. Thank you again for listening and for making culture something that you do by design and not by default. If you've enjoyed today's episode, please be so kind to leave us a review. It helps us reach a wider audience and accomplish our mission of influencing the world for good at scale. Today's episode show notes and other relevant resources related to today's topic can be found at leaderfactor.com forward slash resources. And with that, we'll see you next episode. You.