How is an agile transformation different

Welcome to Definitely May Be Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, Peter Maddison and Dave Sharrock. How are you today, Dave?

Peter, I'm doing very well. Good to be chatting again. So what is on the agenda for this afternoon's conversation?

So today we're going to be talking about how an agile transformation is different from a digital transformation, continuing our whole uh digital transformation season here.

Well, an extension perhaps of digital transformations or a specific case of uh a digital transformation, I guess, is what we're thinking of here.

Yeah, so when we because when we were talking about this, we kind of said it's it's really it's all about that organizational change. Um but uh and I think you made a very interesting comment before we started that it's it is the organizational change, but these days, when people say, hey, I want to do an agile transformation, it has something of a different connotation.

Certainly. I mean, the if if I if we look back over, I mean, we've been doing this agile thing for a few years now, and some time ago, agile transformations were were about the people. In fact, you can you can hear this now. There are some uh kind of conversations going on online where they they feel something is somehow missing. And I think what we're seeing there is more of a natural maturation of that whole agile transformation conversation. So in those early days, agile transformations were about people, about teams, about how to get closer to the customer, how to collaborate, how to break down the the walls of of process and documentation that had begun really slowing down product development and freeing it up so that people were really um more aligned and in tune with how they could get product out of the door and enjoying the people that were getting the product out of the door, enjoying the time working with them.

Yeah, and that and I think that that entire change in approach to it, I think, is kind of critical. Uh, we'd like to talk about um the the learning that was as we've gone on over the last couple of decades that agile's been around and uh the as a from the manifesto forward versus like I mean there's lots of work going on in the space long before that, of course. Uh so I so that I don't get shut down by people saying otherwise. I am aware of that. The uh but from a from this idea of moving away from the big T agile transformation, we're gonna reorganize everybody, everybody reapply for their jobs, we're gonna put you all into a scrum teams now, we're gonna give you a whole bunch of new titles, we're gonna change everything to a more, well, why are we doing this? And the underlying reasons.

W what I like, what you're describing there is where it's gone, if you like, and it's moved away from how do you collaborate on a team, how do we create a team of individuals and get them collaborating and working together to get stuff out of the door quicker, just closer to what the customer wants, into hold on, that's a great idea, let's re-org, let's do that transformation piece. And this is what we talked about in earlier episodes, if you like, which was the process transformation. And there's inherently nothing particularly wrong with the process transformation concept itself, as we discussed, but the challenge is that especially in an agile context, we're needing, let's say it's 50% process change, 50% mindset change, and the ratio is going to vary, but it's a lot of mindset change. So we're not just introducing a new process for booking vacations or expense reporting. We're we're really changing how people interact and work together, and that combines process transformation with uh an organizational transformation. And I think that's the bit that makes agile transformations really quite, whether it's a unique or a particular breed of transformation, which is they're combining that organizational, the people side, coupled with the process side, and nowadays I would argue definitely with a business side in there as well.

And there's this piece there too, around that when you try to do all of this all at once, you in the impact to the organization is too large. And the organization's ability to absorb that um is is not there. Like it uh there's the the limit to the your ability to unlearn, right?

Well, yeah, it's the the unintended consequences when you make big changes, when everything shifts, the unintended consequences for big changes, big unintended consequences. This is the the headache of it. Whereas, as you're pointing out, there are you know too many moving parts, too many levers, you're not going to be able to uh necessarily end up where you were hoping to. You'll end up somewhere.

How does all of this relate to digital transformation and all of the types of digital transformation that we've been talking about?

I think when you look at agile transformations, we need to roll back to why are we doing these things? And again, anytime I'm starting to talk about why, I'm going to point at Simon Sinek and his golden rule. Uh, because understanding, and this is why I brought the business piece in earlier on. I think in the early days of agile transformations, the why was because it's there, because that's an early adopter mindset and approach to some of these things. Whereas today uh we're recognizing agile transformations, that the scale of them and what we're trying to get to requires an investment and there's a cost associated with it in terms of you know mental uh change, you know, adjusting our mindsets and so on. So you better know why you're doing it. The outcome has to be pretty clear. So that's the first thing that I would perhaps start with. The the second thing that makes agile transformations pretty interesting is the the impact of the people part. So we talked earlier on about organizational change combined with process change. Um, what I had a really interesting conversation earlier today with one of our clients, and they made a just a quick comment, which is really so true, which is when we start coaching people, it feels like the change is slow and takes a long time. So when we view it, it feels like we're really slowing things down. But actually, as those process changes then come in, because you've got the buy-in and the people are on side, the adoption happens really, really fast. The opposite, starting with a process transformation, re-org design. You know, this is where we are, this is where we need to get to, here's the plan to get there, and then pushing that through without bringing the people on board might appear to be quicker. We make lots of progress about the planning and where we want to go, but the moment it hits the people in the organization, what you often find is it sort of skitters off and stops exactly where it is. It doesn't really affect the change. And again, what was interesting about the conversation earlier on is they would talked about a major transformation sort of you know realignment around this is where we want to go. And the buy-in was almost totally absent. So it was one of those kind of clunk. You heard the plan land, then everyone kind of waited to see what they needed to do and then carried on behaving as they normally do.

And so I think there I think is that key piece where we can start to link an agile transformation or and uh the the or another way of putting that is the adoption of an agile mindset, the adoption of the ability to think in and break things in small parts and to learn and realize that the learning is the important part of this. How can I learn from this? How can I iterate and get better at this? And that is in turn one of those pieces that will make your digital transformation successful. Because being able to think that way, being able to look at this massively complex change to your business model, but to start to think about this and well, if I if I've got these uh these outcomes that I want and these objectives I've set for myself that might be a long way out, they can be they can be too far for me to understand. I can look at that and say, there's just no way we're not going to be able to get there. But the if I've started to adopt some of this agile thinking, started to think about how I can look at the first steps, the first things that I need to do. I can move from that I'm trying to plan out this massive change to like, like, what is the first thing I need to do? What what action can I take that I can learn from that will move me towards my goals? And that that's the type of agile transformation, I think, is where the we see the value come in between the two.

Well, and and uh of course we're we're in wild agreement in many of our conversations, but I agree with where that one's going, but also wanted to pull out the that's one of the fundamental differences in many transformations in that uh agile transformations, at least at their heart, right from the outset, are about small changes. They're about Kaizen rather than anything bigger and scarier than that. And the the reason being there are there are many different things coming together and through through experience, I think, as much as anything else. Um, any of us who've been involved in that have learned that there's no point trying to you know get a big lever in and move the whole organization. It it has to sort of snowball up, and you can somewhat plan some of that way, but the reality is we have to kind of take our time and snowball things up bit by bit, small piece by small piece, because so much of it is dependent on the the buy-in, the acceptance, the curiosity, if you like, of the people in the organization.

Yeah, inspiring curiosity.

Lovely way to put it. Um, what do what would you say the difference is in in that sense? And we sometimes hear the talk of small t versus large t transformations. So, where does an agile transformation sit in that kind of idea, or what how would you bring those two together?

So I would argue that uh if you are doing an agile transformation with a large T, as in I'm gonna then that's what I was describing earlier. This if you are going out and saying, okay, we're gonna go agile and on Monday everybody reapply for your jobs, you all now have new titles, you're now called scrum master of the universe, and you everybody's working differently and everything's totally changed, then you're doing it wrong. And that the what we're describing there, the what you were saying before, like at the heart of it, it should be that that smaller uh change within the the pieces. So, like, what are the smaller increments of change that I can start to bring in and introduce uh so that I can learn? Because what worked somewhere else isn't necessarily gonna work here. I've got to understand the context of that in my environment, in how I work, in what we do, in what we're trying to do, what is valuable to us, and how do we work? And that part of it is is missing very often if you say, I'm just gonna blanket one size fits all, you are now all this, because that's where things start to fall apart and the wheels come off the cut.

I I'm gonna kind of try and reframe that whole big T small t piece in there, because as you're describing that, what's going through my head is first of all, that's a little bit, you know, ours is better than yours or yours is better than ours conversation. Um so if I try and reframe this one just for this conversation where the the large T transformation top-down supported by leadership, whereas small T may be bottom-up only. And I think in those contexts, we actually want big T transformation. We recognize, I mean, that's one of the things that there's a lot of um studies show if senior leadership, if executive leadership aren't on side, and by on side, I don't mean funding, but actually recognizing that their role in is going to change as a result of that change, uh, and not just demanding that your role changes, job roles and everything.

And not only their role, but their behavior.

Exactly. Well, that's it, exactly. So they're beginning to recognize it's that inspiring curiosity piece. How do you inspire curiosity in your executive to know to have them be interested in how their change of behavior is going to influence the success of a transformation and how they can recognize it and see it? Because now, I mean, I think we'd both argue that the transformations that move quickly, that are predominantly successful, have more successes than failures on their way, are that definition that I'm just coming up with of um big T transformations supported by the executive who are fully engaged, understanding their behaviors can change, coupled with the ground swell of support that you're getting through. And to your point, small change, not trying to change everything in the next three months, but something which is is paced and some sort of incremental iterative approach to that change.

Yeah. I think we've had two slightly different definitions of big T and Little T in there, but I think both of them are very valid uh in the way of describing it, and I completely agree. That's that's definitely part of it. You need that that leadership by in the uh the moving the authority to the information rather than the information to the authority. The then that there's a whole piece around there that we can start to uh to dissect perhaps on another call. So uh, so how how would you sum up what we've talked about today in three points for our listeners?

So here let me try and pull a couple of things together. Number one, agile transformation is a sort of a uh a triad of you need to know what you're trying to change on the business side, that's going to drive things. It's a process change. The ways of working are absolutely processes. There's a process change in there, but there's also the kind of organizational people and cultural side. And let's for the moment pretend they're sort of three equally weighted uh components of a transformation. That's the first thing I pick up. Um the the second thing I want to pick up is is re kind of reflecting back to what you just talked about on the big t small t transformation, which is more about you for a successful transformation, we need leadership. But there's another statement which is for a successful successful transformation, we need the organization to buy in. And I think that's one of the key things. It's uh it's a little bit like a a seesaw, I guess we'd have to say teeter totter, or you're going backwards and forwards, and there's balance between leadership's involvement, commitment, contribution, and the organization's involvement, commitment, and contribution that comes into that. What would you add? That's two.

Um well, I could I could sum it up as the uh your your last point there is it's the leadership will make it or break it, could be rephrased as leadership alone will not make it, uh, but it will break it if you don't have it. So it's uh the I think um did we did we cover the like the the principles-based pieces, like understanding why you're in this in the first place, like the the reason for doing this is is key.

That uh and that sort of golden rule and uh that we kind of touched on very briefly. I don't know that we went into much detail, but knowing why you're making that change. And I do think that's something that because we hinted at it that the why before is uh when you're early in the adoption cycle, it's the because it's there is sufficient for the why. Well, it isn't at this point. I mean, this has been around for a while. Organizations are coming to the table and they need a pretty clear, compelling narrative with which to pursue that change.

Yeah, awesome. Well, I I as always I loved the conversation, it's always good, and uh really enjoyed some of the areas that we managed to explore there. And so if anybody would like to reach out to us with any feedback, they can at uh feedback at definitely maybeagile.com. And uh I look forward to the next conversation.

Looking forward to it as always, Peter. Thanks.

You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.