Video details

Agile Transformation Or Just Another Restructure? by Terry Haayema


Is your Agile transformation just another restructure?  Is everyone being shuffled around into Tribes?  Villages?  Crews?  Are people reporting horizontally into Chapters?  Is there talk of how we need to go faster?  Were decisions made behind closed doors?  Was the focus on structure as if that will change everything?  Consultants engaged who created lots of PowerPoint presentations with lovely motherhood statements about how our people are our greatest asset and the new structure will break down silos and allow us to go faster?
Then it’s announced, teams are shuffled around into squads, tribes, chapters, etc..  As the transformation builds up speed, everyone gets some training and there is a massive amount of change management comms, presentations, and events.
Big up front plans,… Big bang change,… Heavy Change Management,… Does that sound like waterfall?
In this talk we’ll discuss a better way by actually being agile about the way we approach agile!
More details:
Conference Link:


Welcome everyone to the session by Terry. The session says agile transformation or just another restructure? A quick introduction about Terry. So Terry is an international author, speaker, award winning coach, coach, mentor, conference host, and a leader in agile community with more than 30 years of experience in leading major projects and agile transformation for some of the largest and the most significant organization in the world. Terry's personal mission is to help people see differently so that they can find the joint joy. So without much delay, I'll hand over it to Terry. Over to you, Terry. Thank you Karthik, for that lovely introduction. And thank you to all of you for investing your time in learning and being part of a community today. It is an honor and a pleasure to be with you today. As Karthik mentioned, I'm going to talk to you today about agile transformation or just another restructure. And I've subtitled it transform your transformation. This is important because a lot of organizations are going through these kinds of transformations at the moment. And what I'm seeing is some of them it just seems like another restructure. So maybe it's time for us to have a conversation about that. So, as Kartik said, I'm an author, host, speaker, coach, consultant, all the things he said there and the important thing there is my personal mission to help people see differently so they find joy. And I'm blessed to be in a role and in an organization where I get to express that mission every day. It's why I'm speaking to you today. It's why I wrote my book. If we can see the world a little differently and it brings us joy, then we've achieved something together. So let's have a look at how we usually go about these agile transformations. And this isn't going to be exactly the same everywhere. This is like a common scenario. And if you find that some of these items don't necessarily apply to you, that's okay. But if half or more of them do apply to you, then maybe there is an opportunity to do things a little differently. So when we approach an agile transformation, we usually start by engaging consultants. So you have a group of leaders who have heard about all this agile stuff, but they really don't know how to go about it. Rather than retaining accountability for the outcomes, they'll go and engage consultants so they can effectively divorce themselves of accountability, but also because they believe the consultants have the answers. And depending on who they get, those consultants can come along and say, here you go, here's the perfect answer to everything that you're facing, even though it's not necessarily relating to the context of the organization. When we've got the consultants engaged, we create plans. The biggest problem with the plans that we create at this stage is that we're doing them behind closed doors. We're doing them where consultants are engaging with leaders, but not with the organization. They're not engaging with the coaches that are already there, they're not engaging with the people on the teams, they're not actually understanding the context. So those plans that they create don't necessarily align with what's really happening on the ground in that organization. When we've got some idea of a plan together and a lot more will continue to be invested in that plan. As time goes on, we start to create documents. The big thing that's happening recently as we're calling those documents play books as if they're not documents. There's something else. When we think about all of the documents that are created along the journey to getting our plan set up, there's actually an enormous investment in documents before we've actually done anything, before we've actually tested something and seen how it fits in our context or learned. When we've got some of those documents together and we're along the lines of creating our plan, we're still working on the plan, we start to design the structure. And the big problem I see with this is that the structure for an agile transformation seems to be an exercise where leaders are shuffling people around in boxes. They've got the idea of a team. Sometimes we're going to call that a squad because that makes an enormous difference. And we're putting names in boxes as if the ideal structure is going to solve all our problems, and as if the people who are very senior in that organization can understand the context well enough to know who should be working with who and on what. When we've got a little bit of structure together, that then necessitates redefining roles. We decide then that project managers are now scrum masters, which may or may not be a good idea, but we're making those decisions again behind closed doors. And sometimes those project managers don't want to be scrum masters. Sometimes those project managers are perfectly happy being project managers. Sometimes they're not too keen to have their role changed in a meeting that they're not attending. We decide that certain Bas is going to become product owners. We change all these roles. I've seen transformations where we decide that the coaches are going to only be working with the teams, they're not working with the leaders anymore, and the coaches don't really want to do that. We often sideline those with context at this stage. So while we're redefining the roles, the coaches in the organization, or maybe certain people in the L and D space in HR gets sidelined. The consultants don't really very often want to adapt the plan that they've brought. So they will just barrel ahead with their plan regardless of what those people who have context will bring up. And then we define ways of working as if we can have one way of working across an entire organization. Very often there will be a particular framework that's chosen, and the one I see all the time is scrum. So all of these ways of working, definitions get into the playbooks around Scrum, which is fine for teams that can do Scrum and are happy to do Scrum and want to do Scrum. It's not so good for the others. And in some organizations you do have people who are providing things other than software where maybe they don't have the kind of a backlog of work that they can plan in Sprints. You know, some people can. And certainly as we go outside of software, you're thinking marketing teams potentially could do Scrum if they want to. Legal teams maybe can. Customer service teams, maybe not. Maybe it's very hard for them to know what they're doing 02:00 p.m. Tomorrow, let alone two weeks from now. So defining ways of working is very, very complex if you want to include the whole organization. But it tends to be follow one framework or another. And then we make announcements. And I'm sure you've seen this. We have town halls, we have leadership announcements, we have email going out and comms, and there may well be posters put up on the walls and slides put up on screens. And it's a big razomataz. And yes, we're going to do this great transformation. It's going to change the world. Everyone is going to love it. And yeah, we kind of let everyone know that this is happening with a great deal of positivity and panache and make out that it's a really wonderful thing. And people hear that and they come along with it. And we start to apply change management. And this is kind of where the roller coaster comes along. We have at some point let it out of the bag that this is happening, especially as we started to sideline those with context and roles, discussions were coming up. So people actually have heard that this is coming even before we make the announcements. So change management can be quite a roller coaster of people going through literally emotional highs and lows as a change. They don't understand, don't see how it's valuable, don't particularly want is inflicted upon them. And then we conduct training and we sort of think that the bulk of the work has been done and now it's kind of in an adoption phase and people are ready to take it all on. Now, I don't know about you, but if we're doing our planning upfront and we're creating lots of documents, getting to effectively a go no go decision when we make announcements, which is kind of like a Big Bang release, having changed management after the release, sounds to me like that's actually a little bit waterfall. It sounds to me like we're not being very agile about our agile transformation. Big upfront plans, heavy documentation, big Bang release, change management all sounds a little bit waterfall. This is a picture of Niagara Falls that I took a couple of years ago when we could still travel. So what's wrong with having a waterfall approach to an agile transformation, I hear you ask. Well, there's a number of things wrong with it. Firstly, we're doing all our thinking at the beginning. We actually think we can just define the perfect plan. We create our plan without any of the things we're going to learn along the way. Now, if the consultants we engaged have done this many times within our organization, not just similar organizations, but our organization, then maybe there'd be a chance. If we've done this many times in our own organization, it should be getting repeatable. But this is the first time we've done this in our organization, so it's not something that's ready to be repeatable. So doing all the thinking at the beginning, not such a good idea. We also end up with meaningless measurement. One transformation I saw was all about speed, as if speed is the only important thing. I don't know about you, but if I am going in the wrong direction, then I don't particularly want to go faster. You're better off actually to pause and find out what is the right direction. So speed is not necessarily the most important thing. But then in that same transformation, the word velocity was used and there were actually commitments made that we were going to double our velocity, except we didn't know our velocity. So I don't know how we're going to make any meaning out of a measurement that we can't measure. And if you can't measure it, you can't manage it. So because we've done the planning up front and because consultants who don't know our context are helping us to create that plan, they decide on measures that we either can't deliver or they don't have a lot of meaning for us. So speed is the perfect example. We've made all our decisions divorced of the context especially that moving people around into their different boxes. We don't know if they want to work with the people we've put them in boxes with. We don't know, other than their sort of title, what is the right reason for them to move. We're just rebuilding a structure and hence the title for this talk. Is it really a transformation or just a restructure? When we put so much effort up front into what the structure will be, we effectively turn it into a restructure, even if that's not the intent. The other problem with creating a big plan at the beginning is that we get emotionally attached to it and then rather than being open to change, anything that proves that the original plan wasn't so good becomes a bit of a challenge. We actually need to prove that it's a good plan, otherwise it will become visible that we're not especially good at planning. So when we invest too much in the plan up front, then we become emotionally attached. And when we're emotionally attached to the plan, then we resist change. And that's not very agile. And the other thing that comes into it, especially when the decisions are being made by leaders, when they're being made up front and when they're being made behind closed doors, is politics comes into it. So we see leaders clinging to the space that they lead and trying to actually create a bigger space. And I have seen politics be quite destructive at this stage of a transformation. So what we end up with is a whole lot of effort before we can get going. And then at some point we're going to ask someone to sign off on it. Someone the most senior person in the room is going to have to sign off. Now, if we go to the Agile Manifesto, it tells us customer collaboration over contract negotiation and anytime we have a sign off, we're creating a contract. So our leaders have created a contract that impacts the people in the system and quite often without talking to the people in the system. So that's what's wrong with that. But even if we take those things into account, if we've got the right people driving this forward, what could possibly go wrong? Well, the people that we are announcing this to when we do our Big Bang release have heard it all before. We had a structure a few years ago, a restructure, and turns out it was just a way to let 200 people go. So 200 people were made redundant and then we had another restructure a couple of years later. And that one was all about breaking down silos and increasing the speed at which we could get things done. Turns out another couple of hundred people lost their jobs. It didn't actually break down silos and it didn't help us go any faster. So people start rolling their eyes, heard it all before, been there, done that. And even if we tell them it's not a restructure, it's like, yeah, well, we've heard that before too. I've seen this directly, especially when we're changing people's roles, it creates an awful lot of worry and anxiety. One organization I was engaged with, a huge number of people actually resigned even before the change was announced because they had seen it happening in another part of the organization and they worried about their livelihoods. They have a responsibility to their family, they need their income to continue. So they started looking elsewhere. That's going to happen if we allow the worry and anxiety of not talking to them while we're doing all these plans, making all these decisions behind closed doors. Fear, uncertainty and doubt. Even those people who aren't necessarily worried about their position don't know what's happening. There is fear from uncertainty. They don't know that this change is going to impact them negatively or not. They doubt the intentions of those people who are leading the change because they've heard it all before. And that's another key to what makes things go wrong. And the reason I put Smiley's here is because the thing to remember is everything we're doing in an agile transformation is about people. So when we don't include those people in our thinking, we don't include those people in how we're going about it, we sub optimize. That would be like designing your product without talking to the customer. If we're going to be agile about this, we want to talk to the customer about the product. And the customer of our transformation is the people that it impacts. So why are we making all those decisions without talking to them? The other thing is the people who are on the teams that are going to be called squads and that are being moved around as names in boxes and having their roles changed, have no accountability for the outcome. They weren't part of the plan, they didn't actually buy into any of the decisions that were made because they weren't at the table. So they have no accountability for making it work. And the last point here is we still need escalation when it comes to the transformation and something emerges. We still need to escalate to the leaders because they have signed off on it. So any change to what we're doing has to align to what they want and what they're expecting. So we have a lot of things that need to be escalated. That means we can't be as quick or as nimble or as agile when we're actually helping the organization to transform. So there's a lot that can go wrong when we make all our plans up front, when we do make decisions behind closed doors, when we create big documents, when we get emotionally attached to the plan, there's a lot that can go wrong. And the biggest thing I think that can go wrong is that we believe we've created certainty. So the plan bringing in the best consultants we can, the documents, the structure that we designed, the Big Bang release and all the announcements are perfectly planned and scripted and even the emails have been prewritten. You know that the training is in place and we feel that that is the effort needed to transform. But at the point where we think we can see the light at the end of the tunnel, we may actually be looking at an oncoming train. So let's talk about how can you transform your transformation. This is really the happy part of this talk because it's not just about the things that can go wrong. When you have a big upfront plan, when you engage consultants from outside the organization, when you have a Big Bang release, those things are one aspect of it. But what I'd really like you to walk away from here today with is some things you can actually apply so that you can transform your transformation and do something a little differently. So the first thing is clarity on why make the Y front and center. If it's not absolutely clear why this transformation is happening, then people just aren't going to buy into it. Make sure the why makes sense to a sane, thinking, intelligent person. Don't make it some motherhood statement that doesn't relate. The other thing is don't make it speed because why do you want to go faster? And can we go faster at the expense of other things? It's actually normally not about speed. It's about the outcomes that speed creates for us. And make sure people know also that even if we are talking about going faster, that doesn't mean we can deliver shoddy work or take risks or ignore our customers or any of those other things. It's not just about speed. It never is just about speed. But even if it is, make that very clear. And when we've got a clear why, think about what that means for a vision. And just like with a product vision, that helps us to see where we're going so that we can decide what we want to do. We can decide priorities amongst all the things we want to do. And it even helps us to know how to go about what we want to do. For a transformation, our vision is about who we will become, who do we want to be in the future. What is it about being an agile organization and being transformed that's appealing? And what is it about that that's appealing to everyone? Starting from our customers and next with the people who directly serve our customers and sort of moving back through the organization and up the hierarchy after that. If this is first about customers and equally then about the people who do things for our customers, you'll have a much more compelling vision than simply talking about we need to go faster. And with a vision of who we want to become, we can break our vision down into agility streams. Don't treat it as one great big bucket of stuff. It's not just transformation. And by that I mean think about business agility. How effectively are your business teams working with your technical teams? Or your operations teams or support teams? Think about your technical agility. Have you separated deployment from release? How effective are your DevOps practices? How mature are your delivery pipelines? It's also about delivery agility. How effective are you at delivering and delivering at reasonable speed? High quality, well scoped pieces of valuable customer outcomes? Think about leadership agility. How quickly can your leaders respond to the system? How readily can something be escalated, resolved and back again? Think about the learning culture. Think about lean portfolio management funding agility. That's a really important one. HR agility so you've got all these different areas to consider. Thinking about your vision and what needs to happen in these different areas will help you to think about the transformation differently and help you to approach it differently, help you to also approach it from the idea of proximity based planning. So rather than a great big plan, we have a vision, we break that down into smaller pieces and we only deal with the great detail on the things we're doing next because they have proximity. Those things we're not doing for a while. We don't need as much detail on because too much will change before we get there. When you've got your vision, you've broken it down into some agility streams. Start to make your customer value streams visible. So these aren't necessarily the steps a customer goes through to achieve value. So that's one way of looking at a customer value stream which might involve multiple teams and multiple systems, but think more about the sort of the subsets of that so that you get reasonable size spaces. Because you might think, for example, a customer achieving a certain thing involves the whole organization. So try to think of discrete and specific value streams that you can. Then think about who is in this in total. Not just the technical teams, but the customer service team or operations or support. Start to bring those people together. You don't need to restructure to make a customer value stream visible. You don't need to restructure to start establishing collaboration amongst the people in those value streams. The next thing I'd suggest to you to transform your transformation is to involve all the people in all the discussions. Now maybe as an organization you've decided to pilot in one small area or to roll out in different areas rather than all at once. Involve all the people in that area. If you've got a value stream that's visible, include the support teams, the customer service teams, the operations teams, the business teams, the marketing teams, the HR people. Include them all because they all bring a context when the time comes to actually do something. Your change management is a piece of cake because everyone is across what's happening. They may still need some training or some other support, but change management gets a whole lot easier. When people are involved in the discussions about why we're doing this and when things are happening and how they're happening, they feel involved. They're also because they've been heard and it's their space, they're much more accountable. So with that, start to break it down into small bitesized outcomes. Not deliverables, but outcomes. We know who we want to become. We've thought about the different agility streams, we've spoken to all the people that are impacted. Let's together break down that vision. So how do we become those people that we defined in our vision, that organization that we defined in our vision, how do we get there? Is to break it down into smaller outcomes and then have everyone on the journey of like, which is the first, what's the priority? Just like with any kind of product delivery, we don't try and do it all at once. We don't want a big bang release with high risk. We'd rather smaller bitesize deliverables that we iteratively and incrementally build up to create massive customer value rather than, you know, big bang release. That's kind of how we operate with an agile project or product. It doesn't tend to be how we operate with agile transformations though. And my suggestion is it should be. Once you've broken it down, just like with your product delivery, prioritize and do the smallest, most impactful thing. You can use weighted shortest job first. You can use a pick model, you can use a whole bunch of different priority techniques and get on with the smallest thing, whatever is the easiest to deliver and has the biggest benefit, that's the thing to do first. With a prioritized backlog, you're in a great position to get on with it, but be agile as you get on with it. Again, we don't want a big bang release, we don't want a wholesale structure change and turning the whole thing just into a restructure. We just want to be moving towards an agile transformation. And measure, measure, measure. If you do decide that your agile transformation is going to be about speed, how are you going to measure that speed? You certainly don't want to be using velocity or something that teams use for something else. If we take a measure and use it as a target, you won't be able to use it as a measure anymore. So velocity is not a good example. Maybe it's revenue, maybe it's happiness, that's one of my favorites. If you measure happiness that will give you a good indication that this is actually working for the people who are doing the work. But then once you decide how you're going to measure, make sure you can measure it. If you don't currently measure it, you might need to do some work to start measuring it. But whatever it is, start it, baseline it and then keep measuring it. The other thing we don't tend to do in the classic transformation is review, learn, adapt and improve. And in this case, as you see from the image, small change. So we don't seem to be able to allow small change to trickle in because we've done so much upfront planning, we've done so much upfront documentation because it's been signed off by someone very senior. Any change needs to go back up to that senior person for sign off. So reviewing, learning, adapting and improving and changing a very, very difficult when we approach our agile transformation is just another restructure. So my suggestion to you is step back from all those big upfront things and make sure you're ready to accept small changes. And when you're in that position, you're now in a series of iterations. You've done the smallest thing you have observed, listened, learned, taken on change. You are talking to the customers of this change or those colleagues of yours that are impacted and you're ready to do the next smallest, most impactful thing, always reviewing that backlog, always going back to your vision. Is this still the most impactful thing that gets us closer to our vision. Rather than, again, having that big upfront plan and just barreling it out, you need to start operating in those iterations, small impactful things that you deliver incrementally and iteratively with a learning loop so that you can continue to get better. And at that point, it's a matter of rinse and repeat. Once you've done a couple, you'll be surprised how quickly the changes start to mount up. You may not have restructured, but you've created a lot of positive change. And at the point where you get ready to restructure, the structure will be obvious because you made the value streams visible, you involved the people in the conversation, you iteratively and incrementally made small changes that got you closer to your vision. The people who belong in that value stream are already working together. It's really simple and obvious at that point what the structure should be. Designing the structure upfront, that's really hard. Allowing a series of small incremental improvements to help bring together the people in that value stream makes it really, really easy to know who belongs there. And the other thing I'll say to you is, at the end of the day, every organization is made up of teams and every team is made up of individuals. There's an awful lot written on highperforming teams and agile organizations, but I wrote this book to help people understand that it's actually about individuals. And if we can uplift the agility of all the individuals in an organization, then we've uplifted the agility of that organization. Thank you. So, Kartik, could we move to the questions? Sure, Terry. So I see a couple of questions for you. So the first question for you, Terry, is that can you talk about the development manager role? The attendee find it bit strange as the role is responsible for people, but without involving in day to day execution, it is difficult for this role to poach people without engaging himself into an execution of EI is his first question for you. Thanks, Kartik, and thank you very much. To whoever asked the question, I'm very, very grateful. It does take some courage to actually ask what's on your mind, so I'm very grateful that you've done that. Sorry, but you're not going to like my answer because this is a perfect example of a role that was created without talking to the people who are doing the work. This is a perfect example of an upfront transformation. If we have a role called was it delivery manager? And it's not all that clear to the people around that role, what that role does or how it operates or how it is valuable, then it's probably something designed by the consultant who took out of his pocket is the perfect plan. And in our plan, we don't have project managers, we have delivery managers and we have scrum masters. Do you know what I mean? So it really depends on what's been. Defined by your organization. Possibly the Delivery Manager is some kind of a partial project manager with line management. So I have seen that before. I've also seen Delivery Manager as something of a pseudoscrum master because they didn't like the word master, so they had to call it something else. I've seen that as iteration manager as well, but it's a difficult question to answer as far as what happens in your organization, but I have seen that as another example of building the structure upfront, deciding the roles up front, and then when it comes to implementing them, we're like, I don't really know what that means. So I hope that answers your question. Thank thank you you so much, Terry. The second question for you Terry, is that can we elaborate more on business Agility and HR Agility stream? Sure. So it's probably a deeper dive than we have time for today, but do some googling on that. So business Agility, there's a group of people called the Business Agility Institute and they have published an awful lot of material about how to be agile as a business. The idea really, if we just sort of put some high level sort of headlines out, is that Agility is not just about the team who are building the software. Alright, let's say for example, a team is building software for a call center. So you've got people in a call center answering customer calls and they use a piece of software. We've kind of thought in the past of Agility being something that belongs to this software team, but business Agility actually brings those people together and it effectively says the quality of our customer service is not just having great software, it's not just having great people answering the phone. It's actually the two of them together. And when we sort of get like further down that track, we bring more and more people together. It's actually about bringing people together so they can collaborate and share a context. You do get really big wins when you bring people together. I've seen large complex things become an awful lot simpler because people can see how each other work. I've seen teams themselves bring enormously valuable changes because they were talking to each other rather than just delivering a project. So that's kind of a big headline. If you look at the Business Agility Institute's material on transformations, they actually say as well, change structure last. So are there more questions? Yes, we have two more minutes. I'll take one more. So one of the attendees that asks how HR and leadership management will fit here, what would be the outcome for them? Okay, I may not be entirely understanding, but we're saying from a leaders point of view and from HR what's good for them out of this. So it does involve a different way of thinking. So as HR, your traditional HR department is more about how do we shuffle people out of the organization without getting sued for wrongful dismissal. HR hasn't always been thinking of the betterment of the people in the organization. And we see that just in the fact that they call people resources as if we can just trade them. We can get rid of 200 people today and hire another 200 people at the beginning of the financial year, and it will be the same. Well, it's not the same. It has massive negative impact. We see people in HR defining KPIs for people that have them competing with each other instead of collaborating. You know, we see this all the time amongst leaders who have got KPIs that conflict. So we wonder then why we have these silos when the very leaders KPIs create the silos. So there is a change in thinking, but that change when we can change the way we think and operate from the perspective of service, then it actually creates a lot of joy. And it does help leaders to get an enormous performance uplift. It does help HR to get enormous engagement uplift, which I guess leaders care about too. But there are enormous outcomes for HR and leaders, but it does mean they need to think a little bit differently. So, yeah. Thank you so much, Terry, for sharing your experience with us today. It was indeed a great session. Everyone has really appreciated the talk that you have given to all that and is sorry if I'm not able to take all the questions, but yeah. Terry will be available on the hangout area for next 20 minutes. You.