Lean agile transformations with Matt Turner

Join Murray Robinson and Shane Gibson in a conversation about the psychology of change in lean agile transformation with Matt Turner.  We discuss how to implement agile and Kanban practices in IT operations, the challenges faced by managers, and the importance of visualising work and understanding flow. We also touch upon the misconceptions and misapplications of agile in the industry. Join us to learn how to be a much more effective change agent.

Read along you will

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

Murray: And I’m Murray Robinson. 

Matt: Hello, I’m Matt Turner. 

Murray: So today we want to talk about the psychology of change in lean agile transformation. 

Matt: Yeah, something that fascinates me and confounds me.

Murray: All right. so tell us a little bit about yourself to start with. What’s your background? 

Matt: So I’ve been in and around IT for about 25 years starting, at the lonely position of help desk analyst. So from a service support, service operations background. Done loads of those types of roles for a long time. I was the person carrying the hot phone, the bat phone, and getting servers back up and running and then managing teams that looked after infrastructure and so on.

And then probably about, halfway through my career I joined an organization that was an online aggregator of insurance, and they were going through an agile transformation, and that introduced me to that sort of world. And I suppose that was just about the time of the nascent rise of DevOps. And so I was in that ops world surrounded by a load of agile people chatting to them, getting to know how they were doing things. And it all made sense. And so it started adopting and adapting how they delivered software to how I could deliver services. That was probably 2008 – 2009, And then was introduced to Kanban and that has been my tool of choice ever since. The thing that makes it makes sense for me.

Murray: What do you think about the view that there is no Ops? Because there’s just DevOps. Developers who manage their own infrastructure by automating everything. So if there is Ops, it’s a very small team. 

Matt: When the portmanteau of DevOps came along, it was people in IT starting to understand that IT was one team and at the boundary of these two sort of silos, they started to meet and mix, and we called it DevOps, and we started to get along a bit better. But then shortly thereafter there was Biz DevOps and Biz Sec DevOps and it’s really our understanding that in an organization, we’re all in the same boat, so we should start working together. 

Statements like, there is no ops frightens people. And that’s a foundational emotion that breeds anger, and confrontation and so on. So the knack of making this okay is to help people understand that you used to feel you were an ops person. You’re now actually going to evolve into something else. You are still useful. You still have knowledge. You still have talent, you might start to play a different role. And at some point we might call it something else when it becomes fully formed.

Shane: Yeah, I really like that idea that fear, makes people less likely to adopt this change. I talk a lot about skills, not roles. But when I say that to people who haven’t done this before, they become fearful that role’s going to go, that skill’s no longer going to be needed. So don’t make them fearful because it will be harder for them to change in this new way of working. 

Murray: When I’ve helped organizations implement Agile as a manager or a consultant, I found that the teams generally had no problem with it. They we’re all facing a lot of problems due to traditional ways of working, and they were quite keen to try Agile. Sometimes I have seen teams that are burnt out because they’re doing terrible Agile in their organisation but generally I find that the problem is with managers, particularly middle managers, who are afraid of losing their empires. 

Matt: I see that also, And it is a scary situation for managers. The role of the manager has been to manage people. So when we invite everyone to consider autonomous teams enabling empowerment in teams. This fear in them what am I going to do? But what we should encourage people to consider is that we are all one team. We’re all necessary. Management is a really essential skill and the people skills are still very necessary in complex adaptive systems. Organization’s are trying to understand the demand and the signals from a marketplace and meet them with their limited capability. That’s a difficult problem to solve. So if you’ve said, we’re going to install autonomous teams and they’ve heard we’re getting rid of you. If you can have that grownup conversation and say, you are still very necessary, but your role is going to change. We’re going to have you do different things. And you’re as necessary to get this work out the door as the technicians are, then hopefully you’ll have less turnover, less churn, all that sort of stuff is costly and wasteful. But if you can dampen the effect and transition into a different way of working then you’ll be ahead of game. So it’s how you do that. How do you make people feel good about doing it?

Murray: Yeah, this resonates with me. I went into a digital organization to do Agile transformation. And I put everybody into cross functional teams and the roles of the functional leaders changed from directly managing people to being a coach and a mentor. To do recruitment, one on ones, knowledge sharing and helping solve difficult problems. So their roles changed to support cross functional product teams. And that seemed to work very well. Everybody took to it well. There was no issues with that. So if I contrast it with big telcos and big banks, which are going through agile transformations with the big consulting firms, what I’m seeing is a goal of eliminating a lot of positions.

Matt: Yeah. And sometimes that’s the entry point into transformation. There is some reason to downsize the organization operational expenditure. And therefore there’s an operating model then designed so we have fewer people. So then we have to then make it work and people look to agility because they think, Oh, that’s going to be cheap and quick. And that’s not the answer at all.

Shane: Yeah, when they come in and the goal is to get rid of six layers of management. That’s the wrong approach. But I agree with you that those skills those managers have are still highly valuable. I often see managers who are great pastoral care leaders. They look after people, they care about people. Something , we often lose when we start moving into this agile way of working. So I’ve seen managers move into that pastoral care role and rock it. They are often good at being able to help make those choices of what’s the next most valuable thing to do for the organization. If managers behave like servant leaders they always have a great set of skills. So the managers don’t disappear they just change what they do and how they do it.

Matt: When technicians or functional people are trying to deliver work, it often slows down and stops. And at that point, it’s not about geeing people up, it’s about understanding why has this slowed down and stopped? Is it a dependency? What are we waiting on? How can we break the dependency? What are our strategies for getting this work flowing again? While the technicians are continuing to work on the problem, managers can go around the organization and try and broker deals. If it’s waiting, because there’s a part of this process needs to be done in a team that we’re dependent on and work is stuck in their backlog. Your manager can go and lobby for it to be put up as a higher priority and try and influence in that way. And that is what we can put managers talents to good use doing. Greasing the wheels in the machine to get that flow consistently moving. They can do things like experiment with how we measure this effectively and just allow the technicians just to keep applying their expertise to the actual solving the problem. 

Murray: What do we do wrong as consultants or change people if we’re going in and trying to help people implement Agile? What are the common patterns you see where people are making it hard for themselves? 

Matt: Not the fault of any one set of people. It’s not just the consultants. it’s also the fault of the people asking the consultants to come in. So if the person asking for a problem to be solved is not really aware of what their problem is, the consultant might take that on face value and try and solve the The problem that we’re asked instead of understanding what is the need rather than the request. The problem is going, this is a cookie cutter. Everything will be all right if you just let me at this problem, because we don’t know, we don’t know if that’s the thing. And that’s not what you want to give people, really. You want to go into somewhere and work with them to solve their problems in their context. 

Murray: What about when the Agile Kanban approach that you’ve been asked to implement conflicts with approaches that they already have, like ITIL? 

Matt: I came out of that service support iTIL background to be a service delivery manager, to pull together disparate service teams, centralize a service into one service department. So the thing was with that, I, Kanban that in a sense of going around those teams and helping those teams visualize the work, because if they visualize the work, I could understand it more easily. I could see where they were amongst all of this demand they were trying to, deliver against. When we visualized volumes of work for these teams, you can see they’re being asked to do too much and they have too little capability to deliver against it. So I could take that back to senior management and show them.

Then, we do things like put on blockers so we could see, which specific ones are having a problem with maintaining the flow and getting them delivered. So some of those blockers would just be one offs but when you start to group them together and analyze them, you’ll find, oh, there’s a systemic issue here that may need some investment in order for us to change how this stuff gets done. That’s when you can say, oh, we do need another person, or we need some of this talent in order to get that flowing again.

It’s more about what problems have you got doing the thing that you think you need to do. And how can we go about improving it? And I just bring a tool that helps me make sense of it. So the blocker thing was brilliant. I used to walk around the teams in the morning, write the blockers down in my notebook, spend the afternoon trying to clear the blockers. So I showed them there’s a different way of managing. I’m here to solve your problems. I’m here to serve you. So it added value. And then really, then we talked about agility practice, so it’s a lean practice. So it’s not all about what you’re used to right now. And there are lots of things out there we could try and adopt to see if it just helps us. And that sort of encourage them to open their mind. 

Shane: My natural reaction is to bring all the work into one team. Let them be able to be end to end, no dependencies outside the team. They just manage themselves. How does Lean and Kanban help us when we’ve got different teams doing different parts of the flow and there is now a dependency and a reliance? What patterns do we have to solve that problem of waiting on somebody else? 

Matt: The first thing that Kanban would say is visualize the work, think big, start small and learn fast. Don’t try and bite off too much too soon. Kanbanise one team, get the visualization, get the flow in one team. Through visualizing one team, what will start to become apparent are the dependencies. 

Then you’ve got an opportunity. Do you bring that set of people within the team. Do you add to their cross functionality so they’re not dependent outside. But there’s probably a boundary to the extent of which you can do that because then all of a sudden you might have everybody in one team. 

So there’s usually always a boundary. So once you’ve Kanbanized one team, once you’ve got them visualizing, once you’ve got them limiting WIP, once you’ve got them deferring commitment and all the things that would help the flow. Then the next team to Kanbanize in that organization would be one that the first team are dependent on. Because then you’ve got a force multiplier. Kanbanize the second team, that second team should optimize a bit. But then also you’ve got the ability to optimize the relationship between the two teams and then build from there. In software delivery, you could bring in things like QAs, and Analysts and UX people, but you’re not going to bring a HR person in or a finance person. So there’s always going to be a boundary, a dependency on decisions being made elsewhere that will affect your ability to get work done quickly. If you have everyone visualizing. Being able to see when those dependencies are slowing us down and work on them then you’re in a better position. You’ll have more resilience. You’ll probably have better relationships across those boundaries because people can explain in a visual vocabulary and therefore understand better the problem the other people are facing. So now I can reset how I’m going to interact and what I’m going to do now. 

I don’t think you can always eradicate those dependencies by bringing them into the one place. So being aware of them and visualizing them and managing them is probably our only way forward.

Murray: So organizations are built on a factory model, like a car factory. And one of the core assumptions of a factory is that there’s little uncertainty, little variance, because you’re doing the same thing over and over again, at speed, because it’s very efficient. But with software development and product development there is a lot of uncertainty. And Agile, is mainly designed to cope with situations where there’s a lot of change because there’s a lot of uncertainty. But from a psychological point of view, it can be quite difficult to get, managers to understand and accept that you have to behave differently in situations where there’s uncertainty. And there’s a lot of uncertainty in software and product development. Are you coming across those core assumption issues and how do you deal with them?

Matt: Yeah, absolutely. It’s easier to see waste in a physical environment. That’s why we use visualization. So , we manifest knowledge work so that we can see it. So , we try and work out where the problems are. Everyone has these same issues. It’s not just managers. The people being managed have also become used to it. There’ll be a lot of people who really like that structure. 

There’s a lovely model, Everett Rogers, diffusion of innovation. In any gathering of people, whether that’s a team or a department or an organization you’ll have 2. 5 percent innovators, and then you’ve got 13, 14 percent are early adopters. And these innovators and early adopters behave differently than some of the others. If you want to get a new idea going, if you want to get a new way of working going. These are the people to find They are the rebels, the mavericks. . So if you come to them with an idea. They’ll give it a go. They’re happy with that risk. They’re not all in one team, they’re amongst other teams. What you want to do is find where they are most congregated. 

If you go into an organization as this person, who’s going to affect some change, we become that beacon the innovators and early adopters will find us they’ll give what we think they should do a go. They’ll find time to do it. They’ll put the extra work in and then they’ll see the positive effect of this new way earliest. What’s really important about that is they provide social proof to get the early conservatives, the early majority they need to see it working elsewhere and then they’ll give it a go. And if you get those people involved, generally you’re pretty much at the halfway point. 

Murray: That sounds like a community of interest. You get them together in a group and you start to nurture them. Is that what you’re talking about? 

Matt: It can be that, but it doesn’t have to be as formal as that. You don’t have to identify as a community of practice and we meet at such and such. It’s just, will you do it where you work? Will you try this new thing? I’ll be the concierge. I will run around giving you whatever you need to get this thing off the ground. So you’re prepared to do it and go against the grain. I will make it as easy for you to do that so that together we can prove that it works in this context. it’s not a model. It’s how does it work here with all of your specific constraints and disablers and enablers? How can you get it working? And you need that to convince the rest of the organization. I 

How often have you, you’ve been in an organization where someone fairly senior might say to you I love the idea, but is there any organization that’s just like us that’s done it? You get that a lot. If they had, they’re probably the alpha now and you’re playing catch up. Do you want the competitive edge? What if you were the alpha? What if you, stole the march on everybody else by working in this way? This way that you’ve just said sounds reasonable and good, but the only barrier is that you don’t want to be the first. You don’t want that risk. The interesting thing is, as we know, not doing it is riskier. That’s the psychology of change. How can you get people doing something that they know to be right and know to be healthy but it scares them in some way. 

The dons of this is Richard Thaler, who wrote Nudge with Cass Sunstein. And they wrote that all about things like how do you get people to prepare for their pensionable age? How do you get people to know what they need to do, which was set aside a little bit of money. And they were just interested in what are these little social cues that you can give people that makes it easier for them to put money aside so that they will enjoy a healthy retirement and so on. It’s things like, how do you get people to stop smoking? Everyone knows it’s, it’s terrible for you, but they still do it.

So we make unhealthy decisions all the time in lots of different walks of life. And we’re talking about how can we get them to do this in a large organization. How can you get them making the decisions they know they want to make, but they’re still not doing it? 

Shane: So where do you think we are in the agile world? When we talk about that adoption curve. Where do you think the world is now in that curve in terms of its agile way of working? 

Matt: So it’s more than cross the chasm. It’s ubiquitous, isn’t it? People are taking it for themselves and maybe misapplying it and misinterpreting it because it is ubiquitous. It’s everywhere and it’s commoditized. And it’s sold in bulk.

And we should guard ourselves from judging people too harshly on where they’re at in their journey. But it doesn’t mean that in the future they’ll be bad at applying Agile. What it might be is that they have to go through that to understand. It might be painful, but it might get them to where they need to be.

Murray: it feels to me like everybody’s saying that they’re doing Agile, And yet, what they’re doing, in most cases, not really agile at all. So there’s a lot of waterfall, which is done in sprints. There’s a lot of Safe, where people are having everything dictated to them. And there’s also a lot of Agile, which is all about cutting costs, particularly coming from the big management consulting companies. It is ubiquitous, but I’m quite concerned that Agile is going down the same path as TQM and it’s just this thing you do because you have to do it. As soon as you got your certificates, you just forget about it again. 

So taking a more positive spin on it. If you have leaders who are showing vision and commitment and that people trust and support and they’re saying we’re going to try Agile, and Kanban and DevOps and , we think it’s going to be really good. People tend to swing in behind leaders that they trust and much more accepting of change in those situations, I think.

Matt: Yeah, I agree. Having leadership involved and having someone as the spearhead of it as the focal point. If they have sway and organizational power, it’s going to propel you forward. But not having them involved doesn’t mean you can’t have a grassroots movement going on and happening, but if, people further up the hierarchy don’t appreciate that and don’t make good use of it, it might come to naught. But what it can do in that sort of small grassroots movement, it can help those people at the grassroots make their lives better by doing it. Because it allows you to get elbow room, it allows you to learn, it allows you to collaborate. You join up those bubbles of learning and of optimization. It can really propel the enterprise forward. If you’re working against that as a leader, then you’re shooting yourself in the foot. If you encourage it then you’re doing well. 

Humans are tribal, if someone’s instilled agility and then another organization poaches them. You fear for what’s left behind. You need to appoint someone from within, that saw that journey happen, that those people trust in order to sustain it. 

Shane: You know, I’ve seen teams that have had a servant leader that have bought a new way of working in. And then the organization hasn’t embraced it, they haven’t scaled it they haven’t changed the mindset of the organization. So that person and the majority of that team leave. They go find an organization that wants to work the way they want to work. Definitely seen the change of the slippers at the top of the organization and the old school this agile. Bollocks, what is it? 

If we talk about adoption, I have a perception that Scrum’s the winner. if you go and look at it, Scrum’s the number one at the moment. 

Matt: So I try not to mention Kanban. I just start talking about flow metrics or deferred commitment. Let’s, for our means of expressing our predictability, I’ll say let’s get the data out. And let’s, from that data, understand how the system behaves when we try and put work through it. I’ll work in places where this is all new to them. And I’ll work in places where they have been practicing Agile practices for a while. And someone might say, we don’t do that, that’s Kanban, we do Scrum. But then it’s easy to point out to them that they do a lot of other things that are from XP. 

And CI, CD, there’s some DevOps stuff. I’m not asking you to stop defining a product backlog. If you want to commit into a sprint. Okay, commit into a sprint, but I’ll show you some data that will suggest the stuff you’re putting in a sprint’s not coming out at the end of that sprint. 

Murray: So to summarize. I think you started by saying it’s not about implementing Agile Kanban or anything else. It’s about how can you help? And it may well be the case that the people who’ve brought you in, may not understand how you can best help them. And it may be that there are other people in the organization that you need to get on side that want different things from you. So you need to be continually asking, How can I help you? Instead of trying to impose the right way of doing Agile or Kanban. 

The other thing I heard you say was instead of talking about Agile and Kanban all the time, you should try and help people visualize the work so that they can understand the problems that they’re dealing with. Where are their blockers? Where is their work piling up. And once they start doing that, you can help them put in place Kanban measures, like cycle time if people are skeptical you can demonstrate that it’s quite helpful for them. They don’t even have to really change anything that they’re doing straight away. If they can visualize the work and understand the flow in the system. And then because they are able to see what the problem is, then that will motivate them to want to make changes And you’ll be in a position then to say maybe you should try this or that or the other thing. 

And then in addition there’s always people who are early adopters who you could work with and then as they start to succeed, other people will start to see it’s worth trying.

And then the last thing we talked about was the importance of leadership saying that they’re behind it and providing some sort of vision and support. 

Shane: I’ve got a couple. First thing I picked up on is that people are scared of change, so talking to them about the fact that the things that you do still need to be done, they just need to be done differently. They start focusing on managing the work, not managing the people.

The second one is kanban gives us a visual way of seeing the flow of that knowledge work. And therefore we can see when the machine’s broken and the big red light’s flashing. 

Shane: And the third one, is when you start this change, those early adopters are going to help you make that change by being successful. 

Matt: Yeah, those summaries are really good. There is one thing though I would say that people aren’t afraid of change. People change all the time. They don’t like being changed. They have to be in control of that change. So what we’re trying to do is bring them along on the change without scaring them. We need to make sure that they feel that it’s something that’s useful, that they enjoy it. They’ll be in control of it. They can tell us when it’s getting too much. They can dial it up and dial it down. And that will bring about more sustained and a higher volume and a higher quality of that change you’re after. 

Murray: Before we finish, do you have a book or a website or anywhere that people can find out more about you? 

Matt: My website for me and my wife is Happus. I work a lot with the people who are the authors of Sooner, Safer, Happier. I do training through Sooner, Safer, Happier also. And I run the EMEA version of the Sooner, Safer, Happier meetup.

Murray: All right. I think we’re done then. 

Shane: It’s been a great session. Thank you very much for your time and we’ll catch you later. 

Matt: Thank you 

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.