Join Murray Robinson and Shane Gibson in a conversation about agile anti patterns with Todd Lankford. Patterns are common solutions to common problems. They may be good, bad or neutral. Agile anti patterns are solutions that make it harder for agile teams to achieve the goal. The top anti patterns are: unrealistic arbitrary deadlines, functional silos and managers who dont listen to or support their teams. Other anti patterns. Pattern languages and pattern libraries.

Read along you will

Shane: Welcome to the No Nonsense Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Todd: And I’m Todd 

Murray: Hi Todd. Thanks for coming on today. So we wanted to talk to you about stubborn patterns that prevent agile adoption and what you can do about it. So, let’s start by getting you to tell the audience a bit about who you are and what your background and experience is.

Todd: Yeah, sure. I’m an agile coach. I’ve been doing coaching since about 2009. Before that I was a traditional consultant doing whatever it took. Dabbled a bit and scrum. And XP and things like that in the early two thousands, but didn’t really get serious until kind of mid two thousands and got heavy into coaching and just really all in, on agile and trying to make company’s lives better and teams lives better.

Murray: Were you one of these people who was a software developer in the beginning? 

Todd: Yeah. I have a computer science degree. I started out in software development and, came up the ranks that way. So yeah, I have that kind of common ground with the teams I coach I’m. I feel like that does tend to make me better as a coach having been through of programming and things like that.

Murray: Yeah. , I think so, too. So it’s been 21 years since the agile manifesto was launched. And then even at the time people had been doing XP and scrum for a good, five years or more by that time. Why haven’t we perfected it by now?

Todd: Well, We’re getting into the companies now that are larger. And it’s more difficult for them to change and to actually make the big leap that it takes to get to an agile mindset and be able to move with agility. Along with the fact, especially in these times that you’ve got companies dealing with, remote work and all the things that come with that. And I think that’s actually made things worse. I think people are digging into what they know and going back to the older, more traditional ways of working more predictive, upfront less empirical less about empowered teams.

Shane: Yeah, I definitely agree. We had Esther Dubby on a while ago and she had this concept that if you don’t rub out the lines, then the organization will naturally rebound to that way of working. When we’ve moved in this COVID world to more remote working, a lot of organizations seem to have rebounded to that combined and control hierarchal behavior rather than self-oring teams, which is really interesting because it’s harder for them to observe what’s happening, it’s harder for them to see the work that’s been done. So in theory, we should have adopted the pattern of more self-organization more trust, more enablement. But I suppose, because they can’t see the teams actually doing the work. They’ve rebounded back to those other practices and patterns that have been around for a lot longer.

Todd: A lot of what I see is companies come in and they complain that the teams are not producing what they expect, and they want me to work with the teams. But in fact, it’s not really the teams, it’s the system the teams are. And so I guess the leap you have to take with these companies is to get them to see that, doing agile is much different than being agile.

Murray: Yeah, I agree with you. It is usually not the teams, it’s usually the system the teams are in and the bureaucracy, the fact that organizations are still working in silos. That you have senior managers telling people what to do and not listening to the teams. Those are common problems that prevent the team from being agile. And yet, as you say, it’s often you’re brought in, oh yeah. this team’s not effective or efficient. What can you do to fix the team? And pretty soon find out that it is a management that’s the issue. 

Todd: The system is giving them exactly what it was designed to give them and really trying to paint the lines of, Hey, if you do this here, then this happens. Then this happens . The teams are just a victim of the system and, they probably don’t feel safe in that system. They certainly don’t have high levels of autonomy, mastery and purpose. And if their engagement’s low, their productivity is definitely going to be low. 

Murray: Alright, well talk us through what the main patterns are that prevent agile adoption. 

Todd: The top three are over reliance on unrealistic hard imovable deadlines and not really real deadlines, but deadlines that are there to motivate the team to deliver. Maybe they’re not seeing delivery and they believe the deadline will somehow magically make that happen. So that’s one of ’em. The second one is, when the teams have silos have high levels of work in progress, work is not finished, and as a result you really can’t find any room to adapt. People are just doing their piece, moving to the next thing. How do you really even inspect and adapt when you can’t get through the entire loop? And teams only care about the one thing they do, they’re one specialty. And the third I feel is this low level of engagement that happens when you take away ownership and trust in the team. And they basically become, a cog in the wheel. If you can’t have empowered teams and you can’t have an empirical process and you’re driven to deadlines, you’re cutting corners. How can you possibly adapt to changing conditions?

Shane: I’m a great fan of patents and anti patents. We like the idea of self organizing teams. We wanna give them a set of goals and then let them do the work that they’re good at to go and achieve those goals. The anti pattern is we give ’em a set of tasks. We take away their owner shipping and ability to organize themselves to do that work. 

The high work in progress one, the hyper specialization that’s an interesting one. From a flow point of view, it is about focusing on the handoffs between groups of people and optimizing that. One person having six pieces of work in play and never finishing any of them, that’s definitely an adding pattern that we see a lot. 

Todd: this is not isolated to large companies. You think these things would be things that you’d see in a large organization that’s been around a while. You find this in startups, you find it in people that, are 10 years outta school. All these patterns are, very resilient.

Murray: Why is that what’s going on behind the scenes that is causing these antipatterns 

Todd: Part of it is simply, human nature. With deadlines people don’t like to talk to a stakeholder and not have an answer about when something might be finished. And, I think without that level of detail and maybe some level of false assurance that might give, people are just uncomfortable. I think there is a deep human desire to want to be in control of your situation and exhibit control to others. And I do think that is just a human quality that gets in the way. And I do believe that agile is not commonplace and the thinking behind it is not commonplace. If people have worked anywhere outta school they’re gonna come into contact with the predictive command and control mindset more often than they’re gonna come in contact with agile ways of working and thinking.

Murray: Yeah. Its certainly common to see management focused on fixed scope, deadlines, high utilization, and so on. And one of the common Antipas I see is management, not listening to the team. So you have your retrospectives, you raise issues, you go and discuss them with management and they say, no that’s not an issue. What are you talking about? and then you have to spend ages trying to convince them. Let’s say you have a problem, like lack of skills or teams not working together, dev and test not working well together as a common one. It is often coming from outside. The team’s not working together because senior managers are not working together and they’re not working together because they have their own KPIs, which are not outset for them from higher up. But the thing is that there’s often this lack of a feedback loop from the bottom up to the top, or just a lack from management to actually accept what they’re being told. I find that common. Do you see that to?

Todd: Absolutely. Oftentimes management doesn’t even interact with the team. How could they possibly know? They almost see the teams as a pond or something on a chess board that gets moved around versus human beings. They might actually manage from a status report. Be very far removed from the team. They’ll see a risk in a report and, they’ll just assume someone will take care of it. Also managers will sometimes turn around the team and say, Hey, bring me solutions, not problems. You have this mentality that I don’t want to hear the problems. I want to hear what you’re gonna do about it. And I think that can actually work against the team’s level of safety in raising issues because if they don’t have an answer to how to solve it, maybe it’s completely out of their control. They don’t have the political capitals to solve the problem. It’s a systemic issue, or they just don’t know how then if that’s the case, they may not even raise the problem. So I feel there’s this cycle that of prevents transparency into the problem. Especially if the manager’s not solving it, if they do know about it, then the team is probably going to give up, they’re going to be apathetic about it and just deal with it.

Shane: I, I have a pet one, the risk management workshop and the risk management spreadsheet. That for me is an anti patent. The risk goes away to the great risk bucket to die. And we are never actually mitigating those risks.

Todd: Absolutely. Yeah. Anytime you see those color codings, it’s hard to trust them. Especially if there’s not a lot of safety everything will be green. And it might be yellow, but don’t worry. It’s gonna be green soon. You get a lot of green on the outside red on the inside, the watermelon effect and that’s an anti pattern. Any type of reporting could be an anti pattern if it’s in the way of individuals and interactions, I think that’s definitely an anti pattern to look out for.

Shane: The negative use of velocity is an anti patent that I see on a regular basis.

Todd: Yeah. I just think management will not let that be a planning tool and they want it to be a measurement and a metric tool for the teams. Maybe the team can use it themselves to help them figure out how much they can take into a sprint or something like that. But almost coach teams away from that at this point. It’s so abused.

Murray: I’ve used it recently to say this is all the things that we promised customers we were gonna do in the next six months. We’ve estimated them in epics. Our team is able to get this many stories and epics done and, oh, look, we’re only gonna be able to get a quarter of what you promised to the customer by the end of the year. So we better do some de scoping. Some replanning some prioritization. Maybe we should address some of the problems we’ve been talking about. It’s not, that accurate, it’s better than the normal Gantt sheet type of accuracy in my experience. 

Todd: I do agree with that and I do use it for that. But as an example, there’s an organization I’ve been working with recently. We were doing just that we were using it to forecast and we were doing estimation on the stories like t-shirt sizing or even story pointing, using velocity to help forecast when that would be done code of uncertainty and all that stuff. But just recently they said, Hey, we’d really like to use this velocity now as a metric for team performance. It always creeps back in, even if you’re using it for the one thing it’s good at, that forecasting. There’s just an innate desire of management to manage. I try to coach them more towards cycle time looking at, lean waste and trying to reduce that over time trying to reduce the number of dependencies, looking at outcomes and not just output and also looking at team autonomy going back to that pattern. If the team’s engagement is low, How are you measuring that? And how are you keeping an eye on your team’s health and how are you removing those types of things. The team gets lost when you look into metrics and you just keep going down the metric path, you lose the human in that. So I try to introduce that back into the equation. Whenever I get that metrics discussion.

Shane: So that one that you mentioned around dependencies, that’s an anti patent that I see a lot. I see teams where they become dependent on other teams or other work being done. They get blocked because there’s this constant handoff, nobody looks at the actual, complete supply chain or the way of working end to end. They look at it in isolation of, a small group of people. And then, those dependencies tend to be the things that kill them. 

Todd: Yeah, absolutely. And it’s not just dependencies outside of the team. Like things, the team doesn’t have control over on its own. It’s dependencies inside the team too. And I find that to be a very difficult pattern to break. I’ve found that there’s quite a few people recently, maybe it’s since COVID happened and remote work has happened, they actually prefer to work alone and work in their specialty and keep their head down and collaboration is actually becoming harder. I find that to be almost an agile killer. I’m fighting that quite a bit these days in teams just to get the team to work together on one thing at a time and get it finished.

Murray: I’ve switched to mostly remote working with one or two days in the office working with teams and that’s because when you go into the office, you’re on zoom all the time anyway, zoom or teams, because everybody else you’re working with is at home or in another state or another country. We used to say face to face. Communication is the best form of communication. 

Todd: It still is. I think. 

Murray: Yeah, but this is pretty good. Like we can see each other. You are in America, I’m in Melbourne. Shanes in New Zealand and we have a lot of really good conversations this way. I can tell how you are feeling from how you look . 

Shane: When I first started coaching, when somebody said to me, what’s the best way of, adopting an agile way of working with a remote team. My answer was. Don’t try It’s hard anyway. And if we’re all in together, then it’s so much easier to form these new ways of working with COVID and this revolution in terms of visual tools to communicate. I think, it is possible now still prefer to do it in person, but I don’t think we ever gonna rebound back to that world. I always saw use of electronic boards, like JIRA. There’s not an anti pattern, but as a difficult pattern, I found that the pattern of people standing in front of physical board was a lot easier than when they communicated over electronic boards. But in, the remote world I’d probably to that now to say actually its hard to have a physical board. So therefore these electronic boards are probably the new patent.

Murray: When I think about agile Antipas I tend to reverse the agile values. And organization’s not doing agile when it prioritizes processes and tools over people and interactions, when it focuses on contracts instead of customer engagement, when it focuses on documentation instead of software. And when it focuses on following a plan instead of adapting to change, and that all happens a lot in agile implementations, particularly in safe. And all of that could be largely put under the umbrella of a traditional bureaucracy. So we’re getting a lot of late adopters now, a lot of bureaucratic organizations adopting agile. And they wanna keep all of their bureaucracy while still doing agile. And I think agile is fundamentally anti bureaucracy. It’s like the opposite of bureaucracy.

Todd: Yep. , they all want a governance system and they want it written all down and you follow it all teams the same. 

Murray: Yeah. Nothing like centralized, standardized agile processes that you can’t change.

Shane: I think there’s a difference between principles, practices, and patterns. The ones that you described are principles. but I don’t treat them as patents for me patents is something I can do given a certain context that typically has value. So I think they’re lower level. They’re actionable things. So typically we reference back to a book that was written on architecture, patents for buildings many years ago. And it was this idea that, depending where your house is gonna get built, depending on the sun, depending on a whole lot of stuff, you would put a lounge in a certain place and you would have certain kinds of windows and those patterns basically helped you build out your house. So it was a bunch of architecture patterns that were usable in a house. And so I keep going back to that. So for me, patents really are at a next level of detail, they’re something that we can adopt or apply given a context, and they may or may not have value. That’s how I describe it. What would you say a pattern is? if you had to give a meta version of it? 

Todd: I definitely think of it as more like behaviors and almost habits. I do think about habits a lot when I think of patterns, like what pattern of behavior are you in? And what is your gut reaction in response to some kind of stimulus? How are you gonna act? And I do tend to associate it with habits that people and teams and organizations have and their default reaction to certain situations. If you use the agile values and the principles as the lens for how you evaluate as a pattern like a good pattern or an anti pattern I think that’s the lens or the measuring stick. You use to figure that out.

Murray: I would say that a pattern is if you’re in this context and you have this problem, then you should apply this solution, that lots of other people have applied in the past. That’s to me what a pattern is. And I agree with you that patterns can be good, bad, or neutral. And you can measure their effectiveness by their outcome or by how they fit with the agile values. That’s how I’d say it. Shane. 

I wanted to move on a little bit, Todd, and ask you as an agile coach, when you’re seeing these sorts of patterns, where do you start? Where’s the point of maximum leverage?

Todd: I like to take a vertical slice through the organization and coach that slice at every level. I have had success with that model because you are coaching the entire chain of the hierarchy in this new way of working in a small way. So I found that to be very effective. It doesn’t always work out, then I’m able to do that. Sometimes I will start, I’ll go right into the team level and focus there and try to show something different.

Sometimes I’ll look at the management level first and try to make that work. But those never are quite as effective as taking a slice of interrelated managers executives all the way to a team and trying to exhibit these new behaviors and new patterns and ways of working and seeing different results.

So I, I do believe you can’t convince them to change. you. Can’t sell them on the new way of working. They really need to try it. And so we quickly need to get into trying these new patterns, deprogramming the old patterns, and then seeing the new results. And that really helps sell the I guess the new way of thinking to them is their own action.

Murray: So you’ve started working with a vertical cuz that’s where your consulting engagement is effectively. But where do you start? Do you start by setting up cross functional teams or do you start somewhere else?

Todd: I will work with a group of managers to focus on say one product area and I’ll take one or two teams in that product area. And we’ll re imagine, will reimagine that team. We’ll reset the team. We’ll form it as a cross-functional team. We’ll help them understand the new behaviors and the new ways of thinking about things and the new ways of operating. Focus on the principles and the things that we’re trying to do and giving some examples of the patterns as we go, and then quickly putting those into action so that we can see different results. So usually yes, we do have to reform the team and recharter them and get them set on a different path. And that includes the management layer.

Shane: When I’m coaching a team, I tend to focus on the team. I focus on the patterns and anti. To other team, but I can often observe a bunch of patents or Antipas in the organization and at the senior leadership. Example is the senior leaders are working based on an annual budgeting approach or basis, they’re time boxing spend by 12 months and then trying to shoe on everything into it, rather than just treating it as, they have a bunch of effort and money that they can spend and the highest priority work will get done.

Todd: So the deadline driven behavior often starts at the highest level and it just trickles down all the way to the teams. So that pattern itself, is one of the ones I have to deal with at the senior level most.

Murray: So I’m just reflecting on the discussion we had with Esther Derby about this. And I do tend to go into these situations by saying you should restructure your teams, but she reminded me that you have to start by identifying the problems of the people who’ve engaged you. And then work on solving those rather than immediately applying your own mindset and your own patterns to the situation because you need to be relevant and you need to produce results and you’ll get maximum leverage if you’re solving problems for the people who have brought you in. And from there, you can work your way up by engaging with more senior people and simply asking them what their problems are and helping them to solve them. 

I would like to be able to use agile, to implement agile, which is to say, to identify problems, put them on a backlog, prioritize them with my stakeholders and then work through them one by one, helping to solve them. And when the solution doesn’t work perfectly going back and measuring the results and having another go and doing something else. 

Todd: Absolutely. That approach highly aligns with the approach I take with leadership. I usually form them as a enabling leadership team in the image of the teams that they’re enabling and supporting, and they have a backlog. We use toyota improvement kata by Mike Rother, quite a bit to help them think about incremental change towards larger goals, and how do they help the teams with the things that the teams are facing that can really help ground them in incremental change. But I also tend to use foundational change at times too. Something like we’ve gotta change the team structure from, specialized teams to cross-functional teams. That’s a more fundamental change. You can’t really easily do that incrementally. So I’ll also work with them on that, but starting with a retrospective or some understanding of what’s going well, what’s not going well. What’s in our control. What’s not in our control. I think that’s a great way to start any engagement with the team or the leadership or some cross section of them.

Murray: I find these days that I am working with middle managers , with programs. And that pretty soon we can identify that the problems they’re having, are outside their control. So what I’m doing is helping them to persuade their senior management, to allow us to make a change that’s in line with an agile way of working. So bringing Devon tests together, for example, into one team, setting up product teams or other things. But increasingly what I’m doing is helping those people in the middle make a case for organizational change to people higher up. And often those people are very frustrated. They can see the problems. They feel they’re not being listened to. But they also quite often feel like that’s outside of my control. That’s outside of my scope. That’s a senior management decision, but what I say to them is they’re not solving the problem. They’re asking you for these things, these deadlines, these scope, this budget or whatever. And they’ve made decisions, which are preventing you from doing that. Why don’t we try making a business case for the change that we want to see and try and persuade them to make those, bigger organizational decisions that will allow us to be successful. And I have had success doing that. I would just like to say that it’s much harder trying to do that from the middle than it is trying to do that from the top. Cause you don’t actually have power or an authority, but as an agile coach, we don’t really have any power authority anyway. So maybe that’s inevitable.

Shane: And that’s one of those anti patents that you mentioned on the podcast on a regular basis, Murray. That idea that the agile transformation is driven by, reducing headcount, middle management by 20%, by some of those large consulting companies. So there’s an anti patent, we predetermined where the costs could be saved. And then we try and do agile to make it happen. 

So Todd, , that example , of alignment of senior leadership behavior with team behavior is one that, interests me because that’s a anti-pain I see on a regular basis and I’ve never actually been lucky enough to be in a situation where I’ve been able to experiment with that. An example would be. We encourage our teams to catch up on a daily basis and figure out where they’re at and where they’re going and what needs to change. But how often does a senior leadership team catch up on a daily basis to collaborate on where they’re at, where they’re going, and what needs to change. Have you seen those patterns actually be successful where you replicate the behavior of the teams at a senior leadership level?

Todd: Absolutely. I believe where I’ve had the most success is where I’ve been able to work with senior leaders, middle management, to form a team to support the teams. And that management team is cross functional. They got user experience leadership. They have technology leadership, product leadership even PMO type people come to this. And, this actually helps them understand and empathize with the team because they’re gonna operate just like the team operates. Their product is empowered, product teams or empowered scrum teams. And their backlog serves that product and this helps them really understand what the teams are going through. It gets them in touch with the teams. They have sprint reviews, just like the teams. If they’re doing scrum, the leadership team has a sprint review to show what it’s doing for the teams and how it’s solving their problems. Their impediments get raised to this team and they work the system and use their political capital to help the teams. And so it creates this nice synergy of helping the teams out, but also helping management empathize better with what the teams deal with on a day to day basis.

Shane: So one of the patterns that I’ve had some success with is getting the senior leadership team to explain to the delivery teams, things that keep ’em awake at night, things they worry about, from an organization point of view. I’d never thought about having the leadership team put into a backlog, the things that worry them, the things that they think need to change. And then that can actually inform the other teams, cuz it’s a backlog. They can see the work to be done. They can see the problems to be solved. So that’s taking that technique or that pattern, and moving it up. That’s an interesting idea. One of the big anti patents I still see is this idea of steering committees or program board. This idea of a bunch of people who come along and deep dive in the detail on problems, but don’t guide the team, don’t remove the impediments. I still see that anti pat in large organizations a lot. What about you two? You still seeing steering committees and program boards.

Murray: Yeah, sometimes they’re helpful sometimes they’re not. I think the biggest problem is when senior management don’t listen. People are telling them things and they’re, not solving problems. So it’s quite common to have a steering committee or governance board and to raise problems there and they just won’t listen to you or they’ll deny it or they’ll turn it around and, attack you because you haven’t done your G sheet properly. That’s why you’ve got all your problems. 

Todd: I think that’s one of the things that this leadership team helps with because they’re there with their peers. If you have one person that is going under the radar and doing things that are counter to what you’d like to be happening it can’t really hide in that leadership team. There’s a bit of positive pressure from the rest of that team that kind of ferrets out or prevents some of that behavior. 

Murray: Yeah, I have been fortunate enough to implement agile ways of working at a executive level in a, hundred person organization when I was in senior leadership. And it’s much easier. Because of your position and your authority people will listen to you and try and do what you suggest. I have been able to, implement daily standups and things like that amongst an executive team. And it works quite well, but fundamentally there’s a mindset at the senior level, which can prevent you from doing this. So for example, you might say, as we’ve often said, that uncertainty is very important that you can’t predict things with certainty. So therefore you need to, take an agile approach and yet people will just flat out disagree with you. And if your CEO or somebody else just says, no, that’s wrong, you’re just not trying hard enough. Then you have to, try and prove your point over a period of time. By saying, okay. I don’t think that’s right because of these reasons, but let’s try what you’ve said and see if it helps. When it doesn’t help you can come back and say let’s try this other approach now to see if that solves the problem.

Todd: I’d say in most cases, they’ve been trying their approach for who knows how long, tens of years or more. And, really, I try to convince them to try something a little different, even if it’s in a small way, one team. A few sprints and let’s inspect the results. Let’s see if we see a difference either in the way the team behaves and, the way the team’s producing the output they produce the quality they have. Are they engaging with each other better? Do they feel more engaged? Are they actually engaging with the customer and, how is that helping them to deliver better? So I think if you can give them to try a small experiment and actually inspect the results, that’s how you start to change their belief. There’s only so many ways you can give a presentation on a new way of working. They really need to try it. Trying, it is key.

Murray: Yeah, I think having agile coaches at the executive level would be quite helpful now having people like us working with senior executive teams and just being a voice for alternative views, being maybe a communication channel for the teams, I think would be quite helpful. But probably. The most common anti patent I see amongst senior management is with ambitious, aggressive political managers going in the wrong direction at, a hundred miles an hour, being very sure of themselves and refusing to accept when it’s not working out.

Todd: Definitely. In many cases there’s only so much you can do about that. If they don’t have desire to change and they don’t see a problem with the way they’re working as a coach, can take ’em to the water, but you can’t force ’em to drink it. At some point, if that’s not going to change maybe there’s another area of the organization, you can be more effective. But I haven’t run into that too many times. I have found that if you can get them together with their peers and you can find promoters in their peer group that are seeing some value and want to try it and have courage that can help soften the edge a bit, on these folks and help bring ’em along for the ride. It can definitely be a mistake if you ignore that person, cuz they’re not on board. I think you gotta pull ’em closer. You really have to understand what’s motivating them. And also maybe where are their problems, as you mentioned earlier, and, how would maybe a different way of approaching , that problem than what they’ve done up to this point, get them different results and see if they’ll try it. Pulling them closer is definitely going to be better than pushing them away. At least it’s worth a try. 

Murray: Yeah, I’m optimistic that people can learn and change. And senior managers are generally very intelligent people. We should be able to demonstrate through pilot programs and results that this way of working makes a lot of sense, because at the end of the day, it does produce better results. Doesn’t it. 

Todd: It really does. It also helps you meet a deadline if it’s real. Okay, you got deadlines. Great. Agile can actually work really well with a deadline. As long as you do the things that would make you agile, if you try to do everything you were doing with, the mindset, you have infinite capacity and you can just work harder and get things done. That’s probably not gonna get you there, but if you use simplicity and you put the customer at the center and you partner with your customer and your stakeholders to get to the right product and you minimize what you build and maximize your outcome, all these things that work, that’s gonna help you get to the deadline. So it’s not like deadlines are an adding pattern in and of themselves. Sometimes you do have a date you have to hit and you should use agile principles to help you get that.

Murray: My experience is that a lot of this sort of stuff comes from the CEO. IF the CEO’s values and behavior are aligned with this way of working then it gives you permission to introduce this sort of change. But if their behavior and values is against this way of working, then, it’s reinforcing through the executive rank that this is not what they want, so it gets undermined. So I do think that the CEOs are ultimately responsible for their organization’s performance by, what they allow to happen. 

Shane: So I’ve seen a pattern though. Where somebody at a lower level in the hierarchy than a CEO is the agile proponent, the person with agile mindset and they have the power to be able to experiment in their silo of the organization. And then I’ve often seen the CEO move on and that person take the CEO’s role, because they’ve shown that this new way of working works. Have you seen that? 

Todd: I have seen that happen. It’s not always something that is gonna be a sure thing. but I have seen if. If you start at the grassroots and you show there is value and it’s seen as valuable from the organization. I have seen people promoted cause of that. Yeah. I find it funny that, we’re trying to coach away from command and control , and power and hierarchy, sometimes you can use that to your advantage. If you’re trying to help people change. If the senior person or the CEO is on board, then you can use that to your advantage, to help give the little, nudge to those that might be resisting at the middle management layer, to try something out. It can be an advantage at sometimes.

Shane: One of the anti patents I see on a regular basis is when we have a change of leadership. So when somebody exits who’s been supporting the agile way of working in that change and they leave and a new person comes in and then somehow that entire way of working gets wiped out. Quickly. There’s the speed of which their anti-pain happens is amazes me.

Murray: Yeah, I’ve seen that too. I have seen to go back to your earlier question, Shane. One of the most agile organizations I’ve ever seen was where they had set up a digital arm and allowed them to be very innovative. And they were very successful with all of these agile ways of working. And then that person got promoted to being the CEO because a board, saw that as a way of solving their problems. And then he applied it to the whole organization very quickly and, they were struggling, but were getting there. Scaling was their big issue. But I have also seen what you’ve said, you are doing agile successfully in your organization and it’s going well. And somebody comes in, who’s a traditional authoritarian command and control bureaucratic person at a senior level and they can wipe it out quite quickly.

Shane: That’s another great. Anti-bank you just identified for me Murray. We’re as an organization, we start to experiment, we experiment in the digital space. We go, okay, let’s experiment over there. Cuz it’s safe. We start to see success in the organization. We start see the change and then somebody goes great. Now get a BA to document what they do as our agile process. And we’ll roll it out everywhere else. I see that as a common anti.

Murray: Yeah, I’ve seen that too at a large telco, they would quite often have, a innovative business unit. And once that had been making quite a bit of money and doing well, they would say, okay, now it’s time to absorb it back into the mothership. It was a language they used. And then the mothership would smother it with all of its standard processes and ways of working, and then it would slowly die. You’d hope it would be the other way around that the, innovative offspring would be able to change the parent and, sometimes it happens, but generally it becomes a struggle of power and authority and you don’t generally have it. And you’re small. 

Todd: Some companies are also looking for, the easy way to get to agile at scale. And to them, we’ll just standardize, every team will do the same thing and that’s the easy thing. But it’s hard work to allow teams to operate within their context and every team to operate a little bit differently. That’s not easy and it does take a lot of touchpoint between the manager and the team, and they need to coach the teams and help the teams craft things to their context. And I think that’s counter to the way a lot of management has worked in the past. They’ve been more hands off and more status reporting and more leading from the ivory tower type of thing. They’re not as used to engaging directly with the teams and helping them customize to their context. And sometimes there’s just not enough time to actually do that as well. Too many things going on too many delivery deadlines that they have to meet. And there’s just not enough time to actually provide the amount of rigor that would take to get to customized teams.

Murray: That reminded me of go to the gemba from lean, go to the work. There’s a lot of commonality between lean ideas and the ideas we’re talking about in agile. Empowered self-managing teams that can do something from beginning to end. 

Todd: Respect for people.

Murray: Managers supporting teams, continuous improvement. But it is hard to get it into senior management, but I’m optimistic. I’ve seen it happen. As a challenge for us as coaches. It’s how we can make a big impact. I wanted to ask you, do you think that agile transformations are an anti patent?

Todd: Is there an end point to change? Is there a finish line? Transformations tend to imply that there’s a beginning and a middle and an end. I think agile is really more about continuous improvement and continually responding to change. Things will never stop changing. So I think it is a bit of a anti Yes. 

Murray: Yeah I think what’s happening in their situations is people coming in with their playbook, either the Boston consulting group playbook or the safe playbook. And sometimes it works. Sometimes it doesn’t bits of it work, but just copying something from another organization and saying, now we’re spotter safe give me my 10 million. Thanks. It’s a good way to make income, but it’s not something that will necessarily work. I like to start with bringing people together in cross functional teams and talking about agile and looking at flow and outcomes and breaking things down into small things. But these days, I think I’m more flexible about let me understand the problem and then more I’ll find some patterns to help solve those problems you’re having here.

Shane: So I love that comment you made about customized to their context. So yeah, anybody’s listening know that Murray and I are not a great fan of safe and, we’ve been pretty vocal about it and yeah, we have had some feedback from the agile community that we don’t have an agile mindset around safe. So if I use that pattern of customized to the context, With those prescriptive methodologies like safe, that’s why it’s an anti-pain. We’ve had a few people on who implement safe at organizations. And if I used a patent recognition for them, what they do is they take safe as a beginning and then they customize it to the context of the organization and then they’re successful. So they use that mindset, they take the patents as successful, outta safe and apply them. They throw the way, the ones that aren’t successful. So for me, that, term customize to the context I’m gonna use that if you don’t mind, because that gives me some clarity about what we see as a good pattern and what we see as an anti patent from an agile practice point of view.

Todd: absolutely. 

Murray: We should go to summary. Shane, do you wanna kick us off? 

Shane: I do indeed. So as I said, patents, and any patents make my heart sing. It’s a term I love. And in a way of thinking that I’ve been trying to adopt for many years with various levels of success. We started off talking about the whole remote way of working. And it still sticks to me that this remote way of working has caused some organizations to bounce back to their traditional way of working. re adopting some of their patterns around command and control. You talked about what I’d call three themes, so the idea of unrealistic deadlines, when we provide stretch goals, as a way of motivating people to do more and less time. So that’s one of the things we should, look out for as a anti patent.

The idea of siloed working high work in progress, hyper specialization is another anti patent thing that we can see. And the third one had been about taking away ownership, removing empowerment is a core thing for anti patents. And then I think , we identified some really good detailed anti patents.

My favorite is, the risk spreadsheet, document it, make it go away. Don’t worry about it. It’s done. I like the anti patent of the watermelon, the team are saying everything’s read and the senior leaders are presenting at steering committees it’s all green. There’s an anti patent of people who are treated like resources. The anti patent of using velocity is a measurement tool, not a planning tool. The anti patent of dependencies outside the team. And the one that I always forget, the anti patent of dependencies within a team is just as important.

I like the idea of using the agile principles as lenses against those patents, it gives us a flavor and we can put those patents into groups which has value for me. I think there’s an anti pattern where there’s a predetermination of where costs can be saved and agile is just a way of achieving that transformation.

And then you came up with a great pattern. I never thought about, which is mirroring the way senior leaders behave with the way teams behave. So the patents or teams are using, if the senior leaders adopt those same patterns, that alignment will do good things. I have a particular thing about Antipas of steering committees and government groups that focus on process and detail.

Anything that has the word agile transformation for me as an anti patent, as you said, change is consistent. It’s not a project it’s not a thing we transform. And another interesting pattern that I’m gonna try and adopt is can we get the senior leaders to create their problems, the things they worry about as a backlog that there’s a visible to the team so they know what they could work on next. 

We can also focus on anti patents for our coaches. Coaches who come in and don’t observe the way the team are working at the beginning, which I believe is an important pattern, just rip into, Hey, here’s how we do it. Yeah. Let’s go scrum. Without even observing what the team are doing and what problems need to be solved. And the last one for me customized to the context I love that term that’s going into my toolkit. Murray. What do you got. 

Murray: There’s a guy called IVA Jacobson who’s been doing quite a bit of writing about patents He has developed something called essence, which is effectively a patent language. Basically there’s a standard pattern for describing good patterns and bad patterns. And what he’s doing is encouraging people to collect those and write them up in a standard way so that they’re shareable and comparable. I think having a standard pattern language is good and there’s been a few attempts to do it in the past. Came from the building architects, as you said, Shane. I know that there’s a scrum patterns. Wiki. In fact, agile came out of an attempts to find patterns for how organizations work and can improve. So ward Cunningham ran something called the C two Wiki. Ward Cunningham is the guy who invented wikis. 

Before the agile manifesto was born, he asked all of the people who were involved and arrange others to work together, to write upper set of standard patterns. They talk about the gold donor, for example. So it says an early form of product owners and all sorts of other things. Have you ever had a look at the C2? Wiki, Todd? 

Todd: Yes, I have. It’s quite interesting. It’s still out there and available for anybody to look at. It, is pretty fun to just follow it where it takes you. We get to see of how they were thinking back then. Yeah, it’s great.

Murray: Yeah. It’s a bit historical, but I think it would be very helpful for us to look at developing patents together as a community because people have become too fixed on scrum or safe or some of the other standard ways of working. And that’s because of commercialization, it’s hard to make money out of patents. Commercialization itself is a pattern. If you look at all the different ways of working in the agile community, you can see that the ones that have been most successful, have a way of making money out of it for trainers and a way of getting a certification, which helps give you a bump in your salary. So commercializing things, is a powerful pattern. 

I wanted to go back to fundamentals. I feel like agile is a paradigm shift in the way of thinking. We’re shifting from a bureaucratic form of organization. And when we are talking about Antipas mostly it’s Antipas that are standard in bureaucracies. So basically there’s a lot of problems with bureaucracies. They’re slow and heavy and top down and hierarchical. They can be a nightmare as a customer, but there is an evolutionary process going on in the world where organizations that are truly agile, innovative, flexible customer focused, are able to compete on the international stage with these old bureaucratic organizations and they’re kicking their ass. That’s what we’re seeing. And that’s why people should do this stuff. 

It’s like the old fashioned monarchies versus the armies of the French Republic. That’s a sort of generational paradigm shifting change we’re seeing here seen here. It’s a very big change and that’s why we keep running into blockers and Antipas, and as coaches, we would like to say, VI revolution let’s change everything, but we can’t do that. We just have to go step by step, starting with people who have problems and helping them to solve them. And there can be a lot of resistance because we’re often talking about fundamentally different ways of thinking about the world and fundamentally different ways of doing things like trusting the team instead of micromanaging them and yelling at them.

I remember having a discussion with a program manager had brought me in to help him on a safe program. And he said, you can’t trust anybody? And I wanna listen to the teams and empower them. I think the teams do have a lot, to say, and they’re telling me about all these things in their retros and you are telling me it’s all bullshit. And they’re just lazy. That is the core of all our problem. I was a little bit more subtle than that though. Todd, cause you can’t tell the person who’s paying your bills that they’re the problem directly. be, a bit nicer. 

Todd: That’s true. When you get resistance, you’re starting to make some kind of a difference as a coach. I think recognizing that as, an opportunity instead of, something painful is part of the key to being effective. 

Murray: Yeah. Esther says resistance means that you’re not solving somebody’s problem. You’re actually creating more problems for them. Or perhaps I don’t understand that you could solve their problem. So anyway, that’s my reflection. What we’ve talked about. I think patterns are powerful. I like your Antipas. You have a drawing of your Antipas, teams can’t win in a broken system. Where can people find that.

Todd: You definitely find that on medium. So I’m a writer and editor for Sirius scrum. I’ve got about a hundred posts on various topics, not just scrum, agile related, lean related product related. Yeah. Check me out on medium. You can look me up on LinkedIn. I have a website coach, langford.com and you could check out me there. It’s got different ways. You can engage with me on that site. 

Murray: That’s been great. Thanks, Todd. Thanks for coming on. I urge people to go and have a look at Todd’s article, the broken system on, medium, and it will provide you with some more context to what we’re talking about. Thanks for coming on, Todd. 

Exit: That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening.