Ep. 112: Real-world Agile Business Transformation Case Study

Peter: 0:05

Welcome to Definitely, Maybe Agile the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, Dave, good to see you today.

‍Dave: 0:15

Hey, it's been an interesting couple of weeks. I think both of us had quite an experience in the last few weeks.

Peter: 0:21

How are you doing, I'm doing good. It's been eventful, it's been busy, it's been lots of great conversations, talking to people about all sorts of different business problems and technology problems. It's been fun the last little while. I've quite enjoyed it.

Dave: 0:36

I was going to say is this the remember, it's not a job, it's a vocation and you enjoy it, so the hours don't count.

Peter: 0:44

Exactly exactly, and we've also been working on our e-book, haven't we? Yes?

Dave: 0:51

Well, speaking of hours don't count. I think this is one of the I mean for everybody in the audience. We've spent as we kind of hit 100, 110 podcasts. We've realized we've got a lot of content there. So we actually sat down, got together and really started trying to condense some of the conversations we've had into the written word, as it were.

Peter: 1:13

Yes, yeah, and so we're pulling that together into a really, really exciting book with lots and lots of interesting guidance all on well, agile and transformation and what goes wrong and what to do right. And, yeah, it should be an interesting read.

Dave: 1:29

Hoping, so so definitely, if anybody's interested, then connect, use the comments, drop us an email. We're looking at getting a bit of feedback from potential readers just to make sure that we're kind of hitting the right tone with what we have.

Peter: 1:43

Yeah, exactly. And speaking of which of tone? What is today's topic?

Dave: 1:48

Well, we've talked a lot about some of the things that we see, and what we wanted to try and do, maybe over a couple of conversations, is talk a little bit about the success stories that we see and sort of avoiding that you know, the rarefied ones that get touted at various conferences and so on, and really look at some of the clients that you and I have talked to, worked directly with and influenced what changes from a digital transformation, agile DevOps transformation, what changes we might have seen to try and use real stories rather than snippets of stories that we've had in the past.

Peter: 2:21

Because we often end up in these conversations talking in the general fashion about things. We thought it might be valuable to our listeners to hear a little bit about a specific case study and sort of work through that a little. And we agree that we would start with one of yours, Dave. So why don't you give us an introduction to the Dave's?

Dave: 2:43

So yeah and this is probably anybody who's worked with me this is one that we name check quite a few times or reference quite a few times, mainly because it was. I always remember when we first started working with the client it was an e-retailer, so they're a retail-based organization competing with the likes of Amazon and Walmart, so a very competitive, classic space where an agile transformation is going to deliver value. And when we started working with them, they knew about agile, they toyed with it in certain areas, but they hadn't really shifted their core development shop away from functional teams to cross-functional teams. So we were in a position to really accelerate that transformation for them and then watch as the ripples went through the organization and I think they really were able to do a lot of great things with it. So it's bottom up in terms of starting with core development, team transformation but eventually really landing across the organization at the business level. So there's sort of a long history there of how they more often changed over the time.

Peter: 3:49

So, thinking back, whereabouts did you start with all of that? Like when you first arrived there, you're saying, oh, here's this big ball of wax and I've got to work out what I want to mold it into. How did you go about doing that?

Dave: 4:00

Well, yeah, and it's like any. I mean, you and I talked about this before. Any sort of organizational change is going to start with an understanding of where they stand today. So there's that. Just what does the landscape look like? What areas do you have to work with and is going to identify an objective for that change? So you don't do agile because it's agile. You do agile or DevOps, or whatever you're going to call it digital transformation. You do it for a reason. It has to achieve some business goal and, like many organizations, I'd say the primary goal was speed to market. As you can imagine, in that retail, retail space, speed is everything right. So it's really. It's not just a differentiator, it's how you compete. To stay relevant is you have to be able to keep up with some very, very capable and fast moving competitors in that space.

Peter: 4:53

So, speed to market being the key driver, what did you do first, to identify where the impediments to speed to market were?

Dave: 5:00

Yeah, so the as we're understanding that landscape. I mean, it was to some extent, you know, if you're going to call us in, you're calling us in because you want agile to be somewhere in the answer to the question, if that makes sense, and so it was solution in mind. Yeah, there is an element of that right, but but also it was. It was actually really well positioned in the sense that there was a solid development shop. They had really capable people, as invariably as the case, but they were. They were sort of shifting slowly over to an agile way of working without really understanding what they were doing. So the first step was really understanding how to structure the teams to serve different customer segments. So that ended up being something where you had, you know, device specific, web and mobile specific teams. There was also different services. So there's a logistics element for you know, warehousing and how do you got product to the customer versus other sides of things, like just retail side of things. So there's either different channels to market or different services that were being offered. That become natural. How we can align teams. We can align teams to deliver in those certain areas and we can start helping them get the right team structures in place, get the right practices with product ownership in place and so on, so that they're really able. You know, half the job is helping a development shop understand what not to do and what to do. That comes partially from a structural shift and it also comes from a rethinking of how work comes into those teams.

Peter: 6:30

What sort of tools did you bring to the table to help them with that structural realignment?

Dave: 6:36

So that's not really where we go, in the sense that we inherited the tool infrastructure, the sort of tooling landscape, oh I didn't mean tools like that.

Peter: 6:45

I mean like from workshops or communication devices or agile tools, not Jira or something on those lines I was wondering what's happened to Peter.

Dave: 6:55

What happened to him? He's left the building. So here one of the things that really stood out is obviously there's an education perspective, and that was really. We had a lot of fun with that because and this is the thing that people forget about the education side. The education side is certainly there to help people understand the vocabulary and how things fit together, but really it's about having that shared experience to team building and in some ways kind of put your hand up and say this thing has to change as we go forward. So there was a lot of energy created from that side. Then we really tackled a couple of things. One was team formation so what? I always look back on this one because the teams actually formed themselves. So again, we facilitated that conversation. But that did a huge amount for the team sort of owning their destiny. That gave us a lift in terms of commitment to the change. And, by the way, we were immensely well supported by the leadership team who have gone on to do great things within this organization. But they sort of supported very clearly from the outset, gave very, very clear direction and backed up that direction, was sort of reinforcing instruction and support and recognition around that. So you were asking about the sort of tools that we may have used. One of them was team formation, one of them was the education piece, I think the bit that, if we look back, that really sort of set things up for success. One was almost accidental in that we and this is a few years ago so we were able to get the product management group all to sit together, so product owners from very different services or products or channels and so on, but all sharing the same space, and so that group again over the years has grown in influence and sort of understanding of the role. But that group really learned off of one another. There was a lot of support and so on that came out of that. That's one thing that came out. And then the other thing that we did, we started tackling the DevOps side. So part of the need for getting moving quicker was how do we get a change that we've agreed out of the door? And this was a great example where there was two sides of the house there's the development side and then there's the IT operation side, and of course they had different needs, drivers and so on, which was causing a bit of a headache. In fact there were even in different buildings. So it's just this classic, you know. You think of anything and everything you can do to sort of separate the two cultures while that was there and that one of the great things that sort of shifted the mindset there. Again, looking back is an exercise that we did, that I always loved doing, which is the Hudson Bay start, and again we'll Google, we'll share a link in this one. But the Hudson Bay start, where we took a tiny change, found a defect, a couple of characters that needed changing, got agreement from the architecture group that this change would have no influence on the system. So then, how do we propagate that change into production? And, of course, we started the journey digitally, got halfway to not even halfway, then had to bounce out because we lost you know, we lost any ability to propagate that change into production, but then mapped out the whole process. So think of it as value stream mapping for the release process and that generated such an appreciation for, if you like, the responsibilities on the development side in order to get a change out. You have a bunch of stuff to do on the development side and also the responsibilities or the service level required on the sort of operations deployment side to accept that if certain things were aligned in the right way, that handoff could be maybe sped up somehow right, and so that that caused a bunch of conversations. Nothing happens quickly, but over the kind of couple of years that we were hands on involved within the organization, we saw releases go from tens a year to hundreds and then thousands. And again, this is what this is, we've talked about this. This is the bit that's really rewarding, because it's not really driven by anything that we were involved in doing. We were distant from so many of the decisions that's being made there in order to see that transformation. But that's the. It's sort of the baton being picked up within the organization going. Ah, the light goes off in their eyes. They're going we get what you're trying to achieve, let's chase this through. And they did that incredibly very, very well, as they went through that over a few years, but very, very quickly in many cases, compared to what we see in other examples.

Peter: 11:13

Yeah, I mean, I've definitely initiated and been involved in quite a few of those types of changes and, yes, it takes, takes time. But I would agree and I've seen that too the great starting point is when you, you identify the 38 steps that it takes to production yeah, and then say, well, okay, the world, what needs to change for each one of these?

Dave: 11:33

Yeah, and people take on that, like the individuals, because we can go in and map it out and go this is what you need to do, and of course, everyone nods their head until we leave and then they go and do whatever they want to do completely different when it's their, their idea, their sort of initiative and they drive it, and so that was a big part of what happened. Now, one of the other things that really drove this and this was really helped from the business side, because, as some of these changes were beginning to take place, there was a realization on the business side that there were opportunities that they may be able to either take advantage of or or get a bigger return on by being quicker to market, and so they really started adopting the practices outside of development, and it pretty aggressively, pretty fast. And this is where I really like working in the sort of high pressure or very competitive competition, like environments, because there's a need to change, there's a desire to look for any advantage that they can pull on and address, and one of the things that was this realization is hold on what we're doing in technology, if we just expand it slightly outside of technology and include some of the business side, so merchandisers or marketers and things like this. We're going to begin to see if we can get the same sort of mindset. We're going to see some returns, hopefully benefit to the business, and I think that that was that's one of the reasons why that change, that transformation has had the legs it has and it keeps going and keeps experimenting and reinventing itself, is because it shifted from being in the IT technology focus change into this is how we get stuff done and it became no hold on. This is how we solve business problems. Now we look at the market and go after that and they had some really outstanding successes in that area, which feeds in. I mean, they become the baseline for the next quarter, the next year and so on. So it's it really feeds on itself and propagates those behaviors.

Peter: 13:39

Yeah, those drivers, the things that are really, really critical, and as you can get it out of just being just one area, I mean because it can start in other parts of your organization. It doesn't have to be IT there are examples of organizations that have started their entire transformation in other parts but it so often is technology, because it's been such a driver over the last 30 or 40 years. Yeah, I think that's a beautiful way of describing it. So, getting to the end of our time, here, today. How would you sum this up? In like you have three favorite moments from this case study.

Dave: 14:12

Let me maybe turn that around. So we've talked a little bit about the things that we did to get the teams launched and these are in somewhat their basics. But I'm drawing attention and the two things I draw attention to was how we allowed the teams to get involved in, how they were formed and what the journey was going to be, but also how strongly we involved technology and then as rapidly as we'd involved technology and I'm thinking of the release process, but there were other changes as well but also how quickly that propagated out to business. All of those are sort of the ideal scenario. I mean, it's one of those things they lined up very, very well. One of the points I'd add to that is the openness of leadership to step in. And now they were guided by some very good people hopefully some of them within our organization, but also they had the talented individuals there who could see where things were going and could drive it. But I think that we were just in preparation for this call. We're talking about the massive influence leadership has and they don't have to come in knowing the answer. They do have to come in with an open mind to explore an experiment, to see if there is an answer that they may be not aware of that could be solving some of the challenges that they're addressing. And I have to say, within that organization that was always there and it wasn't something that just hit you between the eyes when you walked in the door, but over the time that that transformation went, that leadership continuously and, you know, with a push on occasionally and all the rest of it, but they were continuously open to challenging themselves and trying new ideas and keeping what worked and changing what didn't. And I think that's really we talk about it, but I would say we rarely see it which is that real impact of that engagement.

Peter: 15:57

Yes, when you initially start and you ask leadership, I discover what needs to change. Is you?

Dave: 16:07

Yeah, point number one.

Peter: 16:09

Yeah, we need the bottom up and the top down. It won't work otherwise.

Dave: 16:14

Yeah, it won't last, right, you get, you get change, but the sustainable change that sees, you know, quarter after quarter, so and so on, sees that sort of level of engagement is something that is driven from the top for sure.

Peter: 16:27

I agree. Well, thank you, dave. I think that was a really good story. I hope everybody enjoyed running through that. Maybe next week we'll run through one of nine, and I for sure. And if anyone wants to reach out, they can at feedback, at definitely maybe agilecom. And don't forget to hit subscribe so you can find out more.

Dave: 16:45

And, as a reminder, if you're interested in helping edit, kind of give feedback to the ebook. Then again, drop us an email to connect and we'll we'll include you in that. Yeah, that'd be fantastic.

Peter: 16:55

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