#048 - Todd Lankford - agile anti patterns

Foreign.

Welcome to the no Nonsense Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I'm Todd Langford.

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.

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 in Scrum and XP and things like that in the early 2000s, but didn't really get serious until kind of mid 2000s and got heavy into coaching and just really all in on agile and trying to make companies lives better and teams lives better.

And were you one of these people who was a software developer in the beginning?

Yeah, I have a computer science degree. I started out in software development and came up the ranks that way. So yeah, 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 programming and things like that.

Yeah, I think so too. So it's been 21 years since the Agile Manifesto was launched and 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?

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.

Yeah, I definitely agree. We had Esther Dubey on a while ago and she had this concept that if you don't rub out the line, 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 command and control hierarchical behaviour rather than self organizing 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 organisation, 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.

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 team. But in fact it's not really the teams, it's the system the teams are in. 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.

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 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's the management that's the issue.

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.

All right, well, talk us through what the main patterns are that prevent agile adoption.

The top three are over reliance on unrealistic hard immovable 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 them. The second one is when the teams have silos that have high levels of work in progress, work is not finished and as a result he 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, their 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 and you're cutting corners. How can you possibly adapt to changing conditions?

I'm a great fan of patterns and anti patterns. We like the idea of self organizing teams. We want to 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 them a set of tasks, we take away their ownership and ability to organize themselves to do that work. The high work in progress 1, 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 ending pattern that we.

See a lot this. It's 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 out of school. All these patterns are very resilient.

Why is that? What's going on behind the scenes that is causing these anti patterns?

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 it's 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 out of school, they're going to come into contact with the predictive command and control mindset more often than they're going to come in contact with Agile ways of working and thinking.

Yeah, certainly common to see management focused on fixed scope deadlines, high utilisation and so on. And one of the common anti patterns 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 is a common one. It is often coming from outside the teams not working together because senior managers are not working together. And they're not working together because they have their own KPIs which are no doubt set 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 too?

Absolutely. Oftentimes management doesn't even interact with the team. How could they possibly know? They almost see the teams as a pawn or something on a chessboard 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 going to 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 capital 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 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.

I have a pet one, the Risk Management Workshop and the Risk Management spreadsheet that for me is an anti pattern. The risk goes away to the great risk bucket to die. And we never actually mitigating those risks.

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. It might be yellow, but don't worry, it's going to be green soon. You get a lot of green on the outside, red on the inside, 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.

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

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.

I've used it recently to say, this is all the things that we promised customers we were going to 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 going to be able to get a quarter of what you promised to the customer by the end of the year. So we better do some descaping, 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.

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, cone 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.

So that one that you mentioned around dependencies, that's an anti pattern 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.

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.

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.

It still is, I think.

Yeah, but this is pretty good. Like we can see each other. You're in America, I'm in Melbourne, Shane's in New Zealand. And we have a lot of really good conversations. This way I can tell how you're feeling from how you look.

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 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're ever going to rebound back to that world. I always saw use of electronic boards like Jira is 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 new remote world I'd probably have to flip that now to say actually it's pretty hard to have a physical board. So therefore these electronic boards are probably the new pattern.

When I think about agile anti patterns, I tend to reverse the agile values. An 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 want to keep all of their bureaucracy while still doing agile. And I think agile is fundamentally anti bureaucracy. It's like the opposite of bureaucracy.

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

Nothing like centralized, standardized agile processes that you can't change.

I think there's a difference between principles, practices and patterns. The ones that you describe to principles. But I don't treat them as patterns. For me, patterns is something I can do given a certain context that typically has value. So I think that they're lower level, they're actionable things. So typically we reference back to a book that was written on architecture patterns for buildings many years ago. And it was this idea that depending where your house is going to get built, depending on the sun, depending on a whole lot of stuff, you would put a lounge in a certain place and you'd 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 reusable in a house. And so I keep going back to that. So for me, patterns really are the next level of detail. There's 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?

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 going to 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, is 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.

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?

I like to take a vertical slice of 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 that 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 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.

So you've started working with a vertical because 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?

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 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.

When I'm coaching a team I tend to focus on the team. I focus on the patterns and anti patterns within the team. But I can often observe a bunch of patterns or anti patterns in the organization and at the senior leadership example is the senior leaders are working based on an annual budgeting approach or basis. Their time boxing spend by 12 months and then try to shovel 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.

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.

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.

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 got to 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 a team. Or the leadership or some cross section of them.

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 dev and test 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, because you don't actually have power or an authority. But as an agile coach, we don't really have any power or authority anyway. So maybe that's inevitable.

And that's one of those anti patterns that you mention on the podcast on a regular basis, Murray, that idea that the agile transformation is driven by reducing headcount and middle management by 20% by some of those large consulting companies. So there's an anti pattern we predetermine 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 pattern 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?

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've 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 going to 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.

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 them 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 because 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 patterns I still see is this idea of steering committees or program boards. 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 pattern in large organizations a lot. What about you two? Are you still seeing steering committees and program boards?

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 Gantt sheet properly. That's why you've got all your problems.

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 could, you 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.

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 stand ups and things like that 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 have 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 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.

Yeah, 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 get 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.

Yeah, I think having agile coaches at the executive level would be quite helpful. 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 pattern I see amongst senior management is with ambitious, aggressive political managers going in the wrong direction at 100 miles an hour, being very sure of themselves and refusing to accept when it's not working out.

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, you can take them to the water, but you can't force them to bring 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 them along for the ride. It can definitely be a mistake if you ignore that person because they're not on board. I think you got to pull them 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. Give 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.

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?

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 going to 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 going to 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.

My experience is that a lot of this stuff comes from the CEO. 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.

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?

I have seen that happen. It's not always something that is going to be a sure thing, but I have seen 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 because 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 some times.

One of the anti patterns I see on a regular basis is when we have a change of leadership. So when somebody exits who has 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. It's the speed at which that anti pair happens amazes me.

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 the 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 getting there, scaling was their big issue. But I have also seen what you've said. You're 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.

That's another great anti bang you just identified for me, Murray, where as an organization we start to experiment, we experiment in the digital space, we go, okay, let's experiment over there because it's safe. We start to see success in the organization, we start to 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 pattern.

Yeah, I've seen that too. At a large telco they would quite often have a innovative business unit and once it 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 was the 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 when you're small.

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 point 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.

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. Respect for people, 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 it's 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 pattern?

Is there an endpoint 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 pattern. Yes.

Yeah. I think what's happening in these situations is people coming in with their playbook, 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 I'll find some patterns to help solve those problems you're having.

So I love that comment you made about customize to their context. So yeah, anybody who'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 customize to their context with those prescriptive methodologies like safe, that's why it's an anti pattern. We've had a few people on who implement SAFE at organizations and if I used pattern 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 patterns that are successful out of safe and apply them. They throw away the ones that aren't successful. So for me that term customized to their context. I'm going to use that if you don't mind because that gives me some clarity about what we see is a good pattern and what we see as an anti pattern from an agile practice point of view.

Absolutely.

We should go to summary. Shane, do you want to kick us off?

I do indeed. So as I said, patterns and anti patterns make my heart sing. It's a term I love and 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 readopting 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 in less time. So that's one of the things we should look out for as an anti pattern. The idea of siloed working, high work in progress, hyper specialization is another anti pattern thing that we can see and the third one have been about taking away ownership. Removing empowerment is a core theme for anti patterns. And then I think we identified some really good detailed anti patterns. My favourite is the risk spreadsheet. Document it, make it go away, don't worry about it, it's done. I like the anti pattern of the watermelon. The team are saying everything's red and the senior leaders are presenting at steering committees it's all green. There's an anti pattern of people are treated like resources. The anti pattern of using velocity as a measurement tool, not a planning tool. The andy pattern of dependencies outside the team and the one that I always forget. The anti pattern of dependencies within a team is just as important. I like the idea of using the agile principles as lenses against those patterns. It gives us a flavor and we can put those patterns into groups which has value for me. I think there's an anti pattern where there's a predetermination of where cost can be saved and agile is just a way of achieving that transformation. And then you came up with a great pattern I've never thought about which is mirroring the way senior leaders behave with the way teams behave. So the patterns of teams are using if the senior leaders adopt those same patterns that alignment do good things. I have a particular thing about Anti patterns of steering committees and government groups that focus on process and detail. Anything that has the word agile transformation for me as an anti pattern, 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 going to try and adopt is can we get the senior leaders to create their problems, the things they worry about as a backlog that is visible to the team so they know what they could work on next. We can also focus on entity patterns 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, what problems need to be solved. And the last one for me, customize to their context. I love that term that's going into my toolkit. Murray, what do you got?

There's a guy called Ivar Jacobson who's been doing quite a bit of writing about patterns. He has developed something called essence, which is effectively a pattern 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 that came from the building architecture architects, as you said, Shane. I know that there's Scrum patterns Wiki. In fact, Agile came out of attempts to find patterns for how organizations work and can improve. So Ward Cunningham ran something called the C2 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 a range of others to work together to write up a set of standard patterns. They talk about the gold donor, for example. So it's an early form of product owners and all sorts of other things. Have you ever had a look at the C2 Wiki, Todd?

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

Yeah, it's a bit historical, but I think it would be very helpful for us to look at developing patterns 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 patterns. 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're talking about anti patterns, mostly it's anti patterns 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. It's a very big change and that's why we keep running into blockers and anti patterns. And as coaches we would like to say viva 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 who brought me in to help him on a safe program and he said, you can't trust anybody. I want to 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're telling me it's all bullshit and they're just lazy. That is the core of our problem. It's a little bit more subtle than that though, Todd, because you can't tell the person who's pay bills that they have the problem directly. You gotta be a bit nicer.

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.

Yeah.

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

You definitely find that on Medium. So I'm a writer and editor for Serious 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, coachlankford.com and you could check out me there. It's got different ways you can engage with me on that site.

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.

All right, thank you, Marinchi.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.