Jeff’s work has really had a profound impact on the way I approach a lot of problems. I remember when one of the companies I ran switched to Scrum (mSpoke) and it was like a light switch went on in the organization.
I can’t really talk enough about how positive Scrum’s impact was on that organization and a lot of the companies I’ve worked with since then.
It was really amazing to meet Jeff. He’s a brilliant guy and I took away a ton from our conversation.
If you’re thinking about how to operationalize Agile philosophies in your organization regardless of the size, I think Scrum is a great technique. And if you’re already using Scrum, hopefully, there’ll be new things you can learn from our conversation. I know there are a few things I’ve already changed in terms of how I recommend deploying Scrum based on this conversation.
Show Links
I also hope you’ll consider subscribing to Agile Giants if you haven’t already on:
- iTunes (also if you feel like the podcast deserves 5-stars, would love a rating on iTunes)
- Spotify
- Google Play
- Or use RSS in your favorite podcasting software
Transcript
Sean Ammirati: 00:08 Welcome to Agile Giants. Lessons from corporate innovators. I’m Sean Ammirati, your host. Co founder and Director of the Carnegie Melon Corporate Startup Plan and Partner at the early stage Venture Capital fund, Birchmere Ventures. Each week, I’m gonna talk to guests who are experts at creating startups inside large corporations. I believe fundamentally, a startup within a company is the same as one inside the proverbial garage. A group of entrepreneurs trying to make the world a better place using new ideas and inventions. However, I also believe some of the techniques and processes are just inherently different. This podcast is going to explore those similarities and differences.
Sean Ammirati: 00:56 First of all, thanks for all the positive feedback on last week’s Beth Comstock interview. I’m glad you enjoyed listening as much as I enjoyed our conversation. Also as a reminder, please go to iTunes and rate/leave comments on Agile Giants. It really does help others discover this content.
Sean Ammirati: 01:13 One other editorial note, April 29th through May 1st 2019 I’ll be participating in the IRI annual conference. The theme is innovation unleashed, physical meets digital. And this year it’ll be based in Pittsburgh, Pennsylvania. I’m leading three discussions throughout the conference as part of CMU’s collaboration with the event and I’ll be joined on one of those panels with a number of former guests from this podcast including Dennis from Bosch Connectory, Terri Lonier, and Gustavo from Safety IO. You can get more information and register at iriannual.com. I’ll include a link in the show notes.
Sean Ammirati: 01:47 Now for this weeks episode, I’m joined by Jeff Sutherland, the inventor of Scrum and one of the authors of the Agile Manifesto. Jeff’s work has really had a profound impact on the way I approach a lot of problems. I remember when one of the companies I ran switched to Scrum (mSpoke) and it was like a light switch went on in the organization. I can’t really talk enough about how positive Scrum’s impact was on that organization and a lot of the companies I’ve worked with since then. It was really amazing to meet Jeff. He’s a brilliant guy and I took away a ton from our conversation. If you’re thinking about how to operationalize Agile philosophies in your organization regardless of the size, I think Scrum is a great technique. And if you’re already using Scrum, hopefully there’ll be new things you can learn from our conversation. I know there are a few things I’ve already changed in terms of how I recommend deploying Scrum based on this conversation. I really hope you enjoy episode 11 of Agile Giants.
Sean Ammirati: 02:53 Welcome to another episode of Agile Giants, I am really excited and kind of humbled for today’s interview. I’m joined by Jeff Sutherland who I think most of the people on this podcast know who Jeff is. If you don’t know who Jeff is you’ve certainly been impacted by a lot of his work. He was a contributor to the Agile Manifesto, he’s one of the inventors of Scrum, the development engineering process. So I’m guessing you know who he is. But in case you don’t and what I think a lot of people don’t know, I was looking at this myself, Jeff is probably sort what led you to that interesting career. So could you start by maybe giving our audience a little bit of a sense on your background and what you’ve done?
Jeff Sutherland: 03:35 Sure, glad to. You know, Scrum derives from 11 years of fighter pilot training. I was a fighter pilot in the Air Force and in fact this weekend I was at the Air Force center for figuring out how to get the entire Air Force Agile. And it’s all based on John Boyd, the world’s greatest fighter pilot and what is called the OODA loop, observe, orient, respond, act, how to respond quickly and dynamically in the environment. That’s the operational piece of Scrum. The theoretical pieces of Scrum actually the Air Force sent me back to school and I wound up as a professor of mathematics at the Air Force Academy and completed my doctoral work at the nearest medical school at the time. So that led to an 11 year career as a professor of radiology at the University of Colorado School of Medicine. And there I had millions of dollars every year from the national cancer institute to mathematically model the human cell. And learning about what causes a cell to change, we were particularly interested in what causes cancer, led me into the study of complex adaptive systems and evolutionary biology. And realizing that any system, whether it’s a cell, a person, or a team is a complex adaptive system and will migrate through the state space of functionality. Either in a positive or a negative direction. Because of small changes that are caused by incidents that occur that effect the environment.
Jeff Sutherland: 05:15 So Scrum is based on that idea. Small, incremental changes can produce awesome teams. I was working with Bell Labs at the medical school using their tools and technology and particularly the team that had Kernighan and Ritchie on it, the inventors of the C language and Unix and their mentality was awesome in terms of how you approach computing, building systems, and so forth. In 1983 I was asked to join a large banking company. They said, “Jeff, you guys are the experts in technologies we’re using at the bank. We don’t know what we’re doing. Why don’t you come over and help us out?” So they made me an offer that my wife couldn’t refuse. I wind up at the bank. And I was their Vice President for Advanced Systems. Effectively the CTO of 150 banks.
Jeff Sutherland: 06:11 And within a few weeks of being there looking at what they were doing I realized that this project management methodology with the Gantt charts was making all the projects late. It was a completely inappropriate mechanism for managing large protects of the banks. So I went into the CEO’s office and I said, “Hey Ron, have you noticed all your projects are late?” And he said, “Yeah, at least four CIO’s call me up every morning and they scream at me.” And I said, “Well, I’ve calculated the probability of a project being late based on looking at thousands of tasks on the Gantt chart and calculating the probability that one of these tasks slides and is late and makes the whole project late. And that probability analysis indicates that all your projects are gonna be late. So you need a completely different approach to building systems.”
Jeff Sutherland: 07:12 He said, “What should I do?” And I said, “Let’s take the worst business unit in the bank, the one that’s losing the most money, and we’ll implement a new operating system and you and the senior management can be like my board of directors and I will do kind of a start up within the bank. With a new approach.” And so, I said I need everybody, this is for sales, marketing, support, installation. This is not an IT thing, this is an organizational thing. And we broke that unit down into small teams, four or five people. Monday morning the product managers would come in and prioritize everything by business value. And I told the teams, every Friday afternoon everything’s live. I said I’m gonna train you just like I train fighter pilots to land that project right at the end of the runway. And I know you’re going to screw it up a few times, just like the pilots do. And we’re gonna come around and keep doing it until we can nail it. And I’m gonna give you a burn down chart so we can see exactly where you are in the glide path.
Sean Ammirati: 08:16 Really, so you were doing burn downs even then …
Jeff Sutherland: 08:19 1983. This is 1983.
Sean Ammirati: 08:20 Wow, okay.
Jeff Sutherland: 08:22 So off we went, they screwed it up for about six weeks but finally they nailed it. Within six months it was the most profitable business unit in the bank and the bank said, “Hey Jeff, here’s $20 million more to invest in building more Scrum.” So what people don’t realize is that this is a research project that has gone on for 30 years and there’s been really massive amounts of money invested in it. I mean probably $250 million of my own budget has been invested in developing, measuring, and improving the performance of Scrum. And in 1993 I was pulled into multiple technology companies to help them improve their delivery of product. And in 1993 at a company called Easel Corporation we were building tooling to replace … Easel was the first 4GL language company. And we were building tooling to take the technology beyond 4GL languages and I knew that in order to use that tool I wanted to, when we sold that tool, I wanted to guarantee that you would double production within the first month or you got your money back.
Jeff Sutherland: 09:38 And I knew to make that guarantee work the process for building systems with that tooling, they needed to use … We didn’t have the word “Scrum” but they needed to use what today is called Scrum. And so I told the team, we not only need to build the tooling, but we need to formalize the process that we’re using. And we began to … In technology implementations I’d done multiple implementations at different companies, you always have to go through the entire computer science literature in order to move beyond what’s been done before. And I said, we’re gonna have to read 1000 papers before we understand enough. And we’re gonna have to benchmark this. We’re gonna get the leading productivity company in the world, software productivity research, we’re gonna bring their tooling in, we’re gonna benchmark this, until it’s 10 times faster than normal development because we know a new invention, startups can’t deploy that unless it’s 10 times better. So it’s gotta be 10 times better.
Jeff Sutherland: 10:43 So off we went, we got lucky on the 300th paper, roughly about 300th. We read a paper in the Harvard Business Review, which surprised me, by Professor Takeuchi and Nonaka and they were looking at the best teams all over the world in leading hardware companies. And they said these teams are working so closely together that they remind us of rugby teams, the game of rugby. So they said, we’re gonna call this Scrum project management. And the team, whenever we came upon a paper like that that was really good, the entire team would read it the same day, we’d have a retrospective at 5pm at night. And when we did a retrospective on that paper the team said, “We need to call what we’re doing ‘Scrum’” and someone said, well what will we call the team leader, and one of the team members says, let’s call them the Scrum master. So the word Scrum and the Scrum master came from that paper.
Sean Ammirati: 11:40 And when was this again that you-
Jeff Sutherland: 11:41 It was 1993.
Sean Ammirati: 11:44 So you were using the term Scrum before the Agile Manifesto then?
Jeff Sutherland: 11:48 Oh yes. What people don’t realize is that the 17 people that wrote the Agile Manifesto, there were only two widely deployed processes, Scrum and Extreme Programming. And in 1995 after Scrum had been running for two years, I pulled Ken Schwaber into the team, Ken was CEO of a project management methodology company, traditional. And I brought Ken into the Scrum and I said, Ken, you know the stuff you’re selling doesn’t work, I wanna show you something that does work. And he spent two weeks with the Scrum team and I said, why don’t you sell Scrum and he said, well you’re right. This really does work. We decided it would be open source. We also decided since Kent Beck, the founder of Extreme Programming, was asking me for everything about Scrum, he said I’m building a new process, I don’t wanna reinvent anything. We said, let’s let Kent take the engineering practices, the engineering practices is XP were all used in the first Scrum team. And let’s have Scrum focus on the team management process. And so that was the decision and then Ken and I wrote the first paper on Scrum in 1995 and published it.
Jeff Sutherland: 13:08 So six years later, in 2001, the founders of Extreme Programming and the founders of Scrum got together at the Agile Manifesto meeting with a bunch of consultants and authors of books, thought leaders. And many of them had been working on books on how to have a more adaptive organizations. Alistair Cockburn had been working on Crystal, which is a conceptual way to think about agile practice. But Scrum and Extreme Programming were the only processes that had hundreds of deployments on teams and they are the parents of the Agile Manifesto.
Sean Ammirati: 13:53 I just never realized that. I always thought of … I guess just it’s when I became aware of each of those things. I always thought the Agile Manifesto came out and then Scrum became this really helpful wrapper on how to deploy it and how to manage it and how to lead teams through it. I didn’t … That’s fascinating that you guys had actually been doing it for years before that. That’s amazing.
Jeff Sutherland: 14:13 Well the Agile Manifesto is a set of values, it’s not a process. So it’s kind of like object technology. Object technology has inheritance, information hiding, all these things that are concepts. But in order to implement them you have to write in C++ or C# or Java or whatever, you can’t say you’re doing object technology and have it mean anything. I mean in the early days of rolling out object technology we’d go into companies and they’d say, “We’re doing objects.” And we said “Show us your code.” There wasn’t a single object in the code. And when we complained about that they said, “Well, it compiles of the C compiler.”
Sean Ammirati: 15:00 Right.
Jeff Sutherland: 15:01 Most of what is called Agile today won’t even compile.
Sean Ammirati: 15:05 So that’s the thing actually, and that actually is a question I had for you that I wanna get to. ’Cause I do feel like Agile, like I’ve read the “we value this over that” version of the Agile Manifesto, just a short, quick set of statements. And when I read that I was like, okay, I know what they mean by Agile in that sense of the word, but my day job is a venture capitalist and night jobs the teacher at CMU people use agile in both those settings pretty regularly and they mean lots of other things. So I guess I’m curious, how do you feel about the term agile now in 2019?
Jeff Sutherland: 15:48 Well, we’ve known for years now, I work closely with the Standish group where Jim Johnson has been collecting data for 20 or 30 years on over 50000 project sets, each set has eight to 25 projects. So hundreds of thousands of projects. And in recent years he’s been splitting them into agile and traditional. And we know that the agile projects have about twice the success rate. But over half of them are late, over budget, with unhappy customers or are complete failures. So there’s a lot of agile BS out there.
Sean Ammirati: 16:26 Are they self categorizing if these are agile or traditional projects or-
Jeff Sutherland: 16:31 Yeah.
Sean Ammirati: 16:32 Okay. So they’re saying and you’re not doing any kind of first principle evaluation to say if you agree with that assessment or not?
Jeff Sutherland: 16:38 No.
Sean Ammirati: 16:39 Okay.
Jeff Sutherland: 16:40 Well, we have done … As we rolled out Scrum at Scale we have now surveyed many hundreds, many thousands of people all over the world that’s part of the training. The first thing we ask people is to assess in their organization what percent of projects are agile, what percent of them fail or late, and what percent are successful, happy customers, good delivery. And their data is worse than the Standish data. So the Standish data is actually overly optimistic.
Jeff Sutherland: 17:18 Jim Johnson has a group of companies that are more disciplined than the average company. So their numbers are actually better than average. And because of this, what’s happened recently, you know I just said I was working with the air force on how to get the air force agile this past weekend. The military was forced to go agile for defense IT projects, I think it was a 2010 Defense Appropriations bill required every IT project to be agile. So that means that every consultant that’s responding to a request or proposal from the DOD is claiming to be agile. The defense department also set up a board they call the Defense Innovation Board and it has some really well known people, you know the former CEO of Google, many of the great computer scientists that have founded significant companies, and recently they produced a document called Agile BS. And they said one of the problems in the industry is that there’s a lot of nonsense around Agile.
Jeff Sutherland: 18:29 So here is a set of questions that should be asked for any proposal for a contract that comes into the air force. And they’re questions like “can the team deliver working product at the end of every sprint including the first sprint?” If yes, agile, if not it goes into the agile BS bucket and the proposal should be rejected. Can the backlog be updated on a cycle time less than or equal to a month for a defense contract? If not, that goes to the agile BS bucket. And they have about 20 questions like this and what happens is, if you apply those to commercial companies over 50% of the so called agile will go into the BS bucket. So that’s the problem with what’s going on today and my major focus is trying to get … Can we get Scrum implementing well in even a few companies?
Jeff Sutherland: 19:34 So for example, Amazon has 3300 Scrum teams delivering on new feature live more than once a second. That’s a good Scrum implementation. And the effect of that is that any market they go into, they completely disrupt the market. So that shows you what Scrum can do when you’re doing it well. And the problem is how do we get the people that haven’t figured out how to do this yet actually doing it well.
Sean Ammirati: 20:02 And I think some of it is this misunderstanding that people attached it to things that aren’t really agile. As you said, this agile BS bucket. It sounds like there’s 20 of them and I’ll find the article afterwards and link to it in the show notes, but if you were gonna pick one thing that’s like most misunderstood about these, or the sort of most common failure point that you’ve seen in these companies ending up in this agile BS point, what would that be?
Jeff Sutherland: 20:27 Well, you know, in 2011 at the big agile conference every year, almost every one of the original Manifesto authors were there and we had a big session with thousands of people and at the end of the session they asked us, “Is there anything you would change in the Agile Manifesto?”
Sean Ammirati: 20:48 That’s interesting.
Jeff Sutherland: 20:49 And Ron Jeffreys said, “I would put a line on the bottom of the values saying, item number two, working product every sprint, we really mean it.” And if you look for the over 50% of agile projects that are late, over budget, with unhappy customers, the primary reason is that they can’t get anything done at the end of the sprint.
Sean Ammirati: 21:18 That’s right. That’s good. That’s really good. So let’s talk a little bit about Scrum. So you’re … This is obviously one of your key points of focus right is getting Scrum helpfully deployed in these organizations, some organizations look like Amazon versus look like these agile BS examples. Do you think that size of organization impacts how Scrum is rolled out at all? So for example, one of the things that I play with a lot with our startups versus the corporate start ups that I work with, in a large corporation the daily stand up becomes really powerful, in a three person team sometimes it feels more repetitive. I’m just curious are there … Is there anything that you would say should be deployed differently depending on the size of the organization?
Jeff Sutherland: 22:08 Well, a few years ago I helped a two person start up in a online poker market. One was already doing Scrum in a large commercial company, the other one was new to Scrum, he came to my Scrum training. And I said, you know, you guys are gonna be coding like crazy and one of the things that you wanna do is have somebody be worrying about the market and actually selling something. In Scrum we call that the product owner, and the other person should be worrying about fixing stuff that’s broken. That’s the Scrum master’s responsibility. I said if you don’t, if you just try to do that as a committee while you’re coding like crazy, you’re gonna forget something. So these guys ran Scrum for two years, two person Scrum, sold the company, cashed out, and semi-retired. So that’s a really nice execution of Scrum. With two people.
Sean Ammirati: 23:01 And did they do all of it? They still did an every day, it wouldn’t take 15 minutes, but an every day stand up?
Jeff Sutherland: 23:07 Well they were talking to each other every day, they actually found, they actually worked better remotely, but they had … I think they were using Skype at that time, now we do Zoom. They had Skype video on all the time. So they’re working and they’re talking.
Sean Ammirati: 23:27 Right, and so it’s more real time as opposed to an episodic-
Jeff Sutherland: 23:30 More real time. And the important thing is that, you come into, we really like weekly sprints and our best implementations today do weekly sprints.
Sean Ammirati: 23:42 Is that true even in large companies? You recommend a one week sprint?
Jeff Sutherland: 23:46 3M does nothing but weekly sprints.
Sean Ammirati: 23:48 Interesting.
Jeff Sutherland: 23:48 They’re the only really big company that insists everybody do weekly sprints. ’Cause we told them it works better and 3M is actually they’re interested in actually what works better. The other companies all say, oh, well, that takes too long. Well, if you wanna go fast, if you wanna deliver more results, if you wanna deliver higher quality, if you have a more rapid cycle time or a more rapid feedback loop, you’re gonna get better quicker.
Sean Ammirati: 24:17 Yeah, I can picture, and again like I just personally Scrum transformed the startup that I ran 10 years ago, 12 years ago that we ultimately sold to LinkedIn. So I always reference it to people, I don’t consider myself at all an expert in deploying it. But I always reference people should read the book, watch videos, that they can get training, all of that which we should talk about in a minute. But I’m picturing the execs that I talk to about that. If I posed a one week, proposed a one week cycle time at some of the large organizations that I work with, I feel like sprint planning could be a day of the four days if they’re not careful there. And so it feels like there’s … You’ve gotta minimize that overhead if you’re really gonna do weekly sprints I imagine.
Jeff Sutherland: 25:04 You know, if you read the Scrum guide carefully it says the meetings are shortened proportionally. So sprint planning is a maximum time box of eight hours for one month sprint, and that’s the maximum. So a maximum of two hours for a one week sprint. Now my company, Scrum, Inc, runs totally on Scrum and our sprint planning is typically about a half an hour.
Sean Ammirati: 25:26 For a weekly sprint?
Jeff Sutherland: 25:28 Yeah.
Sean Ammirati: 25:28 Okay. So how does that work? You come in Monday morning, you basically do the sprint planning and then hit go? Is it always kinda Monday to Friday?
Jeff Sutherland: 25:36 We used to come in Monday and then people felt that that didn’t work as well. We have some people that tend to work on the weekends, some people not, and there’s kinda this reset on Monday for people who aren’t working on the weekends, so it’s not a great time to kind of really focus. So we’ve moved it to Wednesday. So the way it’s working now, 9:30 on Wednesday morning we have our sprint review. At 10:00 we pull in the stakeholders, the leadership in the company. And each one of our teams owns a value stream and our product owns the revenue. So the stakeholders are really interested in how is it going, but also are you making your numbers. So 10:00, whatever time the leadership of the company needs to review what we’ve done happens, by 10:30 we’re into our retrospective and that lasts less than half an hour, and then we go into sprint planning. So by 11:00 we’re in sprint planning and before lunch we’re done.
Sean Ammirati: 26:41 Wow, that’s great.
Jeff Sutherland: 26:43 And what’s important is, just like this online poker company is that you get a clear focus and reset once a week with a review of what’s happened. So you generate this constant improvement cycle.
Sean Ammirati: 26:57 Yeah, I noticed like, it’s incredible … I mean for the people listening that haven’t tried Scrum, it’s completely transformative. It really is.
Jeff Sutherland: 27:05 One of the problems is I talk in the training, I still do a lot of training. You know, Scrum can be fast, easy, and fun. And I’ll say, okay, who’s got the fast, easy, and Scrum and so we got 30 or 40 people in the room, maybe five people raise their hand. And I say, or Scrum can be slow, hard, and painful. Who’s got that? Then 10 people raise their hand. And I said well we’re gonna go along in the training and specifically identify what makes the difference between fast, easy, and fun and slow, hard, and painful. And there is a very specific set of things. It’s just like playing football, you know, if you don’t have a team that understands the plays, if you don’t have a stable team that you can count on, you’re gonna get hurt.
Sean Ammirati: 27:52 That stable team’s a big one. Switching over to the corporate innovators that I work with. I think that’s a big one. I met with a large software development company a year ago and we were talking about lots of things and then delivery and timeliness and on time, on budget came up. And I said, well are you using Scrum and they said, yeah. And I just asked them two simple questions. Like well what’s your velocity and can I see the burn down charts, and what I realized as we were talking is that they were switching team members completely every sprint. Which made it kinda, there’s a lot of noise in there when you’re doing that.
Jeff Sutherland: 28:28 Right, well you have to boot up a new team every sprint. We worked with a local company here near Boston and they brought me in to train the management, not that … And the management was doing that and I got the management committed. I said, we wanna implement Scrum at scale and that starts with a reference set of teams. So let’s take 10 of your teams and we wanna stabilize the teams and stabilize the back log and I need a management commitment that you won’t mess with the teams and you won’t mess with the product owner. And they agreed. Right out of the gate, the team with a velocity of 10 goes to 60 in the next sprint.
Sean Ammirati: 29:08 That’s right. It’s incredible.
Jeff Sutherland: 29:10 It’s incredible that management doesn’t understand these work dynamics. So how do these guys get promoted when they don’t understand basically how work works and how teams function? It’s mind boggling.
Sean Ammirati: 29:25 That’s another episode, Jeff. But I couldn’t agree more. So I do wanna, before we wrap this I do wanna make sure to give you a change to explain a little bit about Scrum, Inc because it could be a helpful resource for a lot of the people that listen. So talk a little bit about that quickly.
Jeff Sutherland: 29:40 Okay, well I went through actually 11 technology companies where I was the CTO, sometimes the CEO or the President, implementing prototypes of Scrum and then implementing real Scrum, but in 2006 I was doing some consulting with a venture capital group and they said, look Jeff, we wanna implement the way you talk about Scrum in our companies everywhere. We wanna run the VC group by Scrum, we want every company implementing Scrum. And implementing is across the whole company. Not just in engineering. And they said, and we don’t want you’re working for another company right now in the health care space, we don’t wanna tell our companies that we got this guy outta health care. You should start your own company, we will incubate it in our venture group. And that will be the basis of consulting to all our investments. So that became Scrum, Inc.
Sean Ammirati: 30:33 And that was open view, correct?
Jeff Sutherland: 30:35 Open View Venture Partners, yep. They had their fourth fund … They have four or five funds, each couple hundred million. Fund four, last year, their goal is to double return on investment using Scrum compared to other VCs. Round four last year, started the year worth about $200 million and by the end of the year it was worth 400 million.
Sean Ammirati: 30:57 It was a good year too for venture. But that’s impressive nonetheless.
Jeff Sutherland: 31:03 They’re doing more than the average VC. I mean this is across the whole portfolio. This is the average across many, many companies.
Sean Ammirati: 31:11 But today Scrum, Inc worked with non Open View portfolio companies as well, correct?
Jeff Sutherland: 31:16 Yes. So I started up Scrum, Inc. initially it was located … I was actually still the CTO of Patient Keeper, the health care company and about after a year or so of that the Scrum business grew so big I decided to just focus totally on Scrum. And then start building out Scrum, Inc. so today we have about 30 really good consultant trainers, we do training all over the world, plus probably an equally number of third party partners, plus a joint venture in Japan right now, Scrum, Inc Japan, which is probably bigger than Scrum, Inc United States at the moment. And a joint venture with half ownership with the Scrum Alliance for Scrum at scale and additional joint ventures we’re working on in other companies.
Sean Ammirati: 32:08 What is Scrum at scale mean? What does that mean?
Jeff Sutherland: 32:11 Okay, well a few years ago we were working with the biggest Scrum implementation, like Amazon has over 3000 teams, SAP has over 2000 teams working on SAP, Intel is, we can’t get really good numbers but we know just one division has 500 teams, so Intel is one of the biggest. Well these people started coming to me and said, Jeff, you need to write down how to scale Scrum because we got these scaling frameworks coming out, and particularly the guys at Intel said, nothing scales unless it’s fractal in nature. Every component has the same API as every other component and it needs to scale like the internet. And these scaling frameworks, many of them don’t scale. And at the same time the Scrum Alliance came to me and said, Jeff, we have partnerships with a couple of the scaling frameworks, but they’re IT frameworks and they’re not organizational frameworks like we use in Open View for our companies. We would like to participate in the development of a framework that’s directed towards improving organizational performance, business agility.
Jeff Sutherland: 33:32 And so we said, okay, maybe we can do that. It took the lawyers about a year of debating and we finally put a joint venture together that closed this past April. And that scaling framework is called Scrum At Scale. And the distinguishing factor is, first of all it’s fractal, there is no additional bureaucracy, there is nothing but Scrum teams, it’s the way our venture group trains our investments to run an organizational Scrum. And the goal is you should get the same level of performance per team no matter how many teams you have.
Sean Ammirati: 34:13 Interesting.
Jeff Sutherland: 34:14 And there’s a division of Intel with 500 teams that is going 18 times faster than when they started about 10 years ago. So that’s the kind of performance we want.
Sean Ammirati: 34:25 And if people wanna learn about that, the Scrumatscale.com that’s the right place for them to learn more about that?
Jeff Sutherland: 34:29 Yeah. They can learn all about that-
Sean Ammirati: 34:31 I’ll include that in the show notes as well as the agile BS thing. I have, for whatever reason, missed this completely, this is really interesting.
Jeff Sutherland: 34:38 Another aspect of Scrum At Scale that makes it really different is the Scrum Alliance says we want it open source just like Scrum. So it is, it’s open source, anybody can use it and people can participate in its development and help evolve the guide. So that’s very different. ’Cause none of the frameworks are proprietary, right?
Sean Ammirati: 35:01 This is really interesting, I will include a link to this in the show notes, for sure. I don’t know how I’ve missed this. This is very interesting. Cool.
Sean Ammirati: 35:09 Well Jeff, I think I promised you 30 minutes and we’re 35 minutes in. But let me just finish with one last question and then we’ll wrap this up. So you’ve had a pretty remarkable career from fighter pilot to professor to this sort of pioneer of Agile in so many ways and changing how organizations work and make products. I’m curious for students who are maybe early in their career, what would you encourage them to think about as they step through and kind of navigate their own career?
Jeff Sutherland: 35:37 Well, today I think over 50% of millennials want their own company, right? So they oughta figure out in school what domain is an area that really interests them and then they might wanna get some experience before they launch their own company, but they should have that as their objective. And agility and particular Scrum as a specific tool to generate agility, that should become part of their DNA. They should know how to do that in their sleep. Because what happens is you start up your own company and initially it’s small and everybody’s doing everything and maybe it’s working great. But as soon as your company actually is successful and you start to scale, if you don’t have Scrum, then you’ve got a mess.
Sean Ammirati: 36:30 That’s right.
Jeff Sutherland: 36:31 Whereas if you have Scrum already in the DNA, and that could be with two people, as I pointed out, then you have a mechanism which will grow to the size of Intel. So I do some consulting and I give talks at the university, recently BU, Boston University gave me an award and I came and talked to their project management group. And they’re teaching Agility there and they’re interested but they’re still teaching a lot of traditional project management. Which doesn’t really work, so I would advise young people to stay away from that.
Sean Ammirati: 37:06 You’re making me feel good. I make all my students read the Scrum book, so you’re preaching to the choir here.
Jeff Sutherland: 37:12 Well the problem is, you know it was a famous Dutch computer scientist, I think Dijkstra is the way you pronounce his name. He said, you know, if you learn a language like FORTRAN first your brain will be permanently impaired. The same is true if you learn project management-
Sean Ammirati: 37:30 If you learned Waterfall as your first-
Jeff Sutherland: 37:32 Yeah, it takes 20 years to kinda require your brain back to normal after you learn Waterfall.
Sean Ammirati: 37:39 You gotta unlearn Waterfall for 20 years. That’s good. That’s really good. Well Jeff, this has been amazing. As I said at the beginning, it’s a real honor to talk to you today and thanks for making the time. I’ll include notes to both Jeff’s company as well as the Agile BS and the Scrum At Scale stuff if people are interested in learning more. But thanks again for the time today Jeff.
Jeff Sutherland: 38:00 Well thank you, I enjoyed it.
Sean Ammirati: 38:11 I hope you enjoyed this episode of Agile Giants. If so, consider sharing it with a friend, and if you think it’s worth five stars, which I hope you do, please go to iTunes and rate it so that others can find this content as well.
