Five Phrases That Shout Your Agile Isn't Scaling

Knowledge / Inspiration

Five Phrases That Shout Your Agile Isn't Scaling

Enabling the Team
UXDX Europe 2018

My team is doing great. Where's everyone else?
Your Epic is my Feature
Anyone know why we're waiting so long for this API?
Should we use green or blue? Lets ask the Chief Product Officer
We need to get it right first time

Five Phases That Shout Your Agile Isn’t Scaling – Tony Grout, Atlassian
It's seventeen years ago, seventeen people got in a room in Utah and argued, debated about the future of software. They decided they had 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 seventeen people created something we now call “The Agile Manifesto.”
So everything has 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 seventy people; that were going to turn into seven hundred people, seven thousand, and would go on trying to use the same things those seventeen people had decided in a room in Snowbird, we are going to be the way forward for software, and for the way we build things today.
So with that, how many of you are in teams of less than ten? Okay, quite a few. How many of you have more than one team in your organisation 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 was designed to help you try and work through.
I often liken it, when I think about Agile at scale when I have 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.
So all of you are working in these one or these more than one team situations. You as team members, and those of you who are managers; are there anybody who has managed people, here today? You can be honest; we won't throw you out. We have 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.
So what does that mean? Well that means we are now starting to see, and we will go through a little bit more as we go through the journey together. When I was starting to see things like Scout Agile framework come out, Less, Nexus, and many other Agile frameworks to talk about how to scale, none of which have yet been proven.
So we are having to work those things out. And as I think about the journey I have been on, one of the things I think we can focus on to help is, everything for me when I think about scaling is about tracking the flow of work through the organisation, 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 may 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?
I am not going to dig into that today. Anybody wants to talk to me about the incredibly interesting journeys I have been on, I am going to be around for the rest of the day. I have seen it done in many different ways; some good, some bad. But one of the things I am thoughtful about is, we have to zoom out as we think about how we work across those different teams. And if we think about how work flows through those teams, we would have to think about zooming out and thinking about the organization as a whole.
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. And we have lots of ways to help; we are 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 first. We understand many things that will help us.
One of the things I am thoughtful though is, there are many warning signs I picked up on my travels. That mean you need to know when to apply some of those things, some of that thinking that you know; 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.
So chapter one. My team is doing great, and so is everybody else. So does anybody know who this is? Any locals? No one?
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, but 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. You don't want to be in another team; you want to be in this team. This is the most successful team.
The issue with teams and managers who want to be in the most successful team is, they typically optimise to make sure that everybody is 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 is, managers focus on efficiency over effectiveness at that point. They locally optimise their own team. “My team is awesome.”
The problem is when you try to make and keep every team awesome and everybody busy, you can't help but have managers you just can't help but want to fill this spot. They want to put one more car on the motorways. Has 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. But as managers, when we sketch…one of the things I often think about is, and I have written a blog post that was one of the most read blog posts I have written. I am not very good, it’s not that many but it's one of the most interesting for me. It is about this concept of the manager rather.
Now the manager rater is a special device. 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…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 have 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 are not very efficient. Why 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 have ever known.
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 have seen this. I worked in one organisation where the UI people had to have everything pixel perfect. We can't ship this unless every pixel is lined up perfectly. So engineers were just sitting waiting for those things to turn up.
What do engineers do while they are waiting? They don't just sit there idly, they create more things we never asked for, because that's what developers do. So we have the engineers going “rrrrrrr” while the designers are polishing the nosecone of the pixel, and nobody was shipping anything. But everybody said they were doing awesome things. Yes, we are making the UI pixel perfect so that the users will get the best experience ever on the planet. Engineers going, “Well, while they are doing that we will just make the codec one millisecond quicker and hence we ship nothing.
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 are so simple somebody can't say, “I didn't understand.” This is one of those things where you go, Okay. Eli Goldratt came up with this, if you love novels there is a book called “The Goal” you can read. The Goal, it's a novel written about the Theory of Constraints.
But this says if you find, what you do is, you have to look through your system; step up, zoom out, and you look and see where the work is clogged up. Now, one of the ways you can see that, has anybody used a kanban board? They are not just for your managers; they are not just pretty stickies to make sure 3M keeps in business. What you will see is, there are some columns in there where they are going…and one of those columns that we saw was the UI team; all the stickies were stuck with the UI team, and we are going, “Well, there is clearly a bottleneck here.”
So, then when you see a bottleneck, this is what you do with the bottleneck. First of all, you will identify it, then you exploit it, sounds worse than it is. So what you do is, you go “Oh, there is a bottleneck here.” The UI team, how do we make sure the UI team is 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.
You can then Subordinate, which is what you then do, you make everybody else slower. Not as bad as it sounds, but actually makes sense. There is no point making everybody else go quicker if all you are doing is putting more stickies in the “it's not done” column. Sometimes it's better just to be 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 fixed it the first time, all you have done by the way, shock horror, is you have just moved the bottlenecks 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.
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 those pixel-perfect things come in, if they are not quite pixel perfect they can edit them in the product, and then ship the product. Your engineer is right; stop writing more things that nobody wants. Build something that the UX team can use to make their lives easier; that's subordinating the constraints.
So, not only did we slow the engineers down, we got them to build tools 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 are doing worse, but that's where you as you as, 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. You can't fail in the space. There is no reboot. There is no, “could you restart the computer.” You are dead.
So, one of the things we did, one of the things we started to look at is, we use some of the concepts that they used on the space station where, in the International Space Station one of the things that they did when they started to build the International Space Station is that all the components were built in different countries. I am going to say that again. All the components were built in different countries. We think it's hard to put software together. What they found was that they had to start thinking about how interfaces became incredibly important. So important, that they actually had interface managers on each side they actually created a role as 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. 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 tops 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 shift, then I need some way of commonly talking about capacity, for example.
So in Skype we use scrum team weeks. Most teams are using scrum and we just said, “Let's just use scrum team weeks.” In your sprints 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 are going to do yet, team weeks are just fine. And we actually called them swags.
This is a guy called Chris Mapson I work with, 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 any other organizations, is their word “customer.” Who is that customer? Twenty-eight different versions of the truth; define it, put it somewhere.
One of my other favorites, I love this one. I worked with the president of a very large organisation with 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 organisation 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 complex world. So I am going to simplify it for us today. Let's just step back a bit and go, “We have just shipped the latest product, we are going to go on a teen dinner.” And do you know how many there are in the team, four of us. There are four people but we booked a restaurant very exclusive, very expense, not going to tell the finance department that went on a new AWS shard that we needed. But we are going to go on a team dinner, four of us.
That restaurant will only allow us all to go into the restaurant if we are all there on time and it has got to be at 8 o'clock, that's the only reservation they have; four of us, 8 o'clock, we all have to be there on time. How likely is that to happen? Well, it might be easy. There is a one in 16 chance of us all turning up on time. It's not maths, it's just logic. This is from Troy McGinnis, a guy I worked with when I was at Skype. He was there with lots of information; the slides will be available. There is a hyperlink to his content, just download whatever you can from GitHub in his repository, it's awesome but there is a one in 16 chance.
Let me ask you a second question. Okay we go back to the office tomorrow, we just shipped the latest product, now there are three other teams we need to rely on. So there are four teams that we need to rely on to ship the next version of the product. You know where I am going. What's the likelihood of it shipping when we say we are going to? You guessed right; here are the teams, here is the number. 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.
So then managers go, “But we need to create teams of seven, plus or minus two people, because Agile says so.” 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; it doesn't say that. There is some stats to show that seven plus or minus two people might be the right answer, however there is another study that has been done recently in the last few years by a guy called Larry Merceroni, 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.
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. But then you go, “I should have five to nine people because they will be six percent more productive.” Yes, Tony, that's exactly what I would do. However, as soon as I put those two teams to get 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.
Now, I am not saying that's the answer, but at scale I worked in an organisation 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 am not saying that seven plus one or minus two is the wrong answer. What I am saying is, go and experiment with the Data, track how much work you are 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 minimise your dependencies.
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 my previous one of my previous organisations. The Product Manager for Chat said, “I want X number of million to improve the chat experience.” Everybody else wanted to do a video. He got all the data because he had 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. So everybody else is going to chat. This Guy did all the research; we don't agree. What we are going to do is talk to the Executives.
So we became the 100 percent winner in a 1 percent market because we didn't let the person closest to the problem make the decision. So it's scaled, you also have to think about the people at the bottom who have 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.
Final one, we need to get this right first time. No we don't. If you do that you build something like the money manager that Lloyds Bank built. **(Zack Mayan?), **who is now on the board of the bank built money manager. He said, “Of course we have done all the research all of the research, we have people named, we have demographic studies, we have done workshops, you have had labs where people have been toying with the prototypes and they have 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, a complete lie; we built it. Zack says. “We spent millions of pounds building a Money Manager to help people budget for their Money. What did we learn? Nobody really wants to know. And Zack says that's fine, the great thing is Zack did that standing on stage like this in front of 18,000 people who build software for Lloyds and goes, “We don't want to make mistakes that big again, so let's make the experiments a little smaller,” but I did that. So that's one of the things. So what the other thing, you think about them as bets. They are not initiatives. Initiatives make you think like. “Oh, we put X amount of meetings on this and we get XY return; rubbish. You don't get that.
At Skype we called them big bets, your investors. I don't know whether anybody has ever seen an investment, what they have on the end of every investment advertisement I have ever seen, “Investment can go down as well it up.” Same with your experiments. Unless you think about scaling, and you think about making mistakes, then one of the things you should do is put guardrails in for your organisation, especially as you scale. So why I hate methods, I hate big complicated methods, because by the time you have rolled out a big complicated method like some of the ones we are seeing coming out now, you will 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 team's brains engaged in improving their processes.
So what we did with 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. But 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 is the only four things we could agree on. So four things; this is an organization that looks like most bigger organisations. You look at some shape of that either big or small version, and we say, “You have 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?
And so an example would be, so I have just put an example up here for you, so the executive level and the team level they actually shared one of the same drivers for value. So the measure demonstrated the changes to the assigned business value metric as a result of testing with real customers. You have to be able to prove you have done that. Did we say to the teams how they did that? No, we didn't care; 18,000 people were trying to tell them what to do. Yes, we tried that. Instead we said, “You are smart.” We hired you because you are smart. We think our recruitment process was okay, we will put some guardrails up and we will let you work out how to do it. Then we give them some training on many different Agile methods, techniques, play books, 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. I was thinking that the time you saw “deliver it” said there, reduces lead time, which is the time it takes to flow value through your system.
So I am going to wrap up now and talk about these things. So the first thing is team over team. So always make sure you are optimizing for the flow of work through the teams. And that may mean some teams have to work slower.
Harmonise the edges make sure you are 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 are smart. And every time you tell them, you are taking away their ability to think and they will remember.
Minimise 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 are putting guardrails, not deep methods.
That is the way you do it. You zoom out, you apply that thinking; and I think you have got it. I think you know what to do next.
With that, thank you very much.