Repeatable Autonomous Team Delivery

Tony Grout at UXDX Community: Amsterdam. Video: https://youtu.be/j5dXrSua57E

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.

What high-performing teams look like

[00:00:11] Thanks very much for having me, hope it's going to be interesting. I've had an interesting career. I've made many mistakes. I've run two startups, founded two, sold two, made money once, lost a lot of money twice, that's why I'm still working. But I have found my home, I think, now with Atlassian, last year. I'm going to talk to you through some of the experience I have had, I'll make them very personal, but also some of the ways that Atlassian thinks about the world, which I think might be interesting. One of the reasons I'm joining this is because I think the way Atlassian thinks is the way I think, and I hope you'll share some of that with me.

[00:00:46] The first thing is that at Atlassian we have a vision, our mission, to unleash the potential in every team. That seems really focused on how do you make teams productive and get that scaling of accelerated delivery. It's teams. We achieve very, very little on our own. So I was quite excited about that, having worked in organizations and grown from very small teams. My first startup that I did, there were five of us in a place. I wish it looked like this, but it didn't. It was back in, more years than I care to remember, about 30 years ago. They didn't have places like this. It was in some shed somewhere in somebody's garden. Teams are the real thing that kicks everything off.

[00:01:31] In Atlassian one of the things that's interesting is we've spent a long time looking at what teams are the most productive on the planet. As we look at it, some of the characteristics we see of high-performing teams are these kinds of characteristics. These are the characteristics that you'd think, when we looked at the most high-performing team we could find, or the most efficient team we could find, these are the kind of characteristics they had. No new news: clear processes. Like, really, that's it? Nothing about, you know, we all have cuddly toys that we carry around with us, or beanbag parties. Nothing like that in there at all.

[00:02:21] Sustainable teams. We all know that having groups of people who can work together and build teams, the forming, storming, norming, performing thing, and stable teams. Personalized tools: you need to bring your own, my favourite editor, my favourite user experience tools that I use. Strong manager. A team, because we all get distracted sometimes. At Atlassian, I described Atlassian, a friend of mine said what's it like working at Atlassian, and I said, well, you've got to imagine 2,000 cats in a glitter factory. We are such doers in Atlassian. One of the problems, or the challenge with Atlassian, I'll come on to later, is trying to get us to focus on getting everybody aligned and on the same thing together. I'll come back to that in a minute. But you need a good strong manager, structured roles, et cetera.

[00:03:15] Now the interesting thing, when we looked at the teams that meet these characteristics the best, the most highly efficient teams we could find, it kind of looked like this. Bethlehem Steel was where we found one of the most efficient teams on the planet. They had all those characteristics. That's all they did, every single day. Bethlehem Steel was, they literally took coal from a pile over here, put it on a shovel and put it into a furnace over here, all day, every day, for hours and hours and hours. They had specialized tools, a shovel, a 21 pound shovel that was optimized for getting the most coal from here over to here. And they had set breaks, all the things that you see on that chart.

[00:04:17] Is that the world that we want to live in? That's the world we worked in. It doesn't feel like where I want to move. I'm going to come back to that in a minute.

Trust, and what McGregor actually said

[00:04:27] One of the things as we think about the world differently, I'd like to think about some of the things I've seen as I try to do large scale transformation. I worked at Skype. I was brought in by Silver Lake private equity to help fix Skype, which was exciting, just before Microsoft purchased it for eight point five billion dollars. And I was also involved in the transformation of Lloyds Banking Group, with 23,000 people, to think more digitally. One of my observations is, to make that kind of change in an organization you need these three things. Again, wow, that's really mind-blowing, right? If you're interested in organizations, it's almost disappointing I have to put those three words up.

[00:05:11] Has anybody here ever heard of Scrum before? Okay. One of the things I love about Scrum, many things, I would talk about Scrum for hours and many other approaches, and I'll talk about that later, but one of the things I love about Scrum is just like these three things. The first page of Scrum says Scrum is a framework for delivering software, it's easy to understand and hard to do well. Easy to understand, hard to do well. I want to talk a little bit about what that means.

[00:05:54] The first thing is, I've already asked you to hold that question in your mind about is that the place we want to work. All right, I'm going to ask you another question, because you look quite smart, really intelligent, so I'm going to ask you all to participate with me on this. This is a study done by a social scientist called McGregor. Has anybody seen this before? Okay, this was done by McGregor, and I want you to think about it for a minute. The whole idea that the research McGregor did said, there's Theory X people and there's Theory Y people.

[00:06:29] I just want you to read down the list of Theory X characteristics and Theory Y characteristics, and think: do I know anybody in my organization, or the people who are all my friends, my relative, my partner, who works anything like this way? They dislike work. They need to be supervised at every step. The less time you're watching them do the work, the work doesn't get done. Classic. No incentive to work, no ambition, therefore they need to be enticed by rewards to get things done. Remind you, do you know anybody like that? Anybody like that? No? No? Maybe not. So wow, you are an interesting audience. I want to find all your friends.

[00:07:25] And the other thing is Theory Y. Theory Y people are happy to work on their own, enjoy taking ownership of their work, solve problems creatively and imaginatively. How many of you are like that? Yeah, okay. Interestingly, statistically, most of you would have said you've met people like this, but all of you think you're like this.

[00:07:49] And what McGregor said was, the interesting thing is there is no such thing as Theory X and Theory Y people. It's where they work that makes the biggest difference. There's no such thing as somebody, there's nobody who starts out like this. When you start to think about your organizations, and you as leaders, or leaders already in your organization, or people you just work with, the thing to take away is that nobody starts out like this. You have made them like that, if they are like that, or you're not helping them to be like that. Trust me, I worked in banking. I no longer work in banking. But I have worked in large corporates and small organizations, where some founders I've worked with in my past hire people and then whip the hell out of them till they get stuff done. So again, it's not about scaling, it's about culture. That's one of the things I want to talk about, and that's all about trust.

[00:08:54] I'm always curious when an organization hires people, how long they spend hiring people. At Atlassian we have no process of hiring. You meet 28 different people over five different time zones. You do all sorts of crazy things, meet people. I remember one person telling me they had an interview with someone who turned up with a crocodile outfit on, because we were having a party one day, and so that's what you saw on the end of your Skype chat. Okay. But we are really careful about making sure that we hire people we trust, and then you don't need to worry about where they are or what they're doing.

Agile as a weapon against developers

[00:09:42] Interestingly enough, recently, does anybody know the Agile Manifesto? Okay, so Ron Jeffries has just come out and said this, this month or last month, which I think is quite interesting. So why did Ron Jeffries say that? Ron Jeffries is now saying, just like Bethlehem Steel, that large organizations, organizations in general, are now using agile as a weapon against developers, because they don't trust them to do the work. The transparency that agile gives executives and leaders and managers that they never had before is now being used to beat up developers and all the other team members. Now that for the first time they've seen information, because the executives can see the work, they're now criticizing the work more than they ever could do with waterfall or more traditional models, because they couldn't see it. It was complete chaos before, but nobody could see that. No plan ever reflected reality. Now they can see what the plan looks like, and they're beating everybody up because they don't like the plan, because they don't trust the people doing the work.

[00:10:58] So I think it's interesting that Ron Jeffries has come out and said this, and we should really think about and reflect on, if we lead teams and we're in organizations, are we encouraging this? Are we encouraging the fact that that transparency is beating up teams? In fact, I was in one meeting, I won't say where, I have many places I've worked, where for the first time a senior executive saw a burndown chart from the team. Now, I walked into that meeting, I had no idea the project manager, who was doing their first agile[?] project, was going to take a burndown chart along. The first thing the senior executive said was, why on Wednesday did it not go down a lot? You wouldn't have seen a plan for like three months in the old way of working, and now you're beating some manager up about what the team were doing on a Wednesday. So just think about that when you go through it, think about the trust thing.

Turn the ship around: giving decisions back to the team

[00:11:56] This is one of my favourite books. If you ever have worked with managers, or are a manager or a leader, this is an awesome book. For those who don't mind reading, there are David Marquet's videos, which are equally good, he summarizes it quite well. I've met David, he's a fantastic, very curious, charismatic character. He was the skipper of a nuclear submarine. Has anybody read this book? He was the skipper of a nuclear submarine in the US Navy, and when you are the skipper of a US submarine you are the guru on that vessel. There is nothing you don't know. You are given the manuals months before you get a ship, you read them all, and David read all the manuals for the new submarine he was getting. Problem was, they gave him a different one. At the last minute they changed the submarine, so he was no longer the smartest person on the ship.

[00:12:59] A quick story that David tells in the book, and there are some fantastic leadership examples in there about how to manage without telling people what to do, giving people back the trust. He says at one point it was his first time at sea trials, when they take the submarine out for sea trials, and he issues the command to the first officer, ahead two-thirds. The first officer says, helmsman, ahead two-thirds. Nothing happens. Ahead two-thirds. The first officer says, helmsman, ahead two-thirds. Nothing happens. I'm the skipper, I have issued a command and nothing is happening. This feels wrong to me.

[00:13:48] So he says to the first officer, I don't understand, I've issued a command and nothing is happening. Why is nothing happening? Well, nothing is happening, sir, because this submarine has no two-thirds. So no, but, and then he said, so why don't you tell me we don't have two-thirds? You're the skipper, sir, and the rules say that we just do whatever you tell us, and that's that.

[00:14:20] David then turns, he does a whole heap of good, there's a whole heap of knowledge in this. One of the things I love is this is a reason why you should move to the model of giving your teams the ability to make better decisions. I've worked in organizations where if you don't follow the process you get fired. The danger with just mindlessly following a process is it's the most risky thing you can do if the context has changed. We work in a world now where that happens every day. David Marquet worked on a nuclear submarine where the world changes minute by minute. It's a good book, take a look at it.

[00:14:55] At Atlassian, one of the ways we solve that is because we have a set of values that we strongly believe in, and one of those is being an open company. What that means is we have surprisingly open conversations about things that people don't agree with in the company. It can be pretty uncomfortable sometimes watching that happen, and it happens in real time on Confluence. So suddenly you'll find the founders of Atlassian, even though they're billionaires now, just wandering in like in the middle of it, you'll see Mike or Scott suddenly pop up and go, actually I think this. Mike and Scott want to hear that. So in your organization, think about how you're doing that in your organization.

Purpose: repeatable without the why is monotony

[00:15:41] I'm going to quickly talk to folks on purpose now. This is Scrum, and this is how it can feel working in Scrum or any other agile approach if you're not careful. Repeatable without the why is called monotony. If you're a developer working on product backlog item 230, and next week you're the developer working on backlog item 360, and the week after that you're working on backlog item 750, it kind of feels like this. Shovel the coal, walk over here, put the coal in the hole, again coal. Why are we doing this? To make steel. Okay, how does that make me feel better? Not really.

[00:16:27] One of the things I'm always thoughtful about is this is the app I used to show my old boss. Has anybody seen this? It is scary, really life-changing. It's called Life Calendar[?]. It puts a circle up for every year of your life and shows them getting filled in as you live your life, and it has a number at the end. When you're a developer working on a project, or a user, or a UX person, or anybody on a team, and you realize you've wasted a whole one of those circles on something that you have no idea why, it's a focusing moment. As I used to tell my old boss, I am not spending another year of my life beating my head against the same brick wall, because I have only so many dots left, John.

[00:17:15] So when you think about working with teams and the purpose, if they don't know why they're building what they're working on, they're looking at this, and you're looking at this and you're thinking, why the hell am I doing this? In large organizations your ability to be so far away from the why am I doing it gets increasingly hard. My favourite jobs of all time, there were two. I can name two jobs I've had that are my favourite, and this is my third, the two before this. The first one was when I built medical software, and we built HIV software, we actually did. When you now have HIV you get a whole set of drug regimes given to you, and my company built all the modelling software for that, back in the late eighties, early nineties. Why is that important to me? Because I knew why we were doing it and I could see the impact we were having.

[00:18:12] My second role that was most interesting for me was when I worked at Skype. You have no idea, when you work for Skype, what it feels like to walk up to somebody. I remember walking up to US immigration. Anybody been there, to US immigration, when you go to passport control? They have like no sense of humour, it's a no sense of humour zone. I walked up to them, I remember walking into Seattle, we'd just been acquired by Microsoft, and I said to the guy, hello, I'm here, and he said why are you here? I've come for business, I work for Skype. I love Skype, I talk to my mother every day on Skype, she lives in whatever country it was.

[00:18:51] Are you giving that to your teams? Are you giving that level of, what the hell are we doing this for, am I feeling better about this? That will generate ten times more outcome than a better plan.

Give them the information, share the why

[00:19:06] So the other thing here is give them the information they need. This is again one of David's quotes that he uses internally: get the information to the people, get them the why. You can only begin to imagine. I love the fact when we do this experimentation. We do an experiment for a whole year on a new feature, and we're going to put a GIF over[?] it, okay, sounds great, let's do that. So off the team goes away for a whole year, and then at some point something goes, well, like that. But it's been a whole year building nothing, and actually, in fact, they don't even know anybody switched it off. It's like being a movie actor and they suddenly go, that's it, your first role in a big movie, and then suddenly you find it's been cut when you go to the cinema with all your friends. Like, that sucks.

[00:20:00] So tell them, right? Let them know. Don't tell your friends to go to the movie, it's not going to be in. All right, at least you don't look dumb. So share your insights and whys. If you're doing user research, the team, some of the development teams are too far away sometimes. So if you are developers, I'm still guessing, any developer will say, yeah, they can suck if you have no idea why the hell you're doing what you're doing. So people deliver better when they understand why. Make people smile, show them how what they're doing impacts the people. Most engineers, what they get up about every morning is they want to make a difference, and if they have no idea how it's making a difference, though.

Alignment: 300 teams, one backlog

[00:20:44] So, final one, alignment. We all have different measures, it's exciting, right? Everybody, say, operations people, all they're trying to do is keep the service up. In banking that's 99.999% of the time. In banking, in Skype, they have the same purpose of trying to ship everything as quickly as possible. That's a conflict. So operations people are sitting there going, you're not changing the code on my watch, and user experience people are going, we just want to make everybody happy. And that's got to work. They've all got different metrics.

[00:21:22] And then you've got to fit it into this. This is what a bank looks like. Here's some numbers of thousands of people who have been involved. You've got to make all that work across all those thousands of people. Each one of those circles is a team of about seven or eight people. There are thousands of people involved. Nobody actually realizes how complicated it is. So making that work across that means you get this: every single team thinks they're doing the right thing, every single team is finishing their stories, yes, another story done, and you are shipping like nothing.

[00:22:00] When I turned up at Skype, that's what I found. I turned up at Skype, 300 teams. Is that right? 300 teams. It takes a lot to ship, it's complicated to make video work across the globe. Three hundred[?] teams doing this, all thinking they're doing awesome things, and we hadn't shipped anything the subscribers cared about.

[00:22:23] So what's fastest? We started off by saying, you know what, you all ship the experience. But Microsoft, I love the fact when I turned up at Microsoft they have one thing that says we all ship software. Are you a software tester? Yes. Your job is not to stop software getting out, whoever you think it is, but it's not, your job is to ship the software like everybody else.

[00:22:44] So the first thing is we did this. The second thing is we created an organizational backlog. At the organizational level we said these are the things we care about, in the order we care about them. Why did we do that? We did that so that 300 product owners could stop fighting about who was the most important, because the executives told them. I just put up a backlog and said, if you have to work out which team is going to work on what in which order, this is the order.

[00:23:14] And then we created something called the wrong order award. So then we had a chart that showed the team that was working in the most wrong order, and they got an award every three months, which was a tin of Vegemite or Marmite. In the UK it's a horrible spread that you buy for your toast, so some people love it, some people hate it. Yeah, there are lovers and haters. And we also had different awards for the teams that were working properly down that backlog, just as a bit of fun, so that all the teams can focus on shipping the highest thing first.

[00:23:53] With that you get this. You start to have a one backlog approach at the team level and you link everything back to that. We went from hitting 3% of the outcomes we needed to over 30% in the space of a year. Now that sounds like a long time, but trust me, if anybody hasn't tried to do transformation with 300 teams before, it's freaking hard, right? 300 teams with the most opinionated developers on the planet, and trust me they are opinionated. You get ten times increased value by having that backlog, and then we kept on improving and improving.

Repeatability: optimize for simple over smart

[00:24:35] So, repeatability. When you're trying to do repeatability at this level you have to optimize for simple over smart, every time. There are a number of organizations where I'm like, we're going to roll out SAFe, and I'm like, have you read that framework? Really? That's like really hard. There's like thousands of pages of guidance. It feels like a process manual, and nobody ever reads the manual. Make your ways of working so simple that somebody can't say they don't understand it.

[00:25:08] The number of times, you have 300 teams and you go, so why are you working up the backlog the wrong way? One of the things they could never say is, we didn't understand. Okay, there's an order to a backlog, right? I mean, you're paid like, you know, you're paid the national debt of Brazil as a team to fix the problem, and you don't understand you start at the top and work to the bottom? Really? Okay, maybe we need to think about who we hire next.

[00:25:37] The other thing we gave people is what I call enabling constraints. Enabling constraints are, give people some really clear rules, again make them really simple so that nobody can argue with them. They may not like them, but they're simple. And just say, go for it. You can do what the hell you want. Work down the backlog at the organizational level in the order we told you, and hit those targets. You're a smart team, work it out. If you can't work it out, we'll come and help, we've got people, but just work it out. Here's some simple rules, here's some simple constraints.

[00:26:12] And then have those teams publish their working agreements openly, so that everybody else can see how they're working. Publish it on, we use Confluence internally, you've got a wiki tool, we use Confluence, you can use whatever tool you've got. And make sure every team knows when and how other teams work: which dailies do you have, your reviews, your retrospectives, which days do you do your sprint reviews, all those kinds of things. If you're using Scrum, just publish those up so teams know how to work with you.

[00:26:44] And repeatable shouldn't be dumb[?]. If you're repeating stupid things, you're still building. The first thing, in my experience of running large agile transformations, and I ran Skype for Windows for a while, guess which of the events in Scrum is dropped first? The retrospective. Why? We're too smart to improve now? Or we don't understand any more how to get better? That is not a reason to remove the retrospective. That is a reason to go and find somebody else to help you. So repeatable doesn't mean repeating the same things. Find others to help you.

[00:27:25] Really smart teams, the best teams I've ever worked with, first of all they fight the most out of any teams I've ever worked with, because they're all strong and opinionated. They're a bit like most sports teams. Most sports teams that are high-performing do not get on with each other, because they get on with each other to get the job done. You're not there, in a team or as a manager, to have a wonderful time. You're there to drive the right outcomes. So think about that.

Deming, and what to take away

[00:27:56] So, this is Deming. First of all, I love this phrase. When you go back and you start blaming devtools for how crap they are, it's your fault, it's your part of the system. Edwards Deming here is the guru of systems thinking, who basically single-handedly almost fixed Japan after the second world war. It's the phrase he used like nothing else.

[00:28:18] As you think about moving forward, think about trusting the talent you hire and earning the trust, to deliver better outcomes by having your teams understand the why. If you don't know what the why is, by the way, you're a victim if you don't ask. It's not an excuse to go, no, you told me. Go and ask.

[00:28:39] And then alignment. Without a common goal, having two hundred autonomous teams, trust me, that is madness. It's just chaos. It's not agile, it's just chaos. What you do need to have is some harmonization of the work as the teams touch each other, you need some harmonization. Atlassian has a lot of this described in some of the playbooks. Anybody who just searches for the word Atlassian and then playbook, there's one on team health: how are your team doing in these areas? You can start to go to the Atlassian playbooks, they're free, and just run them internally. You may not like the answers you get, but agile is a good mirror. So take a look at our playbooks. Be the change you seek, that's one of our values, which I love. Go make it happen in your own organisation. Hoping you're taking something away.