Structuring Your Business For Agility

Almost all companies need to get better, faster, cheaper and happier! But how? Business Agility is an option but changing culture is not easy and having teams learn and do all the Agile practices is not enough.

Conway’s law, which states that at the root of all complex systems and processes lie complex structure, is so true and this talk is all about what needs to change in traditional organisational structures in order to drive business agility and deliver great outcomes.

The talk is based on hands-on experience over the last 12 years in structurally transforming organisations to an Agile way of working and will cover how to deal with issues of scale, org design and resistance to change.

This presentation will walk through the why what and how of the entire approach, sharing the good and gory experiences, the successes and the pitfalls.

Transcript

So have a look at this picture, and if you look at this, you can see this is 2016, so 2006 to 2016, 96 percent drop by the top companies in retail. Now, Woolies isn't up here. I don't know the stats there, but if you look at Amazon, they've gone up almost 2000 percent in that time. So everybody has digital, everybody has websites. Everybody knows about customer experience. So what is the real difference between Company A and Company B, between the top company and the bottom company?

They're all playing catch up now. But why? So the main thing that you see is they say, "well, it's the people". Now they're realizing that the core differentiator is the culture, is the way of working. But what really does that mean? It's such an easy word to say, it's the culture, but what is it that has made Amazon so big and continue growing every single day? It's sustainable growth. It's not just a once off. And there's two things. The structure and the style. That's the leadership style, the culture, the softer parts. I'm not going to talk about that today in my twenty minutes. I'm going to focus on the structure side. I'm going to break it down into two bits, the structure of the work and the structure of the organization. So let's go down with just one slide on what is business agility, just to just to lay the playing field. 

It's very important that when I when I started the first transformation program with Jeff Smith in Suncorp in 2007, we did Agile. And of course, we had a separate program called Lean. It was one of the biggest mistakes Suncorp ever made at that point because they never, ever came together. Three years, four years later, we made one head of the two transformations even that did not work. They stayed as two separate transformations. So what's happening today, and the reason we're all sitting here together, is that Business Agility has provided the umbrella to pull all these practices and principles together. 

The other thing that I would like to say is that it's no longer I.T. anymore. In the last four years I've been working with the aerospace industry, with banks, with IBM, a large part of my work working at around transformations of two hundred thousand to three hundred thousand people, groups of 20 thousand at a time, and of course, I've had the fortune of working with the best bank in the world as well in Singapore. So if you look at that as a definition, what you see underneath that is a set of values. This is why it works so well, because right at the foundation, is a set of values: trust, respect, openness, transparency. You can name a few of those human values you want. Principles on top of that, you've got focus on the customer. You've got iteration, continuous learning, empowered teams, etc., simple values, and a whole buffet of practices that you can choose from, whether it's a Design Thinking, customer journeys, Agile stand-ups, Scrum, SAFe® practices, whatever. 

Pick what suits you. And it's jumped the fence; now I'm doing most of my work with marketing, sales, finance organizations and not I.T. teams at all. So it's really become something that works across. So if you look at this, when we started in IBM about four years ago, it was, "Yep, we got to get the values in place. We got to get the practices. We got to start changing culture. Let's go for it." 

We started. So what did we do? We had training. Great. We had some coaches in traditional stuff. And you start pushing the practices. You've got the stand-ups, the retrospectives, empathy maps, the usual stuff. Let's do it. Let's do it. Let's get the culture changed and...nothing changed. There was a little bit, of course we got benefits, but actually I saw regression in time to market. We were spending more time with stand-ups and retrospectives and rituals and rituals and software delivery. 

Other delivery was taking ages. Now, it could have been time. We said, "Let's go and talk to the people. Let's just go and find out." So I went on a mission. I happened to tour, I don't know, fortunately a lovely 20 countries talking to them all over the world from Japan to Colombia, and we found this: the maze and the madness. And this is what sits right under it. And it shocked us. And I'm going to talk to you about it in a moment. 

So. Traditional organizations started off, you know, right from the time of the military warlords. Functional, groups, sets. And then it went on. You got HR, finance department, one department, two department, three. Around the eighties, we started going global. You had sector one, sector two, geographies, et cetera. And then around the 90s, something strange happened. We got this, this method of what is called KPI Management. So now if something was not working, you know, your strategy was not right.  Let's have a Head of Strategy. And then they had a Head of Strategy and then a Head of Variation. And now we've got a problem with I've got a team that I worked with that had a problem with gross margin. So they appointed a V.P. of Gross Margin. V.P. of Gross Margin, V.P. of Innovation, V.P. of this, V.P. of that, and it goes on and on. And in the center is Bob. Bob is still the single person doing the work. That has not changed. And we've built this inverted pyramid on top of the doers that is really removing accountability, all sense of accountability and responsibility. You can't even say who's accountable. And these are good people. These are great people, great leaders, but very easy to say, "Oh, no, the leaders maybe are not the right leaders." No, they're all good leaders. They've been set up to fail. And then we came across the madness. 

The madness is how work flows through the maze. So what you've got there is you've got people coming in with the process. Let's let's make the process map so they'll do process reengineering. We've all been through that. You put it in maps. It's just that that is not how things work. You've got another way that work happens in the organization. And if you really know how to shout and who to contact, you've got your network.

There's a third little way that things happen. That's how work really gets done, and this is how things work. And then what do we do? Because it is the maze. Then we automate the whole lot. So now we go and buy SAP. We buy whatever it is that suits our flavor. And now it's RPA, that's the latest buzz word, and we digitize the whole mess. Now imagine transforming that. Try doing that. It's all set in concrete, very easy and structured when you're setting it up, and then it goes hard and that's it. You're stuck. You can't move anything. Of course, we then need an army of our project managers, maze runners to run this maze.

I worked with one bank in Australia and when we started the journey, they were at one hundred and four developers in one area. Take a guess. It was a small area. Take a guess on the number of PM's - project managers. Well you're almost right. It was ninety seven. Maze runners through this, and I feel so sorry for them because they're fantastic. They've got no accountability, no sorry, ALL the accountability, no responsibility to change things, deliver on time. It's a thankless job that they can't achieve. So it's very, very difficult. And underlying all this, each one has their metrics, their dashboards, their KPIs, the governance. It's all there hanging around, and there's so much you don't know actually what's happening. 

And it's in this maze that sometimes we find ourselves struggling. You feel that you're the only one there pulling along. You're the only one carrying the ship. And it's the structure. And we come back to Conway's principle here, which said that your systems and your processes will only be as simple as your structure. You've got complex structures, you can forget about having simple processes or trying to simplify your processes, and that's what we need to address. 

So. We have to look at that dark dimension behind us: the maze and the madness. You've got to address that. Without touching that, all Agility efforts in pockets, they'll work fine. The minute you try to scale across the organization - this is not just a pilot or a lab or something else - and really make change stick and sustainable, you start having a problem.

Now, we did not do too much of a change in Suncorp in terms of org design. Not too much. We did it in pockets in the I.T. organization, but not on the business side. And you can see where this thing can regress very, very easily. So let's look at the org structure. What does it take to actually structure for Agility? So if you look at a traditional - I've used an IT structure here, but it doesn't matter. You can use any structure, whether you're in marketing or sales. 

It's very functional. It's all based on the competence you've got: the BAs, the devs, the testers. You may have graphic designers, you may have content management people, et cetera, et cetera, the grouped. And sometimes, for example, in this picture you see the PMs are on a completely other organization altogether. And the projects go across. The projects are running right across this, and a person on multiple projects.

The biggest challenge I found in most of the transformations is the start up phase. Can you give me, I ask one question: give me the list of people that you have - that, yeah that in itself starts the problem - and then tell me what they're working on. 

Oh, oh, that's about six to eight weeks. We don't - how are you managing it? If you can't give that information, like that, on the spot, and have it up on the wall immediately? You have the numbers, but they're not including contractors. Oh, by the way, and there's MS also, they're not included there. There's all these ifs and buts. So very, very complex. But physically it looks very simple. And we've seen this picture and everybody goes, oh yes, it's very structured and everything. And then there's this happening at the back, you know, people working with different people. You have your lines of communication. So what do you change? What I found through experience - and this is really blood, sweat and tears and a hundred mistakes - that works, is a very simple model. Now, I'm not calling it the Spotify model. Please don't assume, because I've used the name 'squad' and 'tribe' that it's the Spotify model. No, it's not. 

It's small, cross-functional teams. Call them whatever you want. That means they've got multiple skills to deliver a piece of work. What is small? You can go between five and 10 people. So seven plus or minus two - it's up to you. And you look at the shared resources, the enablers. There are always people that you can't have one or two in the squad itself. So they're up there at the tribe level, they're shared across.

Call, call this whatever you want. It amazes me. You know, I've worked with some very senior leaders and they have, you know, at CEO level and they'd go and look at companies and they'll say, "I like that, but I'm not going to call it a squad. We are not calling it." Why? Well, because Spotify call it a squad. OK, so call it anything you want. It does not matter. Don't get hung up on the terminology. Small cross-functional teams, and share the resources that are, that are based up there.

Now. How do you design this? This is key. So the top three questions you have to ask, the number one question is who is the customer? So let's take a marketing team. Who's the customer? Well, it's the, it's Division A that I'm doing the marketing for. All right. You're doing the - so what is the service you provide? Marketing is that broad, as you heard from this morning's discussion.

What is the service that you provide? I provide this and this. There should be maybe two, three, five services. Defining a service is very hard. I got lists of 140 from some teams. They're just activities. They are not services. You do activities to deliver a service. Once you define the service, you ask yourself, what are the skills needed to deliver that? This is not roles, this is skills. And that's also a mindshift change because people are not used to talking about skills, they're used to talking about roles, and a person can play multiple, can have multiple skills. 

And the last question you ask is, what is the minimum size of the team to deliver that service. And this was substantiated by the discussion I had just last week in Singapore with the Amazon, the head of Amazon Global H.R. that talked about this. They only ask this one single question, 'what is the smallest size of team that can deliver a service?' Now, if the volume of demand is much more, you can have multiple small teams. It doesn't mean you can't scale. 

So that's very important that you ask these questions, and that, of course, you can read that they are dedicated, stable, cross-functional and, yes, colocated. Now we'll talk later about if you want to use India, they should be colocated in India or China or wherever you have distributed centers, colocate them. You can have the product owners here. Right? 

Now, you have chapters and guilds that go across for learning and competency. So what about our managers? For our managers, you put them at the top, you've got Head of A, Head of B, and at the tribe level. But what's happened, and I'm hearing this from top level consulting companies today that have gone with the advice of putting a whole list of managers, which is taking the functional organization, turning it on its side and having the same organization across. So now you've actually increased the number of managers you've got, when originally we are finding a lower number of managers. 

You've got too many managers as it is. So this does not work. I've tried it, I've led it, because for every little problem, and they say, "No, they're just H.R. Managers." So let's suppose there's a person problem in one of the teams. A person problem involves multiple people, that's supposing there's a dependency problem that people don't agree on. Now, six managers are involved in that one meeting - more than the size of the team. 

They all have to be emailed, they all have to be combined, contributed. It just goes on for months, yeah? So don't have that side level. And I came up with this one measure called Organizational BMI or Bureaucracy Mass Index. It's a very, very simple calculation. You just take the ratio of the enablers to the doers, yeah? Enablers are people who are needed to enable the work, the doers are the ones who actually do the work. Manager? Enabler. Project manager? Enabler. Myself, consultant? Enabler. Doers are the ones actually doing it. And if you've got, 10 percent is what I've come up to, I have worked with about eight or nine teams of twenty thousand each, between 20 and ten thousand each, and transforming them. And this number works at the scale of 200 right up to ten, fifteen, twenty thousand. So you're looking at 10 percent. So what would it be in most organizations? I've worked in organizations country - that number? What did it say, two minutes? Ten minutes. Zero?! Wow. OK. So I'm going to zip through that.

So, the other key message I'd like to leave with you is 'bottom up'. That's a doorbell, by the way. Beautiful one, isn't it? So it's bottom up. You have to design the organization bottom up and not like we traditionally doing, say we have seventeen managers, therefore we need to do this. So I'm going to skip that one and that one and leave you with one or two slides on the structure. 

So, if you look at work: do the right work, doing the work right. The top bit is the responsibility of the leaders. You do not need a PMO for it. You need assistance. Yeah? The Amazons, the Googles, Spotify do not use SAFe® models. Their leaders are responsible of doing, for doing the right work. Single, pulled from a single pipeline. Get the work done. Simple priorities. And what we're looking at is if you find that you are oooff! washed over with work, you've got too much work. 

Prioritization is our problem. Your problem is strategy, not prioritization. Yeah? Prioritization is the result of unclear strategy. So I would recommend one book, if there is one book you read, it's this one which is Measure What Matters by John Doerr, which talks about OKRs and cascading strategy, and how you take the strategy from the level above the objectives and key results and bring down to the level below, and the objectives of the level below are the key results of the level above. 

This is the golden slide for prioritizing and cascading strategy, and we have to learn to stop and start. So with that, we're almost at the end. I'll leave the rest for questions. I'm going to skip all this to the end and, I think I'm stopping right there. Thank you very much. There's just too much! Thank you. Thank you.

Phil Abernathy

Director And Executive Agile Coach @ Purple Candor

With 31 years of business and IT experience and over 18 years of consulting and management experience with blue chip companies in Australia, Europe and the USA, Phil is a proven entrepreneur, executive leadership coach and management consultant.

Phil is considered one of the leading experts in Agile and Lean in Australia and NZ and has been instrumental in setting up the Agile Academy. He is the founder of Purple Candor and his 12 years of Agile experience firmly establishes him as an executive coach and trainer in the Agile/Lean arena, specialising in helping organizations transform to a more productive way of working.

His 14 year IT career with Shell, culminating as CIO, combined with the experience thereafter of building and running his own Professional Services company for 18 years gives Phil the unique combination of in-depth IT knowledge, business acumen (financial services, energy, telecom and new media sectors) and dynamic leadership.