Nov 6, 2021
Bio Dr. Jeff Sutherland is the inventor and co-creator of Scrum, the most widely used Agile framework across the globe. Originally used for software development, Jeff has also pioneered the application of the framework to multiple industries and disciplines. Today, Scrum is applied to solve complex projects in start-ups and Fortune 100 companies. Scrum companies consistently respond to market demand, to get results and drive performance at speeds they never thought possible. Jeff is committed to developing the Agile leadership practices that allow Scrum to scale across an enterprise.
Dr. Sutherland is the chairman and founder of Scrum Inc. He is a signatory of the Agile manifesto and coauthor of the Scrum Guide and the creator Scrum@Scale. Jeff continues to teach, create new curriculum in the Agile Education Program and share best practices with organizations around the globe. He is the founder of Scrum Inc. and coauthor of, Scrum: The Art of Doing Twice the Work in Half the Time, that has sold over 100,000 copies worldwide.
Ula Ojiaku: Hello everyone, my guest today is Dr Jeff Sutherland. He is the inventor and co-creator of Scrum, the most widely used Agile Framework across the globe. Originally used for Software Development, Jeff has also pioneered the application of the framework to multiple industries and disciplines.
Today, Scrum is applied to deliver complex projects in startups and Fortune 100 companies.
Dr Jeff Sutherland is the Chairman and Founder of Scrum Inc. He is a signatory of the Agile Manifesto and co-author of the Scrum Guide and the creator of Scrum at Scale.
Jeff continues to teach, create new curriculum in the Agile education programme and share best practices with organisations around the globe.
He has authored and co-authored a number of books which include Scrum: The Art of Doing Twice the Work in Half the Time – which has sold over 100,000 copies worldwide.
In this episode, Dr Sutherland shares the backstory of how he and Ken Schwaber developed the Scrum framework. I was pleasantly surprised and proud to learn that one of the inspirations behind the current Scrum framework we now have was the work of Prof Babatunde Ogunnike, given my Nigerian heritage.
Dr Sutherland also talked about the importance of Agile Leadership and his current focus on helping organisations fix bad Scrum implementations.
I’m sure you’ll uncover some useful nuggets in this episode. Without further ado, ladies and gentlemen, my conversation with Dr Sutherland.
Thank you, Dr. Sutherland, for joining us on the Agile Innovation Leaders podcast. It's a great pleasure to have you here.
Glad to be here. Looking forward to it.
Fantastic. So could you tell us about yourself?
Well, I grew up in a small town in Massachusetts. And I always felt that I would go to West Point of the United States Military Academy, even at a very young age. And I finally made it there. I spent four years there.
And I went on to a program where a certain number of cadets could join the Air Force. And I told the Air Force, if they made me a fighter pilot, I would move into the Air Force, which I did. I spent 11 years as a fighter pilot in the Air Force.
And most of the operational aspects of Scrum actually come from that training. My last tour in the Air Force was actually at the US Air Force Academy, I was a professor of mathematics.
And I had gone to Stanford University in preparation for that position. And I had worked closely with the, at the time he was Head of the Department of Psychiatry, became the Dean of Stanford who had studied under my father-in-law, he had become an MD under my father-in-law, who was a brilliant physician. And I was working on research papers with him, both at Stanford and at the Air Force Academy. And I asked him for guidance.
And I said, I'm thinking about, given all the work we've done in the medical area. Starting in Stanford, I'm thinking maybe becoming a doctor - become an MD. And he strongly recommended against that he said, ‘you'll just go backwards in your career, what you need to do is you build on everything you've done so far. And what you have is your fighter pilot experience, your experience as a statistician, and a mathematician, you want to build on that.’
So, I had already started into a doctoral program at the University of Colorado School of Medicine, which was not far from the Air Force Academy. And so, I talked to my department Chairman there who offered me a position in the department running a large research grant, funded by the National Cancer Institute and so, I decided to exit the Airforce and join the medical school.
While I was finishing up my doctoral degree. And as soon as my doctorate was finished, I became a professor of Radiology, preventive medicine and biometrics. I was a joint across multiple departments. And I was doing mathematical research on modeling, particularly the human cell on a supercomputer, (to) determine what caused cancer. And to do that required extensive mathematical research as well as the medical research. But at the end of the day, what we found was for any complex adaptive system, like a human cell, or a person or a team, they go through different states. And they're moved from one state to the next by some kind of intervention.
And so, if you understand what causes those changes… turned out in the case of cancer, there were four different states that led to a tumor. And in every state, there were certain interventions, and if you knew what they were, you could prevent them and prevent cancer. Or you could even, to my surprise, take a cancer cell and make it go backward into a normal cell.
So, this fundamental understanding is the theory behind Scrum.
So, while I'm doing this all at the medical school, a large banking company came by and said, ‘you know, over the medical school, you guys have all the knowledge about the technologies; the new technology, we're using (for) banking, you're using for research.’
And they said, ‘you guys have all the knowledge but we have all the money and they made me an offer to come join the bank’ [Laughs].
[Laughs]You couldn’t refuse
Not just me, it was my family. So, I wind up as Vice President for Advanced Systems, which was effectively was the CTO for 150 banks that we were running across North America.
Each was, you know, a dozen, 50, 100 branches. And of course, we were mainly doing the software, installation and support to run the banking operation, which is largely computer stuff – (this) is what banks run off.
And as we're building these systems with hundreds and hundreds of developers, one of the first things I noticed is that all the projects were late. And I look at what they're doing. And they're using this process where they spend, you know, six months defining requirements, and then they put all the requirements into a Gantt chart.
And then they, they plan on taking six months to build something, but it's never done. Because as soon as they start testing that they find there's all kinds of things that are broken. So, virtually every single project of the bank is late.
So, as a head of technology, one day I walked into the CEO’s office and I said, ‘Ron, have you noticed all your projects are late?’ He said, ‘Yes’. He says, ‘Every morning at least five CIOs or CEOs of the banks, they call me up.’ And he says, ‘they scream at me.’ I said, ‘wow’, I said, ‘You know, it's going to get worse, not better. Because these guys are using this, these Gantt Charts.’
And I showed him one. And then being a mathematician, I mathematically proved that every project would be late at the bank. And he was stunned. And he said, ‘what should I do?’ I said, ‘we need a completely different operating system in the bank.’ This is back in 1983. ‘Let's take one business unit. Let's take the one that's losing the most money, okay, the worst business unit’
They have nothing to lose then.
And it was the automated teller division that was rolling out cash machines all over North America. It was a new technology and they had a ton of problems.
So, I said, ‘let's take that unit and every one, sales, market, support, installation, we're going to split them down into small teams. And we're going to have Product Marketing come in on Monday with a backlog prioritized by business value. And at the end of the week, on Friday, we're going to deploy to 150 banks.’
‘And I'm going to train them how to land a project every week, just like I trained fighter pilots to land aircraft. I'm going to give them a burndown chart, we're going to throw away the Gantt Chart, I'm going to give them a burndown chart to show them how to land the project.’
So, he said, ‘Well, that's gonna be a big headache.’ I said, ‘look, the bank needs to be fixed.’ He said, ‘Okay, you got it.’ So, I took that unit. I told them, ‘I know it's gonna take several weeks,’ today we call them sprints, ‘for you to be successful.’ Because as new pilots, trained to land, these high-performance jets, they tend to come in high and then they have to come around and try to land again, they over and over, they practice until they can nail it.
And it took them six weeks, six sprints to actually nail the end of the week (and) deploy (to) 150 banks. But within six months, it became… it went from the worst business unit in the bank to the most profitable business unit in the bank. And the senior management said, ‘you know, Jeff, here's another 20 million dollars to throw at whatever that thing you're doing [chuckles] it's the most profitable thing in the bank, we're gonna put more money in that [Laughs]. So that was the first prototype of what we call today Scrum at Scale.
Now, I've been CTO of 11, or CTO or CEO of 11 different companies. And for the next 10 years, I prototyped that model and advanced technology teams until in 1993, at a company called Easel Corporation, we found that because of the tooling we were building and selling to customers, we needed to build the tool with what today we call Agile Practice.
And we need to train the customer to use the tool by having teams do an agile practice. So, in order to train our customers properly in 1993, we actually had to formalize what I've been prototyping for 10 years.
And we wrote it down and at the time we were reading this paper, we're going through 1000 papers in the journals I, you know, I had done many new technology. And, in every one of them, you have to read everything that's ever been done so that you can go beyond. You can use everything that's been done, but then you go beyond, okay?
So, it's a tremendous amount of research to launch new technology. And at about the 300th paper in our file, it was a paper out of the Harvard Business Review, which really surprised me, by two Japanese Business School professors, Professors Takeuchi and Nonaka.
And in there, they described the best teams in the world. They were lean hardware teams that reminded them of a game of rugby, they said, ‘we're going to call what they're doing Scrum Project Management.’ So, I said to the team, ‘we need a name for this thing that we're going to train our customers in, and let's call it Scrum.’ And off we went.
So, for the next two years, we were actually using Scrum within Easel deploying products. But it was not public, to the general industry. And Easel got acquired by a larger company. And at that time, I felt that this needed to be rolled out into the industry because we had benchmarked it with the best tooling in the world from the leading productivity company, and showed that it was… that (it) went 10 times faster [chuckles]. The quality was 10 times better, which is what you need for a new technology innovation. And so, I felt it was ready to go to the industry as a whole.
So, I called up an old friend, Ken Schwaber. And he was a CEO of a traditional Project Management software company, a waterfall (methodology). He sold these methodologies with 303 ring binders, a software package that would make Gantt Charts [chuckles]. So, I said, ‘Ken, I want you to come up and see the Scrum, because it actually works and that stuff you're selling doesn't work – it makes projects late.’ And he agreed to come in, he actually came up, he met with me.
He stayed for two weeks inside the company, working, observing the Scrum team. And at the end of those two weeks, he said, ‘Jeff, you're right. This really works - it's pretty much the way I run my company.’ He said, ‘if I ran my company with a Gantt Chart, we would have been bankrupt a long time ago.’ So, I said, ‘well, why don't you sell something to work that works instead of inflicting more damage on the industry?’
So, he said so we said ‘okay, how (do) we do it?’ I said, ‘it needs to be open source, it needs to be free.’ Ken felt we needed to take the engineering practices, many of which appear today in extreme programming…
…and let Kent Beck (creator of eXtreme Programming, XP) run with them because Kent had been sending me emails, ‘Jeff, send me every...’, he had been following the development of Scrum, ‘…send me everything on Scrum, I’m building a new process. I want to use anything that you've done before and not try to reinvent anything.’
So, he (Ken Schwaber) said, ‘let Kent take the engineering practices, we’ll focus on the team process itself.’ And we agreed to write the first paper on this to present at a big conference later that year. And writing that paper was quite interesting. Ken visited DuPont Chemical Corporation, the leading Chemical Process Engineers there that they had hired out of academia to stop chemical plants from blowing up.
And when Ken met with them, they said, describe what we were doing in the software domain. They said, ‘you know, well, that process that traditional project management is a Predictive Process Control System. We have that in the chemical industry.’
‘But it's only useful if the variation in the process running is less than 4%.’ They said, ‘do you have less than 4% change in requirements while you're building software?’ Ken says, ‘no, of course not! It's over 50%!’ And they started laughing at him. They said, ‘your project’s going to be exploding all over the place.’
‘Because every chemical plant that has blown up has been somebody applying a predictive control system to a system that has high variability. You need to completely retrain industry to use Empirical Process Control, which will stop your projects from blowing up.
And they said, here it is, here's the book, they had the standard reference book for Chemical Process Engineering. And in there, there's a chapter on Empirical Process Control, which is based on transparency, inspection, and adapting to what's happening in real time. Okay, so those are the three pillars of Scrum that are today at the base of the Scrum guide.
Do you still remember the title of the book that the chemical engineers recommended to Mr. Schwaber by any chance?
Yeah, so I have a, when I do training, I have a slide that has a picture of the book (Process Dynamics, Modelling and Control).
It's written by Ogunnaike and Ray. But that is the root of the change that's gone on in the industry. And so then from 1995, forward, Ken and I started working together, I was still CTO of companies. And I would get him to come in as a consultant and work with me. And we'd implement and enhance the Scrum implementations in company after company after company.
Until 2001, of course, Scrum was expanding but Extreme Programming in 2001, was actually the most widely deployed. They were only two widely-deployed agile processes at the time of Scrum and Extreme Programming. Extreme Programming was the biggest.
And so, the Agile Manifesto meeting was convened. And it had 17 people there, but three of them were Scrum guys - that had started up Scrum, implemented it in companies, four of them were the founders of Extreme Programming. And the other 10 were experts who have written books on adaptive software development or, you know, lightweight processes, so, industry experts.
And we, we talked for a day and everybody explained what they were doing and there was a lot of arguments and debate. And at the end of the day, we agreed because of this book, Agile Competitors, a book about 100 hardware companies - lean hardware companies, that have taken Lean to the next level, by involving the customer in the creation of the product.
And we said, ‘we think that we all need to run under one umbrella. And we should call that Agile.’
So, did you actually use the word umbrella in your (statement)? Oh, okay.
Often, people use that right?
Because at the time, we had Agile and Extreme Programming, and now everybody's trying to come up with their own flavor, right? All under the same umbrella of ‘Agile’. And that caused the both Scrum and Extreme Programming started to expand even more, and then other kinds of processes also. But Scrum rapidly began to take dominant market share, Scrum today is about 80% of what people call Agile.
The reason being, number one, it was a technology that was invented and created to be 10 times better. So, it was a traditional new technology developed based on massive amounts of research. So, it worked.
But number two, it also scaled it worked very well for many teams. I mean, there are many companies today like Amazon that have thousands of Scrum teams. And Extreme Programming was really more towards one team.
And (reason number) three, you could distribute it across the world. So, some of the highest performing teams are actually dozens of teams or hundreds across multiple continents.
And because of those three characteristics, it's (Scrum has) dominated the market. So that brings us to in 2006, I was asked by a Venture Capital firm to help them implement Scrum in their companies, they felt that Scrum was a strategic advantage for investment. And not only that, they figured out that it should be implemented everywhere they implemented it within the venture group, everybody doing Scrum.
And their goal was to double their return on investment compared to any other venture capital firm. They pretty much have done that by using Scrum, but then they said, ‘Jeff, you know, we're hiring you as a consultant into our companies. And you're a CTO of a healthcare company right now. And we don't want to build a healthcare company, we want to build a Scrum company.’
‘So, why don't you create Scrum Inc. right here in the venture group? We’ll support it, we'll do the administrative support. We'll write you a check - whatever you want.’ So, I said, ‘well, I'm not going to take any money because I don't need it [chuckles].
I understand how that works. If the venture capital firm owns your company, then (in the) long term, you're essentially their slave for several years. So, I'm not taking any money. But I will create the company within the venture group. If you provide the administrative support, I'll give you 10% of the revenue and you can do all the finances and all that kind of stuff.
So, that's the way Scrum Inc. was started to enable an investment firm to launch or support or invest in many dozens of Scrum companies.
And today, we're on the sixth round of investment at OpenView Venture Partners, which was the company the six round is 525 million. There's a spin out from OpenView that I'm working with, that has around this year, 25 million.
And over the years, just co-investing with the venture group I have my own investment fund of 50 million. So, we have $570 million, right this year 2021 that we're putting into Scrum companies. Agile companies, preferably Scrum.
Now when you say Scrum companies is it that they facilitate the (Scrum) training and offer consulting services in Scrum or is it that those companies operate and you know, do what they do by adopting Scrum processes?
Today, Scrum Inc sometimes help some of those companies, but in general, those companies are independently implementing Scrum in their organizations.
And okay, some of them may come to Scrum training, maybe not. But since Scrum is so widely deployed in the industry, Scrum Inc, is only one of 1000 companies doing Scrum training and that sort of stuff.
So, they have a wide variety, wide area of where they can get training and also many of the startups, they already know Scrum before they started the company. They are already Agile. So, what we're interested in is to find the company that understands Agile and has the right team players, particularly at the executive level, to actually execute on it.
No matter what the product or services (are)…
Products or services, a lot of them are software tooling companies, but some of them are way beyond that, right? So, turns out that during COVID… COVID was a watershed. The companies that were not agile, they either went bankrupt, or they were crippled. That meant all the Agile companies that could really do this, started grabbing all the market share.
And so, many of our companies, their stock price was headed for the moon during COVID [laughs]. While the non-agile companies were flatlined, or are going out of business, and so the year of COVID was the best business year in the history of venture capital because of Agility.
So, as a result, I'm spending half my time really working, investing in companies, and half of my time, working with Scrum (Inc.) and supporting them, helping them move forward.
That's a very impressive resume and career story really Dr. Sutherland. I have a few questions: as you were speaking, you’ve called Scrum in this conversation, a process, a tooling, the technology.
And you know, so for some hardcore Agilists, some people will say, you know, Agile is all about the mindset for you, what would you say that Scrum is it all of these things you've called it or would it be, you know, or it’s something (else)...?
So, certainly the (Agile) mindset is important. But from an investment point of view, if the organization can't deliver real value, quickly, agile is just a bunch of nonsense. And we have a huge amount of nonsense out there.
In fact, the Standish group has been publishing for decades. 58% of Agile teams are late over budget with unhappy customers. So, when you get these hardcore Agilist, that are talking about mindset, you have to figure out ‘are they in the 42% that actually can do it or are they in the 58% that are crippled?’
My major work with Scrum Inc. today is to try to get to fix the bad Scrum out there. That is the biggest problem in the Agile community. People picking up pieces of things, people picking up ideas, and then putting together and then it doesn't work (laugh). That is going to that's going to be really bad for agile in the future. If 58% of it continues not to work.
So, what we found, I mean, it was really interesting. Several years ago, the senior executive (of) one of the biggest Japanese companies flew to Boston wanted meet with me. And he said to me, ‘the training is not working in Japan for Scrum.’
He said, ‘I spent 10 years with Google, in Silicon Valley. So, I know what it looks like what actually works. And I can tell you, it's not working in Japan, because the training is… it's not the training of the Scrum that is high performing. And in fact, our company is 20% owned by Toyota, and we are going to be the trainers of Toyota.
And we cannot deliver the training that's currently being given to Toyota, it will not work, it will not fly. And we want to create a company called Scrum Inc. Japan. And we're a multibillion-dollar company, we're ready to invest whatever it takes to make that happen.’
To give them the kind of training that will produce the teams that Takeuchi and Nonaka were writing about in the first paper on Scrum. And as we work with them to figure out what needs to be in that training, we found that the Scrum Guide was only 25% of the training. Another 25% was basic Lean concepts and tooling, right?
Because the original Scrum paper was all about Lean hardware companies. So Lean is fundamental to Scrum. If you don't understand it, you can't do it.
And then third, there are certain patterns of performance that we've developed over the years, we spent 10 years writing a book on patterns - Scrum patterns. And there's about a dozen of those patterns that have to be implemented to get a high performing team.
And finally, scaling to multiple teams. It turns out, right about this time I started working with the Japanese, I was at a conference with the Agile Leadership from Intel. And they told me that they'd introduced Scaling Frameworks into Intel division, some of which had more than 500 Scrum teams in the divisions and the Scaling Frameworks had slowed them down.
And it made the senior executives furious and they threw them all out and they said, we did not want to hear the word Scrum at Intel anymore. But you guys need to go twice as fast as you're going now.
So, they came to me, they said, ‘we're desperate. We have to go twice as fast. We can't even use the word “Scrum”. What should we do?’ And they blamed me, they said, ‘Sutherland you're responsible [Laugh] you caused problem, you need to fix it.’ So, I started writing down how to do what today we call Scrum at Scale.
And everybody, you know, most of those people in the industry were implementing IT scaling frameworks. They were all upset. ‘Why are you writing down another framework?’ Well, it's because those IT frameworks do not enable the organization to show Business Agility, and win in the market. And in the best companies in the world, they're being thrown out.
So, I've had to write down how do you add, how do you go to hundreds and thousands of Scrum teams - and never slow down as you're adding more and more teams. You know, every team you add is as fast as the first team when you start. Yeah, that's what Scrum at Scale is all about.
So, there's two primary things that I'm focused on today. One is to fix all this bad Scrum. Second is to fix the scaling problem.
Because it turns out that if you look at the latest surveys from Forbes magazine, and the Scrum Alliance on successful Agile transformations - I learned recently, that almost every company in the world of any significance is going through an Agile transformation or continuing transformation they’d already started years ago. And 53% of them do not meet management expectations.
And the MIT Sloan Business Review did an analysis of what happens if an agile transformation fails, and 67% of those companies go out of business. So, this is becoming really serious, right? To be successful today, if you're competing in any significant way, you have to be agile.
And number two, if you try to be agile and fail, you have a 67% chance going out of business. And the failure rate is 53%. So, this is the problem that we're wrestling with. And half of that 53% failure is due to the bad Scrum we talked about, but the other half is due because of the leadership not being Agile.
I was just going to say, as you said something about the leadership not being agile.
In my experience, you know, as an agile coach in some organizations whilst the teams would embrace you know, Scrum and embrace Agility - the practices and the processes and everything. There's a limit to, you know, how much they can get done…
…if the leadership are not on board. So…
Jeff Sutherland: …you hit this glass ceiling. So, I've been, you know, giving presentations on Agile Transformations around the world. And I can remember multiple times I've had 300 people in the room, say, and I say okay, ‘How many of you are agile, in Agile transformations or continuing the ones you’d started?’ Of course, everybody raises their hand. ‘How many of you have waterfall traditional management that expects you to deliver all the old (laugh) Gantt Chart reports that we always got, and don't understand what you're doing?’
There's 300 people in the room and 297 people raised their hand. I said, ‘you need to give your leadership the book by Professor Kotter called Accelerate.’ Professor Kotter is one of the leading change experts of the world.
And he also, yeah, He also wrote ‘Leading Change’ as well - the book, yes.
And in that book, he says, if the leadership of the Agile part of the organization is traditional in their mindset and requirements, the Agile Transformation will eventually fail 100% of the time.
Those are sobering statistics in terms of, you know, the failure rate and how much of you know the success hinges on business agility and the leadership being agile as well and taking the time to know and care what it means. Yeah.
And what's happening is that the Agile Leadership today, if you look at some of the companies that have been most successful during COVID, one of them is John Deere Corporation, the biggest farm equipment manufacturer in the world, probably the oldest.
Their stock price went up more than Amazon during COVID. And the board of directors gave their Agile Leadership, the Agile Coaches, Scrum Masters, the highest award in the Corporation for producing that result. So that's another reason I'm trying to communicate to Agile people.
The success and survival of your company depends on you. You think your management's going to save you but no, if they are old-style people, they are going to run that company out of business. And you need to either save it before it goes out of business or run to another company before bad things happen.
It’s impressive that, you know, John Deere being a farm equipment manufacturer… I think they were ahead of the curve you know, (compared to some of their contemporaries in that industry as well) and embraced agile ways of working.
Do you know how their Agile Leadership were able to quantify their contributions to the company?
John Deere started to get Agile more than 10 years ago. So, they've been at it a long time.
But in recent years, they really started to build… build internally… Agile leadership, you know, based on my work and they started applying that across the company. I mean, the major focus has not been software actually – it’s been in other parts of the company.
What has to happen to run a company that's building tractors? [chuckles]. Well, there's all kinds of things that have to happen, you know - purchasing, there’s legal [Laugh], there's acquiring all the pieces, it's putting them together at the assembly line, you know, software is a piece of it.
You know, that's probably the easiest piece to fix with Agile, it's the rest of the company that's the challenge. They have started doing that really well which is reflected in their stock price.
Amazing. So, you said something about you know, you're out to fix a couple of things, the problem with bad Scrum out there. And, you know, the problem with scaling agile.
So, with respect to the first one, the point about bad Scrum, what in your experience would be the root cause of bad Scrum implementations in organizations?
There’re about 11 things, that if you fix them, the team will go twice as fast. And it’s multiplicative.
So, you know, we have extensive data on, you know, really big companies. What's the difference between the fastest team and the slowest teams? The fastest teams are 2000 times faster than the slowest teams. So why is that?
Well, first, the team has to be small. The optimal team size is four or five people. If you have a 10-person team, that's going to take at least 50% longer to get anything done. If you go out, look at the team size, you'll see companies have even not only ten-people teams, they have 15 people in a team, 25 people in a team, okay? Those teams are never gonna meet Agile performance.
Second, the backlog needs to be really ready in a sense of small, it's clearly understood, it's properly prioritized. So, you need somebody managing that backlog that can get it right, because we have extensive data for multiple case studies showing the team's production doubles immediately.
As soon as you get that backlog right. So you go into many companies, you'll see, there's still arguing about what's the top priority, right? Or everything's top priority. That's just gonna create a massive mess.
Third, teams are constantly interrupted. You know, the only teams I know that aren’t interrupted are people… these teams and defense contractors working on top secret stuff. And they work in a locked room, [Laughs] the door, it says ‘no managers can enter’, [Laugh] and they don't get interrupted.
But for the rest of us, there's always somebody coming in wanting something else done. And there's a way to manage that using a pattern we call the interrupt buffer. And if you don't have that pattern implemented properly, you're gonna go half as fast. If you're lucky, you might go half as fast.
And what do you say the Scrum Master has a part to play in making sure the interrupt buffer is there and it's enforced?
The scrum master needs to set this all up. Fifth, in high performing teams, we see this pattern called swarming, where multiple people are working on a story together. That increases the process efficiency, which doubles the performance of the team.
So, if people are specialists working independently, that team is going to be really slow. So I’m up to number five, there are six more things, but you probably want to go through them.
It’s very clear, what makes agile teams suck, we know exactly why. And it needs to be fixed. So, I appeal to anyone listening to this help [Laugh] fix bad agile, it's hurting us all.
Thank you for sharing that. Would this be in any of any of your books or in any of your articles that you've written?
Yeah, it's everywhere and (in) everything I've written, but the best summary, it's the red book Scrum …
Scrum, The Art of Doing Twice the Work and Half the Time
And we've had people pick, pick this up. A CEO in Kenya came to New York to one of my courses, he said, ‘Jeff, I just read your book. And I'm CEO with three new energy startups in Kenya. And my teams implemented that, and they're going… they're doing three times the work and a third of the time. So, your book is too conservative.’ He says to me, this guy, he only read the book, he had no training.
So, this book is enough to really get off on the right foot. And if you're having problems, it's enough to fix things. In fact, recently before COVID when we could get everybody together, we had an Apple employee in the class and she said, Jeff, do you know why Apple always meet its states? I said, no, you know, Apple is really secretive. They don't tell anybody anything. She says ‘it's because they do Scrum by the book.’
So, I said, ‘What book?’ She says, ‘The Red Book - Scrum, The Art of Doing Twice the Work and Half the Time - they do it exactly by the book.’
So, again, my message to the Agilists out there: Apple is winning. They are the most valuable company in the world. And it's because they do Scrum exactly by that book. So, you probably should read it.
Definitely. So going by the book, would you say there's any wriggle room for adapting to one's context, or is it about you know, going, ‘check- we've done page 123…’
Well, the whole thing about adapting is fundamental to Scrum. So, one of the things I'm constantly doing in my talks, training, is I'm going back to before Scrum and reading a paper from the leading researchers on complex adaptive systems, in which they mathematically proved, you model things on the computer, that systems evolve more quickly, if they have more degrees of freedom, up until you hit a boundary where the system goes into a chaotic state.
So, from the very beginning in Scrum, maximizing the freedom and the decision capability of the team has been fundamental. And we talked about this as self-organization.
Now, unfortunately, that term has been so misused, misunderstood that we had to take self-organization out of the Scrum guide. And what we inserted was self-managing. And we put next to it goals, okay, the theme is self-managing to achieve a goal. And to make that happen, they need a commitment to do that.
And so, this is one of the fundamental things for Agile teams that work that they have that self-managing commitment to achieve a goal. And the teams that are not working, they're fuzzy about that, right.
So, we want the maximum degree of adaptation, the thing that they don't want to change is the basic structure that's in the red book, if they change that, it has the control mechanisms to allow the maximum degree of self-organization - not to go off the rails.
So, we see a lot of Agilists, ‘oh, you know, let's just tweak the framework this way or that way.’ And then the self-organization takes a team off the rails, and then they fall into that 58% that can't deliver, they're late, they're over budget, the customers aren't happy. And so, this is the really one of the hardest things to communicate to people.
There’re certain things that you absolutely have to be disciplined about. You have to be more disciplined to get a great Agile team than in all ways of working. And that discipline is what allows the maximum degree of self-organization and self-determination, [Laugh] right?
So, understanding those two things together, you know, it makes it makes people's brain explode, [Laugh] right? It's hard.
But it works.
But it works right. [Laugh]
You've already mentioned a lot of books in the course of this interview session, and these would be in the show notes.
So, would there be anything any final word of advice you'd have for the leaders that would be listening to this podcast in terms of their transformation journey?
So, one of the things we did to Scrum at Scale is that the difference between that and most of the other scaling frameworks is that it's all about the leadership. So, we need an operating leadership team, that is a Scrum team that needs a Scrum Master, a Product Owner, backlog.
And its objective is to improve the Agile implementation of the organization. On the prioritization side, we need a leadership team that, led by a Chief Product Owner, that is prioritizing backlog across the organization.
So, you know, I've had the Chief Product Owner of Hewlett Packard in my course, he had a $200 billion portfolio. He learned from that class. Says this class is pretty good.’ He said, ‘In just one slide I figured out how to get $20 billion more a year with no additional resources’ [Laugh]. Just by understanding how to work the framework right? At the $200 billion level.
And you're talking about the Scrum at Scale course, right?
No, this was a product owner course. Product Owner course. He came to it. We're now doing a Scrum at Scale… we’re actually doing a Chief Product Owner course.
So, a Product Owners at Scale course which it has been really well received by the leading Agile Practitioners. (They) really like that because they need to work more in the large than in the small often.
Definitely. That means this available on the Scrum Inc site?
So, one of the things I would recommend I would really recommend is the Scrum Field Book. It’s a bunch of case studies for organizations, large and small, that have tried to take the whole organization to Scrum.
Well, thank you so much, Dr. Sutherland - it's been a great pleasure having you and hopefully we could have a you know, follow up conversation sometime.
Yes. Thanks for inviting me and glad to do it again.
That’s all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com. Also share with friends and leave a review. This would help others find the show.
I’d also love to hear from you, so please drop me an email at firstname.lastname@example.org. Till next time, take care and God bless!
PROMOTION: Sign up for a free month’s trial with Amazon Music to get unlimited, ad-free access to 75 million songs, podcasts in HD here: https://www.amazon.co.uk/music/unlimited?tag=agileinnovati-21 *