Five Phrases That Shout Your Agile Isn't Scaling

Tony Grout at UXDX Europe. Video: https://youtu.be/aoGi8DP8eeA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The agile manifesto never talked about scaling

[00:00:03] Hello, good afternoon. It's 17 years ago, 17 people got in a room in Utah and argued and debated about the future of software. They decided they'd had enough of the fact that we just couldn't do anything useful together to make anything interesting happen without the business being unhappy, without customers being unhappy and without engineers being unhappy. So those 17 people created something we now call the agile manifesto.

[00:00:52] Everything's changed since that day, but one thing that hasn't changed is the agile manifesto did not talk about scaling. Those people had no idea that seven people were going to turn into 70 people, that were going to turn into 700 people, 7,000. And we go on trying to use the same things those 17 people had decided in a room in Snowbird were going to be the way forward for software and for the way we build things today.

[00:01:39] So with that, how many of you are in teams of less than 10? Okay, quite a few. How many of you have more than one team in your organization that you have to work with? Most of you. Then you are already scaling. Just to be clear, when I talk about scaling I don't mean scaling to the thousands, and trust me, I have worked in some interesting places. As soon as you go beyond one team you have some scaling challenges that the agile manifesto really wasn't designed to help you try and work through.

[00:02:14] I often liken it, when I think about agile at scale and when I've owned this problem, as it's like being on a battlefield in the 1900s, and the battlefield is filled with fog and you have no idea where the enemy is, where your friends are, and what you should be focusing on at any one time.

[00:02:44] So all of you are working in these one or these more than one team situations, you as team members and those of your managers. Anybody, you have managed people here, you can be honest, we won't throw you out, we've accepted you as managers in the agile world. One of the things we have been left with is we have to just work it out.

[00:03:07] So what does that mean? Well, that means we're now starting to see, and we'll go through a little bit more as we go through the journey together, things like the Scaled Agile Framework come out, LeSS, Nexus, many other agile frameworks to talk about how to scale, none of which have yet been proven. So we're having to work those things out.

[00:03:37] And as I think about the journey I've been on, one of the things I think we can focus on to help, everything for me when I think about scaling, is about tracking the flow of work through the organization, and the flow of value being the most important thing. Now, many of you here may be struggling with what the word value actually means, or you may think you know what you think value means, and everybody else thinks they know what value means. So one of the first challenges we all have is, how do we define value?

[00:04:06] I'm not going to dig into that today. Anybody wants to talk to me about the incredibly interesting journeys I've been on, I'm going to be around for the rest of the day. I've seen it done in many different ways, some good, some bad. But one of the things I'm thoughtful about is we have to zoom out as we think about how we work across those different teams, and we think about how work flows through those teams. We have to think about zooming out and thinking about the organization as a whole.

[00:04:36] So I like it, we have to build surfers, not oil tanker captains. You have to be able to build managers and team members who are able to pop up, look around and surf across the system and work out, are we going quicker or not, rather than oil tanker captains who just try and point the big tanker in a different direction. I think that's agility.

[00:05:03] And we have lots of ways to help. We're smart, we understand, a lot of us have grown up with some form of agility. We understand the concept of experimentation and we understand that you need to fail fast. We understand about many things that will help us. One of the things I'm thoughtful about though is there are many sort of warning signs I picked up on my travels that mean that you need to know when to apply some of those things, some of that thinking that you think works at small scale, and some of those things work at bigger scale. And I want to share that with you as we go through this journey.

Chapter one: my team's doing great

[00:05:37] So, chapter one. My team's doing great. What else? So, anybody know this? Any locals know this is the Kerry Gaelic football team, who are allegedly, I learned a lot about Gaelic football by researching this slide, probably might not use that very often again, however, they are incredibly successful in Gaelic football. They are where everybody wants to be, and every manager and every team wants to be the person in this team. I don't want to be in another team, you want to be in this team. This is the most successful team.

[00:06:33] Teams and managers who want to be in the most successful team typically optimize to make sure that everybody's really efficient. And that leads you to one of my favorite challenges when you think about scaling up to more than one team and everybody trying to be efficient. Managers focus on efficiency over effectiveness. At that point they locally optimize their own team. My team is awesome.

[00:07:02] The problem is, when you try and keep every team awesome and everybody busy, you can't help but have managers who just can't help but want to fill this spot. They want to put one more car on the motorway. Anybody been on a motorway that's had every space filled? Anybody? Yes, it's got a traffic jam and it doesn't go very fast.

[00:07:30] But as managers, one of the things I often think about, and I've written a blog post that was on this, it's one of the most read blog posts I've written, I'm not very good, not that many, but it's one of the most interesting for me, is about this concept of the manager rater. Now, the manager rater is a special device. Any of you, anybody here not managers? Okay, you have yet to see this device. Many managers won't remember seeing this device. But when you get your manager upgrade, ha ha, that's not an upgrade.

[00:08:05] What they do is they simply take you, you lose about two minutes of your life as they put you through this machine, and from being somebody who is a UX person or a developer or an engineer of some description, you suddenly forget everything you've ever known about that, and now you understand spreadsheets and Gantt charts. And you look at your team and go, but I don't understand why we're not very efficient. Well, can't we just put one more person on this piece of work and it will be twice as fast? And they forget everything they've ever known.

One team going faster makes everybody else slower

[00:08:47] So the challenge with that is, sometimes one team going faster causes everybody else to go slower. Let me tell you a story about where I've seen this. I worked in one organization where the UI people had to have everything pixel perfect. We can't ship this unless every pixel is lined up perfectly. So the engineers were sitting there waiting for those things to turn up.

[00:09:22] What do engineers do while they're waiting? They don't just sit there idly, they create more things we never asked for, because that's what developers do. So we had the engineers going, while the designers were sort of polishing the nosecone of the pixel, and nobody was shipping anything, but everybody said they were doing awesome things. Yes, we're making the UI pixel perfect so that the users will get the best experience ever on the planet. Engineers going, wow, while they're doing that we'll just make the codec one millisecond quicker. And hence we ship nothing.

[00:10:04] So what can you do about that? Well, the first thing is, you want to do something really simple. Anybody heard of the Theory of Constraints? One or two, right. This is your best friend. There are very few things in life that are incredibly simple but really effective, and I love things where they're so simple somebody can't say, I didn't understand. This is one of those things.

[00:10:36] Eli Goldratt came up with this. If you love novels, there's a book called The Goal, you can read The Goal. It's a novel written about the Theory of Constraints. But this says, what you do is you have to look through your system, step up, zoom out, and you look and see, where is the work clogged up? One of the ways you can see that is, anybody use a Kanban board? They're not just for your managers, they're not just pretty stickies to make sure 3M keep in business. What you'll see is there are some columns in there where they're growing. And one of those columns that we saw was the UI team. All the stickies were stuck with the UI team and we're going, well, there's clearly a bottleneck here.

[00:11:26] So then when you see a bottleneck, this is what you do with the bottleneck. First of all, you identify it, then you exploit it. Sounds worse than it is. So what you do is you go, there's a bottleneck here, the UI team, how do we make sure the UI team are no longer a bottleneck? One of the things is, let's not have them all go on holiday at the same time, or anywhere when it's on the critical path. So you do simple things.

[00:11:51] You can also, sorry, you can then subordinate, which is what you then do is you make everybody else slower. Not as bad as it sounds, but it actually makes sense. There's no point making everybody else go quicker if all you're doing is putting more stickies in the not done column. Sometimes it's better just to, radical, send them home. And then the other thing you can do is elevate, so you then start investing in, do we get more of those UX people to help? And finally, whenever you've fixed it the first time, all you've done, by the way, shock horror, is you've just moved the bottleneck somewhere else, and then you start again. So it's a bit like whack-a-mole, but you just keep moving and eventually it gets better.

[00:12:37] So how do we fix this? Well, what we did is we simply said to the UX team, okay, first of all, please don't take holidays right now, because we need to ship some stuff, so can you just work around this so that we can get you working as quickly as we can? The next thing is, we said to the engineers, the developers, why don't you write some tools so that when the pixel-perfect things come in, if they're not quite pixel perfect they can edit them in the product and then ship the product? Your engineers, rather than start writing more things that no one wants, build something that the UX team can use to make their lives easier.

[00:13:20] That's subordinating to the constraint. So not only did we slow the engineers down, we got them to build a tool to help the UX people do their job better. So one of the things you can start to do is you start to stop thinking about a team being successful and you have to think about teams over team. That may mean that some teams will feel like they're doing worse, but that's where you, if there are any managers in here, your job is to make them realize that it's about getting value flowing out of the door as quickly as possible, so your users and your stakeholders are happy.

Harmonize the edges: lessons from the space station

[00:13:53] You can't fail in space. There is no reboot. There's no, could you restart the computer? You're dead. So one of the things we started to look at is, we used some of the concepts that they used on the International Space Station. One of the things that they did when they started to build the International Space Station is they had all the components built in different countries. I'm going to say that again: all the components were built in different countries. We think it's hard to put software together.

[00:14:37] What they found was that they had to start thinking about the interfaces. They became incredibly important, so important that they actually had interface managers on each side. They created a role of interface manager on both sides, and those people flew to each other's locations at the start of the project so they could get a shared syntax and vocabulary.

[00:15:04] Because even though you want agile teams to all be able to do things in their own agile way, they want to optimize the way they work, wherever those teams need to work together you need a common vocabulary and language. I don't care whether a team wants to use jelly tots for estimating, t-shirt sizes, colored wigs, doesn't matter. But where we need to start thinking about the capacity of the whole organization to get a feature shipped, then I need some way of commonly talking about capacity, for example.

[00:15:41] So in Skype we used scrum team weeks. Most of the teams were using scrum and we just said, let's just use scrum team weeks. In your sprints you use jelly tots, you use story points, we don't care about any of that, because for capacity planning we just need to understand, for a quarter, how much capacity do we have and how much does team A need from team B to get a job done? And they just need to know team weeks, that's all we care about. And by the way, integers only, because you guys are so unable to forecast, because you don't know what you're going to do yet. Team weeks is just fine.

[00:16:13] And we actually called them swags. This is from a guy called Chris Maps[?] I worked with. It stands for sweet wild-ass guess. So swags were done in team weeks, but we needed a common vocabulary, because the edges have to fit. Even if you have every team working independently, think about those connections and make sure you have a common syntax and a common vocabulary. My favorite one in banking and other organizations is the word customer. Who is that customer? 28 different versions of the truth. Define it, put it somewhere.

Dependencies square your uncertainty

[00:16:54] One of my other favorites, I love this one. I worked with the president of a very large organization, 65,000 people underneath him, and I remember him just sitting there with his head in his hands and he said, Tony, I really would love to help my organization get better but I have no idea what's going on. One of the challenges is we just don't see things, and when we connect things together we have a very complex world.

[00:17:25] So I'm going to simplify it for us today. I'm going to go, let's just step back a bit. We've just shipped the latest product, we're going to go on a team dinner, and you know how many there are in the team: four of us. There's four people, but we booked a restaurant, very exclusive, very expensive, not going to tell the finance department that that went on a new AWS shard that we needed. But we're going to go for a team dinner, four of us. That restaurant will only allow us all to go into the restaurant if we're all there on time, and it's got to be at eight o'clock, that's the only reservation they have. Eight o'clock, we all have to be there on time. How likely is that to happen?

[00:18:08] Well, it might be easy, right? There's a one in 16 chance of us all turning up on time. It's not maths, it's just logic. This is from Troy Magennis, a guy I worked with when I was at Skype. There's lots of information, the slides will be available, there's a hyperlink to his content, just download whatever you can from GitHub in his repository, it's awesome. But there's a one in 16 chance.

[00:18:37] Let me ask you a second question. Okay, we go back to the office tomorrow, we just shipped the latest product. Now there's three other teams we need to rely on, so there's four teams that we need to rely on to ship the next version of the product. You know where I'm going. What's the likelihood of shipping when we say we're going to? You guessed right. Here's the teams, here's the number.

[00:19:05] So as soon as you start having dependencies, complicated dependencies of teams, your likelihood of shipping goes down significantly. In fact it's a square of the number of teams. This is not me making it up, it's just logic.

[00:19:25] So then managers go, but we need to create teams of seven plus or minus two people, because agile. Agile does not say that. Nowhere in the manifesto did they say it has to be seven plus or minus two otherwise the world will end. Doesn't say that. There is some stats to show that seven plus or minus two people might be the right answer. However, there's another study that's been done recently in the last few years by a guy called Larry Maccherone that says that teams that are nine to sixteen people approximately are six percent less productive than teams that are five to nine people. Six percent.

[00:20:17] So let me just get this clear in my brain. So a team with almost double the number of people is six percent less productive than a team with five to nine. Which is very interesting, right? Probably. But then you go, I should have five to nine people, because they'll be six percent more productive. Yes, Tony, that's exactly what I would do. However, as soon as I put two of those small teams together and need them to ship anything, I now have double the uncertainty that I'll ever ship anything on time. This is what you end up with.

[00:20:51] Now, I'm not saying that's the answer, but at scale, I worked in an organization where there were seven teams that had to work together to ship anything. Anybody here from UX, you are one of the teams that everybody relies on all the time, and you probably rely on others. So I'm not saying that seven plus or minus two is the wrong answer. What I'm saying is, go and experiment with the data, track how much work you're getting done, and see if bigger teams are better or not by combining teams. If you have dependencies, that's what you do, by zooming up two teams, maybe make them bigger. So, minimize your dependencies.

Decide close to the problem

[00:21:34] Four. Simple one. How many times do people have arguments about things they can't decide at the team level? So what do they do? Well, we had this in one of my previous organizations. The product manager for chat said, I want X number of million to improve the chat experience. Everybody else wanted to do video. He got all the data, because he'd gone out and worked with all the universities on the planet, that said every single young adult does not want to communicate with their parents on video, because they can out-think them in real time. Every single teenager does not want to have a conversation with any of you who are not teenagers, because you can out-think them in real time. If they go on a chat, they can work with all their friends, five of them, to out-think you.

[00:22:19] So everybody else is going, chat? This guy and all the research, we don't agree. What we're going to do is talk to the executives. So we became the 100 percent winner in a one percent market, because we didn't let the person closest to the problem make the decision. So at scale you also have to think about, the people at the bottom have got the data, you need to get it to the people you need to make the decision, or let the person at the bottom just make the call. So, close to the problem.

We need to get this right first time

[00:22:49] Final one: we need to get this right first time. No, we don't. If you do that, you build something like Money Manager that Lloyds Bank built. Zak Mian, who's now on the board of the bank, built Money Manager. He said, of course, I've done all the research, all of the research, we've got personas, we've got demographic studies, we've done workshops, we've had labs where people have been toying with the prototypes, and they've all told us, we hate not having any money at the end of the month, we really should budget better and you need to help us. It was a lie. Complete lie.

[00:23:29] We built it. We spent, Zak says, we spent millions of pounds building Money Manager to help people budget for their money. What did we learn? Nobody really wants to know. And Zak says, that's fine. The great thing is, Zak stands on stage like this in front of 18,000 people who build software for Lloyds and goes, we don't make mistakes that big again, so let's make the experiments a little smaller. But he did that.

[00:24:00] So the other thing, think about them as bets. They're not initiatives. Initiatives makes you think like, oh, we put X amount of money on this and we get X-Y return. Rubbish, you don't get that. At Skype we called them big bets. You're investors. I don't know whether anybody's ever seen an investment, what they have on the end of every investment advertisement I've ever seen: investments can go down as well as up. Same with your experiments.

Guardrails, not big methods

[00:24:28] Unless you think about scaling and you think about making mistakes, the only two things you should do is put guardrails in for your organization, especially as you scale. So, why I hate methods. I hate big complicated methods, because by the time you've rolled out a big complicated method, like some of the ones we're seeing coming out now, you bake in that new method into the organization for the next ten years. It's just so hard to change. As you get bigger and bigger, the way people work becomes increasingly difficult. So what you need to do is build guardrails to keep your teams' brains engaged in improving their processes.

[00:25:04] So one of the examples we did at Lloyds, trust me, in banking everybody wants to write down a process, a process about writing a process. One of the things we did instead is we said, instead of writing a process, why don't we get people to focus on measuring and moving these four things in the right direction? Why these four things? Just like the agile manifesto, it's the only four things we could agree on.

[00:25:29] So, four things. This is what an organization looks like. Most bigger organizations, you look some shape of that, either a big or small version. And we said, you've got these four things you should measure. You kind of look like this. So given that, each of you should think about measuring those things at your level of scope. How are you helping move those four things in the right direction?

[00:26:00] So an example would be, I've just put an example up here for you. The executive level and the team level actually shared one of the same drivers for volume. So the measure was, demonstrate the changes to the assigned business value metric as a result of testing with real customers. You have to be able to prove you've done that. Did we say to the teams how they did that? No, we didn't care. 18,000 people trying to tell them what to do? Yes, we tried that.

[00:26:30] Instead we said, you're smart, we hired you because you're smart, we think our recruitment process was okay, we'll put some guardrails up and we'll let you work out how to do it. Then we gave them some training on many different agile methods, techniques, playbooks, toolkits. They could choose any of those to meet those criteria. That got through group audits at a bank, this kind of approach. So you do this by zooming out and looking at the problem.

[00:26:57] I was thinking, wherever all that time you saw deliver[?], it said there, reduce lead time, which is the time it takes to flow value through your system.

Wrapping up

[00:27:08] So I'm going to wrap up now and talk through these things. The first thing is teams over team, so always make sure you're optimizing for the flow of work through the teams, even if that may mean some teams have to work slower. Harmonize the edges: make sure you're all talking in a common vocabulary where it matters. Where it doesn't matter, just do something else, let the teams work it out, they're smart, and every time you tell them, you're taking away their ability to think, and they will remember.

[00:27:41] Minimize your dependencies, because why? Because it doubles your uncertainty. Maybe you experiment with bigger teams. Make decisions close, because that's what we do in agile. And then finally, adapt or decline: make sure you're putting guardrails, not deep methods. That is the way you do it. You zoom out, you apply that thinking, and I think you've got it. I think you know what to do next with that. Thank you very much.