Scaling agile

Read along you will

Shane: welcome to the No Nonsense podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Murray: So today, Shane, I wanted to talk about how you help larger teams of 50 plus people to implement an agile approach. How do you scale agile? 

Shane: So my experience is typically starting off with one team and then, after that group has been getting some good success. Everybody wants them to do more. And so the logical way of doing that is to scale. To put more people in, create different groups or a bigger group and see how they go in terms of achieving more. That’s when we hit the scaling problem. What about you? When do you tend to get involved in scaling? 

Murray: it’s really only been over the last five years. I was asked to do an agile transformation at a digital agency, which had already implemented Agile and got very confused and was losing quite a lot of money. I redid the transformation across 90 people and was delivery general manager there. I found it quite easy and very successful. Since then I’ve been doing agile coaching for some very large programs. One that was over a billion dollars for an insurance company and one that was a few hundred million dollars for a Telco. The insurance one was using water scrum fall as advocated by the big consulting companies and the Telco one was using safe. So when I was able to do it myself it was pretty straightforward and I think it worked well, but these other approaches I thought were pretty awful. 

Shane: Okay So my opinion is, we have a group of people, let’s call ’em a pod that have adopted the agile mindset. They’re going on their journey, they’re seeing some success and the organization wants to achieve more by adding more people. So my view is, we should treat it as an experiment. So we’ve got say, pod of five, we should add another pod of five and we should experiment until running two pods together is successful. And then once that’s working, we can then decide what we wanna do next. Do we want to put another two pods in and go to four? How do we want to expand it out like an amoeba and just keep breaking off and growing bigger and bigger. 

Murray: Yeah. I like that approach, Shane,

Shane: Yeah, because we’re testing it and we’re changing the things we do when they don’t work. And as we scale, some of the things that used to work probably won’t work. But what I see is, this idea of we’re doing okay, so why don’t we add 10 squads, and just replicate what squad one’s doing nine times. How about you?

Murray: Yeah. Everybody wants to do agile now, at least in name. So whenever any big project or program is set up, it’s just assumed that it’s gonna be agile. So you have this, billion dollar insurance company program. Everybody just said it had to be agile, obviously, but nobody who said that seemed to know what Agile was. And, they just did water scrum and fall because somehow they thought that’s what Agile was or it was easier to do. The other ones I’ve come into have already been set up and I was coming in to help. So there were already, quite large numbers of people in them. 

Shane: And did they start with a large number of people? Was it a standing start from zero to 200? 

Murray: Yeah, that’s what they tend to do. Even bigger than that, Shane. 

So there’s a number of major banks and telcos that are going through these business agility transformations where you’ve got the big three management consulting firms, McKinsey, Bain, and BCG coming in and saying you’re gonna be able to cut out a lot of people and save a lot of money by doing this agile transformation. It’s worked for Spotify, it’s worked for ING, so it’s gonna work for you and so there’s this huge top down thing happening quite often. 

Shane: Yeah. I hate the word transformation. I think it’s bullshit. Think about how a butterfly happens, it goes into its cocoon. It hides from everybody and works on itself and then eventually it comes out from the cocoon transforms. But it’s completely isolated, it’s a one off event. When we become agile we transition consistently, continuously changing. 

Murray: I agree. 

It’s about continuous improvement and experimentation and tailoring for your situation. That’s a much better way to go. 

I’m really against, big bang transformations. They’re very suitable for consulting companies cuz they can make a lot of money, do a lot of packs. And then leave.

Shane: Yeah, digital transformation is when the business removes all funding from IT and gives it to an external party.

Murray: You can see if you’re the external party that you’d be advocating that.

Shane: Yeah. And then you definitely wanna advocate 500 people from a standing start, because you’ve got a scaling problem on day one that you have to pay to solve. 

Murray: Let’s talk about what people actually do to solve these kind of scaling problems. So I like your approach, which is start small and get one team working and then double it. And then double it again using your experience. I would really strongly recommend that if organizations are prepared to do it. It’s a great way to experiment and see what works and improve. It’s a process of continuous change and improvement on how you are organized. So I like that approach. But what if for various business reasons they wanna do a hundred people. 

Shane: So my answer is don’t. So I don’t believe standing start with a hundred people trying to figure out how they’re gonna work in the future and reinvent all that stuff, will ever have success. 

Murray: But there are many products, Shane, that are much bigger than a five person team. Like Spotify has 5,000 people now. . And there’s bigger companies that have applications or products that actually do require hundreds of people to build them.

Let’s say that you want to build AWS inside your Telco you can’t do that with five people. What I’ve seen, Shane, is that in big organizations you need to use your political capital to get funding and support and generally it’s such an expense to get over that hurdle that you need to do something pretty big. 

Shane: Yeah, I look at companies like Basecamp and I say, actually, do organizations really need to be massive? And I don’t think they do, but le let’s take that off the table. So if we look at organizations that end up having lots of squads lots of groups of people, Then yes, that can work, but they still get there incrementally, they still continuously change how they’re working as they grow into that. So if you say that actually to deliver your vision you are gonna need a hundred teams, then the question should be how do we start with one team and then scale out as fast as possible, but safely? Rather than saying a standing start of 500 people was a good idea, and I suppose that’s my philosophy.

Murray: What would you do though, if you came in to consult on a program that had 10 squads, and squad had, nine or 10 people in them. Let’s say they’re doing water scrum, fall or safe or something like that, and you had to help them. What would you do?

Shane: my approach wouldn’t change, I would spend the beginning observing. seeing what’s working and what’s not. Then I’d encourage their conversations to identify the things that are working and they should keep doing and identify the things that are not and what they’re gonna do to fix that.

What wouldn’t I do? I wouldn’t go and find a framework on the internet and come in and say, that solves the problem. I would go and look at those things and say, do any of the patterns from those frameworks seem to be able to solve our problem? We’ve talked before about the concept of three Amigos. So if one of the problems is the, each of the groups are working in complete isolation, but they have dependencies across each other and it’s the dependencies that are causing the problem. There may be a scrum or maybe a three amigos. I’ve done a little bit of research around things like less and I like some of the patterns and mindset that it seems to be doing. So I would look at those things and say, okay, if we experiment with these as a group, will it solve that particular problem? 

Murray: Yeah. I like that approach as well. I find though that organizations that they’ve been sold a framework. They’ve been sold safe or they’ve been told that they’re doing agile, but really what they’ve been sold is water scrum fall. it’s helpful to understand what these frameworks are so that you can identify them and maybe help them move away from them.

What I like in terms of scaling frameworks is Scrum Nexus. The Nexus is a coordination and integration team. So you might have, six to 10 Scrum teams and you have a team in the middle, which is integration, coordination and planning. And it’s made up of a combination of leaders from each of the Scrum teams and maybe a couple of permanent people. And they run a kind of less type of environment, which is single product manager, single product backlog with all the teams. 

Nexus and Less seem very similar to me. Less is the same thing. It’s single product manager, single product backlog several teams and the teams take items off the product backlog, as required and as makes sense. So It’s all about , relatively autonomous self-managing teams that can work pretty independently off a single product backlog. There’s something else called scrum at scale. It’s all based around Scrum of Scrums and the three amigos, so you’ve got your scrum master, you’ve got your product manager and your technical person 

Shane: Yeah, idea of having somebody who’s experienced in doing the work brings a voice of experience around estimation. So they can go, yeah, that’s all good, but this one looks like it’s massive and this one looks like it’s smaller. So they’re doing some early guessing on the size of the work. It’s an important voice into the conversation. 

Murray: yeah I definitely think you’re right about that, but I would like to bring a fourth voice in, which is the user experience design. I think they get short shrift in a lot of products, and it’s absolutely critical, and they do the same sort of thing as the technical leader, but in a different domain, in the domain of the user experience. 

Shane: I don’t see a lot of ux skills or behaviors in the data world. And in my startup, we’ve got an awesome UX person. So probably have a little bit more experience over the last year or so based on that. And I can see the value. The question would be then, what part of the conversation are they in, what 

Murray: All of the non-technical parts and any of the technical parts they want to be in. That’s why I would say.

Shane: Yeah. So , in the data world, there’s a whole new theme coming out, I think called data mesh. Which unfortunately lots of data technologists think is piece of technology, but it’s not. What it’s describing is effectively an operating model. And so if you look at that and you look at some of the way other organizations have scaled I think you end up with two patterns. You end up with a pattern where each of the groups of squads have complete autonomy and then you are centralizing conversations or pattern slash control where you have to. To help scale to remove some conflict or some mismatches. So I think that’s pattern one, I think the other pattern for scaling is everything’s controlled from the center and then the bits that can be devolved are devolved out to each of the groups of the squads to execute. Which is my view of what safe is saying.

And so , I’m a great fan of autonomy at the edges and, centralized communication, centralized collaborations, centralized planning, centralized patents where it makes sense, where it adds value. And so yeah, that’s why I think when I read things like Less, I naturally like it because it fits more within my mindset.

Murray: Oh, If you think about it, autonomous teams are like loosely coupled services, Shane and we can also think of leadership as a service as well. 

Shane: So if you think about defense force, in the heat of, the battle autonomy is devolved at that time because that’s important. Up until that there’s still a lot of central planning, because that’s important. 

Murray: Yeah, So if you’re in an army you want to use the air power to bomb your enemies , but you don’t want ’em to bomb you. That used to happen a lot. And the solution is to have a integrated command structure that has air, army tanks and infantry all combined together, it’s called Combined Warfare. And the more you can devolve it down to the lower level, the better it works. And it’s the same thing with teams. If you have teams that are able to do everything they need to do, have all the skills and capabilities to deliver value from beginning to end, then they’re gonna be much more effective. Because they have a lot less dependencies. 

So I think actually dependencies is the key thing with scaling Shane, I think that’s worth talking about. How do you deal with dependencies?

Shane: So that’s a good point, if you had a way of breaking the work down into completely isolated pieces of works that had no dependency on another group of people then you probably won’t have a scaling problem. So it’s the fact that actually we end up touching something else that somebody else is touching or we are reliant on them doing a piece because it seems to make sense that we hit the problem.

Murray: So in my experience, when you scale, what happens is that you start to get all of these dependencies on other teams. And as you said, there’s two ways of dealing with it. So let’s say that you have a team that’s building some application to be used by a retail store and it needs to get data from some backend systems. 

So it’s gonna go two ways. And your organization has set up a middleware team and that middleware team has to make a whole lot of changes for you in order for you to do what you are gonna do. But they’re not on your timetable. They don’t have your priorities. They are not actually really interested in what you’re doing at all. 

You could find yourself very quickly blocked by them. And the solution that I would advocate is to get one person from that middleware team and put them in your team and empower them to do the work so they don’t need to go back to their team all the time. 

So, you are removing the dependencies between teams by making the team fully cross-functional. And I would advocate that approach with all of the other dependencies. So if you’re doing marketing and you’re constantly being blocked by legal people, who have a six week cycle for giving an opinion on any communications then get the legal person and put them in your product team.

Shane: I think that’s the key is focus on the edges of your groups and the dependencies they have at those edges on somebody or something else. And that’s what you have to manage in a scaling. 

Murray: Yeah. And this is what DevOps is about. DevOps is not about having an ops team using Kubernetes and calling themselves DevOps and blocking everybody from delivering anything until it goes through them. That’s not DevOps. DevOps is having the dev team be responsible for their own operations. There’s no DevOps team. 

Shane: So make a decision on whether you’re gonna centrally control and push out. Is the model You’re gonna use the mindset. or you’re gonna have autonomy at all the edges and then centralize the communications or collaboration or practices and processes where it makes sense. That’s the first decision. And then the second decision is, are you going to be a factory or are you gonna be product focused? So the example of a factory is almost like that lean one you talked about is you do a piece of the work and then you’re gonna hand that off to another station, you know another group of people and they are dependent on you pushing that to them at the right time. 

And so we focus about that flow through those stations. The idea of just in time. So when’s the latest, I can give it to you about blocking you and how do I manage that to happen? So that’s one way of approaching it. The other approach is that end-to-end skilled team and that boundary starts to become the concept of a product.

Murray: I think the factory model just doesn’t work at all for product or software development but the factory model is what nearly everyone uses because the factory model works well for doing the same thing over and over again at low cost efficiently and effectively. But products, and software development has far too much uncertainty and far too much learning and change required, for the factory model to work. So I’d say just take that out completely and stop doing it . You need to remove dependencies as much possible by having cross-functional teams. And you also need to coordinate between those teams. So there are sometimes capabilities that you only need a bit of, so you can’t really afford from an economic point of view, to have a full-time highly skilled person in your team. Not every team needs a data scientist, but your product might need a data scientist. So there is a need for some coordinating and integrating group, I think. 

Shane: So If we say that every squad is autonomous and that the ability to use machine learning as part of whatever they’re building is important, then they should have a data scientist.

Murray: In every team? 

Shane: Yeah, because as soon as we share, we introduce a dependency. And so what we’re trying to say is end to end full autonomy is our goal, and then we manage everything else as an exception. 

Murray: I would say, in that situation, then every team needs to learn how to do data science, and if they don’t have the skills now, then we are going to find somebody in the team who’s interested in doing it, and we are going to skill them up. And your lead technical leader, whoever that is, is going to, mentor and coach, all those people.

Shane: Yeah I think that’s a good distinction. We talk about skills, not roles. 

Murray: Yeah, and that person doesn’t have to necessarily be called a data scientist, although they might end up specializing in it. Let’s say that you have eight or 10 teams that are cross-functional. There’s still a place for the three Amigos or the Four Amigos. There’s still a place for, a technical leader or an architect or something like that. Somewhere, you need to be able to work on the bigger picture. And you also need to provide coaching and training and support to individuals in teams. 

Shane: Yeah. There are times where we want each of the autonomous groups to communicate with each other because that communication has value, and there’s ways of doing that. I’ve seen ones where each group will publish a blog every week as like a mini demo, of what they worked on as a way of communicating. Obviously demo days is another way of communicating if people are interested, so I think that’s important. As we get more and more, we probably need to communicate across those autonomous groups. 

I think the second one is collaboration, where there is actually gonna be some form of dependency across the autonomous groups and they need to collaborate. How are we gonna do that? So that can be Scrum and scrums or three Amigos. There’s a bunch of patterns out there that you could experiment with. There is then control. There are times where we want to control something across all those autonomous groups. We want ’em to be non-autonomous for that. And that’s typically where the architect has to come in and the old way of working, which is these are the rules and you can’t break them. 

Murray: I agree with you that there needs to be some control. If I look at it from the product manager’s point of view or from the business point of view, typically you’ve got a certain amount of time and money that you need to achieve some sort of outcome. Otherwise it’s just not worth doing. 

And so you need to make sure that everybody’s aligned. There’s no, there, there would be a big problem. There’s a big problem with autonomous teams if they’re going in different directions and they’re not aligned. So how do we align them? 

And the way I think, work best is something called objectives and key results. Rather than setting a detailed scope, what you do is you define your scope in terms of your objectives and how you’re gonna measure success. And then you. Talk to the teams and you agree. How is each team gonna contribute to achieve this objective? And maybe they’ll do it by achieving sub objectives.

So Team one will achieve this objective that contributes to the overall. And team two will be a second objective and team three will be a third objective. And together they’ll achieve the big objectives and each one will have their own sub objective measures. So you end up getting like a hierarchy of objectives leading to your main goal. I think that’s a good way of doing it. 

Shane: Yeah. I like the objective part. I’m not such a great fan of the key result part. 

Murray: It’s about, measuring whether you’re achieving your objective. 

Shane: And so I don’t agree with that. I think it’s about communicating shared goal combined objectives. When we talk about backlog grooming, the massive amount of value I see outta that is not the estimation they come up with. It’s the conversation they have together before they start the work.

And OKRs, I see the conversations we have where people are setting objectives for each group of people is where the real value is. We’re having a conversation about the organization’s objectives and then the autonomous group’s objectives. And as humans, we will try and naturally align them.

Murray: Shane, if you had a hundred people working on a product, and that product had a clear architecture where it had different components that do different things. Maybe there’s a component that gets a lot of data from backend systems, and then there’s a component that, deals with retail and there’s a component that deals your customer service people and so on. So you can break up your product solution into an architecture. 

What, do you align the teams with the architecture or would you try and have everybody do everything? 

Shane: So my current theory is I would break it up where I could reduce the dependencies as much as possible. So for our product I think we would experiment with what I believe Spotify did to reduce the dependencies. So search is a product within Spotify and there is a team that do search. There is the one that does the cover art. And so they only worry where there’s a dependency across those. And that’s how I do it for a digital product like ours. But haven’t done it yet, so can’t tell if it’s gonna work or not.

Murray: Yeah, I like that approach too. 

And I think it’s also probably worth experimenting with different team structure models.

Shane: So let’s take it outside technology. Let’s put it into a bank or an insurance company, because then what we’re saying is actually we want vertical product groups; a product which is savings and a product which is loans. And in theory with autonomy, they can run completely independent systems and only share data where there needs to be a dependencies, which would be customer right. 

Murray: I definitely think a product view of the world and product organization structure is much better. But there is perhaps a need for a matrix structure here because if you are operating a bank, there’s gonna be a time when you’re building things and there’s gonna be a time when they’re built and you just want to do them as efficiently as possible. And so when you are trying to do something as efficiently as possible, I think that’s when the factory model does work. If you’re trying to do the same thing over and over again. So I think there is a case for some shared services across product teams, but I would like the product teams to be the ones who decide whether those shared services are valuable and working for them or not. And I would like those shared services to be embedded as much as possible. 

Shane: What Spotify talked about from memory was they allowed every squad to be completely autonomous right down to the technology. One was using Jira, one was using Trello, one was using something else. But what they found was, over time as new squads stood up, they’d go we need a place to store our board what’s everybody else using? And then they’d go we don’t care enough to go get our own. We’ll just use what squad B’s doing. And then over time they became critical mass. So enough of the squads said actually we’re spending too much time internally each maintaining Jira. Let’s have a squad that serves us by maintaining Jira for us. We’re their customer. And they’re providing us a product.

Murray: This is the idea of internal products for internal customers. And I think that makes a lot of sense. Why on earth is every product team building their own crm? Why not have a single CRM so you can have a single customer view? And in order to do that, you would set up a CRM product team, and their customers are internal to the organization. 

Shane: So I think that sounds like a control approach, remember when I said these two approaches? So that is, we think it’s more efficient therefore we are gonna mandate it. 

Murray: I wasn’t meaning it quite that way. I was thinking about your scenario. People start to build their own CRMs and somebody’s done quite a good one. And so the others say, okay let’s use that. I was working for a large telecommunications company that had decided to build AWS type services. They had eight different initiatives to do this each, which was given a large amount of money. And it was mainly because of empires within the organization, it become an important strategic initiative. Every, executive director wanted to have one, and so they poured money into eight of them. And then after a while it went down to four and then two, and then one, which is sensible, but it took them, five years and maybe a billion dollars before they got it down to one.

Shane: But do you think that if they started with 500 people using safe all supposedly working together, they would’ve spent less time and less money to achieve the same outcome? 

Murray: Not if they were using safe, Shane, because safe is pretty awful in practice from a scaling point of view. 

Shane: So while that sounds inefficient I’m not convinced it is. I think there’s also an anti pattern to it. I remember when I was working for some large American vendors in pre-sales systems engineer or sales engineer or whatever it’s called now.

There was a kind of behavior that I believe came outta General Electric. And it was this kind of hunger game. So the way it worked was every salesperson had a quota. And at the end of the year, you had measured against your quota. But unfortunately, even if you made your quota and you were in the bottom 20% of salespeople across the organization, you got fired. Even if you were successful because the organization was based on that hunger, that win at all costs bring in new, blood. So I think with your Telco example, There’s always a risk that, eight groups fighting each other to win at all costs is a bad behavior. So I think, we’ve gotta be a little bit careful about that, but I’m not convinced that it was the least efficient way of achieving their outcome.

Murray: The most efficient way it would’ve been to start 15 years ago or 20 years ago when AWS was starting, and to start with a small team and then scale it up in an evolutionary and experimental way. 

Shane: I remember when my previous company, we started using aws and I remember the AWS console with the services, as you logged on and tick the box for the services you want to use. There weren’t that many boxes and now I hop onto AWS and I’m like, oh my god there are so many things and that didn’t happen overnight, it wasn’t, the organization bringing on 50,000 people on day one to build out all these things. It was done incrementally and continuously. 

Murray: What happened was the organization didn’t do anything for a long time, even though lots of people were complaining about it and told them they should do it internally. They didn’t do anything for a long time until it became such a serious threat that they had to do something. So they had to play catch up, which is Borders and Amazon. You ignore the problem for a long time and you’ve gotta do a big catch up. So you do need to spend a lot of money quickly.

Shane: Did they catch up? Are they winning? 

Murray: I think that , they are actually successful in building the service for internal users and, it seems quite strong and quite robust and quite good from my point of view. Whether they’ll be able to commercialize it and make money out of it. I’m not sure. 

Shane: So maybe the answer then is if you’ve had an action for 15 years and your business is in massive trouble you have no choice but to try and scale from zero to a thousand people on day one to fix your lack of foresight, leadership in an action. But actually it’s not a good idea. The best idea is start small scale where it makes sense, and as you learn and become an efficient organization at scale because you’ve grown to be good at it, 

Murray: Yeah, I think that’s definitely a much better approach. Shane. I think we agree there. There’s some research on this. So Standish group has this chaos report, which they’ve been doing for 20 years, which is on all sorts of success factors with projects, waterfall versus agile and a whole lot of other things. And , they have shown that small projects are much more successful than big projects, no matter what methodology. The Project Management Institute also has found the same thing. And then Agile projects are more successful than Waterfall projects. So if you have a small Agile project, it’s many more times more likely to be successful than a big waterfall project. Big waterfall projects have only two or 3% success rate with something like 20 or 30% of them or more failing, and the rest are seriously challenged. 

Shane: I’m gonna make a prediction. in two or three years, we’re gonna be reading the white papers that talk about the failure of transformations to achieve the organization’s goals. And for me, that’s a scaling problem. 

Murray: I, agree with you. 

And the reason is, that it’s actually being done in a very non-agile way. They’re using a waterfall approach to change the organization into an agile one. So you get the big consultancies in. They lock themselves away in secret rooms with executives. They come up with a new organizational structure that has less people in it, cuz you are using agile. And without any consultation, you just say, okay, this is it. Change is happening and we’re gonna start by training people and here’s all these new jobs and you can apply for new job. But it’s very centralized, very top down, very upfront. What we need is an agile change management process, which would be iterative, incremental, exploratory. And it would be highly collaborative, open and honest. Not like this big bang, let’s gut the organization and restructure it and make everybody apply for their jobs again. 

Shane: So Agile change management really is just how do we start agile small and scale out to a large organization in a good way. I can’t wanna say in a safe way, but I can’t use that word anymore. So what are we call it? 

Murray: I would just call it agile change management as opposed to Big bang change management. 

Shane: Yeah I hate the word change management. I think managing change is really important. I think all the baggage that comes with change management annoys me and I call bullshit on it as much as I do around the word project. 

Murray: It’s not collaborative normally at all. So that’s a problem from an agile point of view. But we could talk about agile leadership then rather than, agile change management cuz it’s continuous, not one off.

Shane: Yeah. And at some stage I’d love to have the conversation around business agility. Being servant leaders versus command and control and all the baggages that comes with a command and control organization, like annual budgets. But we’re running outta time. Final thoughts on how to scale. 

Murray: I think this is interesting. We both really agreed. I think that you should start small with one team and then expand out from there in a kind of evolutionary pattern like cellular division. Because you don’t know what the scaling, solution is gonna be for your organization and I think every organization is different. I think you should try Less and Nexus and Scrum at Scale, and there’s plenty of tools in the safe framework, which are good, which you could try. But it’s really important to experiment with them and try them in your situation. Small teams, try them and then, if you are gonna do something big, make that big thing made up of a bunch of small teams working cooperatively together and unified through, an O K R type of approach. That’s how I’d sum it up. 

Shane: Yeah. I think the only way of success is starting small and getting bigger. If you are time bound, if you’ve waited 15 years for your competitor to stick you and you’re in trouble. Then actually start small bit, focus on how fast you can scale. Focus on those dependencies and how you’re gonna manage them. When new problems turn up as you double, triple, quadruple, or do that exponential growth, how are you gonna fix problems quickly. But definitely go look at all those other patterns out of nexus less and those ideas.

Murray: They, have lots of good patterns , where people have solved the problem before. And you can try them out. But definitely don’t do a massive big bang, business agility, transformation from the top down. And don’t do water scrum fall because your big four consulting partner said that’s agile. Cause they don’t know what they’re talking about. 

Shane: Yeah, I come back to the idea of transforming a way an organization works. Agile transformation is not the goal. Achieving our organization goals in a more effective way by being agile is what we try to do, the project itself is not the outcome. It’s the thing that assists us getting the outcome. 

Murray: We need to focus on the business outcome we want and if we are doing it in an evolutionary way, we can measure and see whether the changes we are making are contributing to the outcome, and if they’re not, we can try different things. But if you do like this billion dollar, three year transformation program it’s only at the very end that the results are really supposed to emerge. And only then can you measure it and only then will you find out that it didn’t do anything, which is what’s usually the case.

Shane: Imagine if we had this idea of transformation ops where the people doing the transformation actually stayed after it and wore the cost and consequences of what they did the developers actually running their own stuff. Wow. Imagine the transformation ops. That’s a new thing.

Murray: I recommended having change people who focus on the business side of change embedded in teams or embedded in the scrum or scrums if you can’t really afford to have one in each team rather than operate independently. 

Shane: So let’s go back to that. So my view change management skills is important in every team. Unfortunately we treated as a role, not a set of skills. And therefore, if our teams don’t have those skills, we need some form of coach, to help up, upgrade their skills as a team to manage that change for the organization. Skills, not roles. 

Murray: Are you really going to ask an application development team to contribute to designing the new organizational structure? That would be empowering for them. But they wouldn’t have any idea what they were doing to start with.

Shane: I remember reading a manifesto, about valve. They talk about the whole idea of holocracy and no organizational structure. So why does the organization structure need to be centrally controlled? Is the question

Murray: Oh, that’s a big question. I think it’s so that people can build their empire, Shane.

Shane: All right. I think that’s done. Otherwise we’ll be here for a few more hours. So good to catch up. We’ll catch you next