Jeff Sutherland: Know How to Overcome Your Team’s Limits and Become a Leading Force

Richard:
Hi, Jeff. So great to see you. Thanks so much for joining us today.

Jeff:
Yeah, I’m glad to be here. It’s great to be here.

Richard:
Really great to have you. We both put on our black shirts. We both look amazing in our black shirts.

Jeff:
Yeah.

Richard:
Is there anything else you want to add on to that introduction?

Jeff:
No. Other than it’s now since we updated the Scrum Guide last year. Scrum is now more than 21 years old. It still seems to be expanding, which is really amazing. Maybe the most interesting thing I learned this year as I was working with Ken Schwaber updating the guide is that he said, “Jeff, I’m ready to update the Guide. So it’s applicable to all kinds of teams, not just software teams.” He says, “You tried to get me do that 10 years ago. Now, I’m ready.” I said, “Well.” My company, Scrum Inc., most of our business is not software anymore. It’s in other domains. His CEO, Dave West, said, “Well, that’s true of Scrum.org as well. Most of our business is not software business.” So we’ve actually crossed a big divide. Scrum is 80% of Agile. So Agile in general today is more outside of software than software itself.

Richard:
Great. Great.

Jeff:
Which is pretty amazing.

Richard:
It is amazing. It is amazing. Okay. I have a couple of questions about this. So the big change in the newest Scrum Guide is that it’s applicable to businesses outside of software. Is there anything else about the new Scrum Guide that you think really stands out?

Jeff:
Yeah, there’s about four things that we tuned. We wanted to make it simpler. If you give me the Scrum Guide to a sales team, it needs to be simpler. So we focused it on one team, the product owner, the Scrum Master and the team members, it’s all one team. We used to have this concept like there the Scrum Team, the product owner, Scrum Master team, and then there was the development team.

Richard:
That was a little confusing.

Jeff:
Yeah, it’s confusing to a salesperson. So we fixed that. But there was also a couple of other things in there. Ken felt the biggest problem in the industry was that Scrum Masters would take in the terms servant leaders. That meant they didn’t have to do anything to change the behavior of a team when it’s dysfunctional. We’re getting a lot of complaints from executives saying, “These Scrum Masters, we pay them a lot of money. They’re really just secretaries. Why do we really need them?” Right? Initially, Ken wanted to take out servant leadership from the guide. Everybody screamed, “Oh, you can’t do that.” So over a long period of time, and almost a year and a half of figuring this out with the Scrum community. It now says, “A leader who serves. A Scrum Master is a leader who serves.”

Richard:
A leader who serves, that is a really nice twist.

Jeff:
Yeah.

Richard:
On that phrase.

Jeff:
It really does change the text.

Richard:
Yeah.

Jeff:
Another similar thing was the word “self organization”. We found in a lot of companies, the Agile developers, were saying, “Well, self organization means I can do whatever I want.” They’re not delivering, the manager results out. The product owner, the screaming.

Richard:
The servant leader lets them figure it out for themselves.

Jeff:
Yeah, right. So we probably had to do something to that. So we said, “Self organization come from complex adaptive systems theory where a intelligence system self organizes to achieve a goal.” Okay, so it’s all about achieving the goal. We felt that this could be better understood by people all across the world because Scrum is in almost every country in the world. It could be interpreted better cross culturally if the teams are self managing. Then we elevated the goals.

Jeff:
Initially, Ken wanted to make … Well, they were complaints about product vision, okay, because the product complaints in the Scrum community that the product owners don’t have a vision. We have this concept of a vision in the Scrum Guide, but the product owners don’t have it. habit. So we said, “Well, we need to make that a lot more concrete.”

Jeff:
What is the concrete piece of what a vision would be? Well, that would be the backlog itself, but the goal that the total backlogs’ trying to achieve. So now we have a product goal front and center. We wanted to strengthen the word commitment, right, because of the self organization problem. So we said, “Okay, the product backlog is designed to achieve the product goal. The team’s commitment is to turn that product backlog into the product goal.”

Richard:
Okay.

Jeff:
Then we we dropped down to the sprint goal, we already have that in the guide. But we said okay, the sprint backlog, the commitment of the team is to achieve the sprint goal. Now the third artifact, the increment, the commitment of the team is to achieve the definition of done for that increment in the sprint. So I’m just working now through a new book or it’s actually not that new, that Gabby Benefield wrote, A Little Book of Scrum, really good introductory book. We wanted to make consistent with the Scrum Guide on finding that almost on every other page, you have to change a couple of words because self organizations. Man.

Richard:
Basically.

Jeff:
Leader who serves the commitments, the goals, those things have to be tweaked. So I’m working on that right now as well.

Richard:
All right. Now, the other part of my two big questions. We call it the Agile Manifesto colloquially. Officially, though, it’s the Manifesto for Agile Software Development, is that right? It’s like the full title of it.

Jeff:
I think that’s maybe, which I have to go look at the webpage in the Manifesto org. But we always call it the Agile Manifesto, you may have a formal title on the webpage.

Richard:
It is specifically about software. But it doesn’t really have to be. Right?

Jeff:
Right. The only thing that I do today what I’m talking about it, the second value is the most important one. That is delivering early and often basically. We said working software, we value over comprehensive documentation. So I changed that software to product when I’m talking to people today, because most of the people we’re talking to are not software people. So they’ll complain if you start talking about software with them. But every everything else works. It’s just that one word, software to product makes it acceptable to everyone.

Richard:
All right, cool. Cool. Let’s see. So this is the podcast about teams. Our guests usually talk about the best team they’ve ever been a member of in their lives. When I say team, what we mean is any group of two or more people aligned with a common goal. You can talk about Scrum and goals. We just talked about that. It doesn’t have to be a work team. It could be talk about my wife and me, we’re a group of two or more people aligned with common goals. Any group that you’ve been a member of, any team you’ve been a part of. What’s the best one of those in your entire life?

Jeff:
Well, there have been many. But if I had to pick one, I would certainly focus on the first Scrum Team because they produce the most significant results. Also it was transformative for every person on that team. It was a life changing experience. We also might talk about though what about a set of teams. The highest performing set of teams I’ve seen was at PatientKeeper. That was certainly a transformative development experience for the company. The problem with great teams is that they don’t last forever.

Richard:
Yeah.

Jeff:
The story about what happens afterwards is almost as interesting as the actual team experience.

Richard:
Where do you want to dive deeper in that first Scrum Team or …

Jeff:
It’s one of the first Scrum Team. Yeah.

Richard:
Okay. So where was that?

Jeff:
It was a diesel corporation. I had started a prototype of what became Scrum 10 years earlier in a large banking company. I was hired into multiple technology companies doing innovation, building the first internet news company, one of the first object database systems. A lot of technologies that the banks needed, spun out of that banking experience. I was running an object database company, I was president of the company. A company which is now known as Matisse, it’s a high performance transaction processing system that mainly runs multi $10 billion nuclear processing plants, lights out. So extremely reliable, extremely fast and massive amounts of sensor readings. So I was running the object database company, where we were actually finalizing the product itself, and also doing a lot of consulting around the world and using the product with object technologies.

Jeff:
That database came out of the AI world. In that AI world, we had very rapid software development with constant refactoring, constant updating, continuous integration, continuous deployment, the system’s always working. All the things we do today were part of that early AI product development. The CEO of Easel called me up one day, and he said, “Jeff, we’ve been trying to hire a new head of engineering. It’s particularly important because we bought a company, a German company, a small tech company. The purpose is to leapfrog the technology that we’re building, because we’re building a 4GL language product right now, which is one of the leaders in the industry. But there are many different competitors now coming on the scene. We need to do better than that. We need someone who has a history of innovation to come in and take this new company we just bought, and use that technology to create a completely new product line that’s going to replace a 4GL product.”

Jeff:
So he wanted to hire me, like a chief engineer at Toyota. You come in, we’re going to give you whatever you need, we don’t even know what the product is yet, you’re going to have to figure that out. So it sounded really interesting. At the time, my object database company that was funded by the French, they were getting a new round of investment. There was some disagreement between me and the new investors that we had to settle. But I had this offer from Easel. In the midst of all this, I decided to go to Easel. They gave me the best C++ developers they have. I worked with them for some months. I had spent years on standards committees, usually as the editor writing specifications, standard specifications for the industry.

Jeff:
So I said to the team, “I’m going to be the guy that writes all the specifications,” which today we know as the product owner, right? They were kind of horrified. But I said, “Look, I know this stuff. Basically, you don’t have the kind of experience we need to build this new product.” When we figured out what it was it turned out to be a system where you could visualize the system. Then that visualization would auto generate all the code. Then you could dive into the code and change the code and it would automatically update the design. So you could do the first round trip engineering product. I was in a meeting with one of the early users of that product, he was the head of Agile at IBM, Scott Ambler. He’s now moved over to the Project Management Institute.

Jeff:
He’s the head of the Agile programs. I’m in a committee meeting for one of the OMG standards, which we are both are on. Scott says to me, this was like two weeks ago, “Jeff, that product that you guys build, it’s called Object Studio is one of the five best development products ever created. I use it today.”

Richard:
Wow.

Jeff:
I thought that is amazing. Okay.

Richard:
It is amazing.

Jeff:
So that team, we were motivated by a number of different threads. But one of them was Alan Kay at Xerox PARC. Alan was the inventor of small talk. Of course, we were small talk guys. Alan came to MIT to get a presentation for, along with almost a dozen language inventor. They all presented papers, got awards. His paper on small talk described what happened at Xerox PARC, where they invented the personal computer. They invented the Windows interface. They brought the mouse over from SRI and connected the mouse. They invented the Ethernet, they invented the laser printer. I mean, we’re sitting there and the MIT audience is like, “This one team invented everything.”

Richard:
Invented life as we know it today.

Jeff:
They didn’t leave anything for the rest of us. We said we knew we needed a new process for people using our round trip engineering tool. So we said what he didn’t invent was a team process to really leverage that technology. And so that’s what we’re going to focus on.

Richard:
Oh, cool. I love that you called it a team process.

Jeff:
Yeah. I was listening to one of your previous podcasts by a woman that was talking about ensembles, it’s most recent. It struck me because we had a couple of Danish guys on the team, three of them, I think. We talked about how do we think of the software itself. It’s going to be an ensemble of components that plays together like an orchestra. Therefore, because of Conway’s Law, the way the team works has to be like an ensemble.

Richard:
Yeah.

Jeff:
So the whole conception of this was, firstly, strongly influenced by one of the greatest developers ever, and his team. But also, by a global … The technology was from a German company, we had these three Danish guys, we had a bunch of Americans, but it was a global team with very different perspectives that was really trying to build something great.

Jeff:
As it turned out, that energy fed on itself so that the team, every person became a better person. What they did was beyond what we could think possible. You come in every day, just excited and accelerated by everyone else on the team. We’ve formalized what we now know it as Scrum by the end of 1993. Then in 1994, we delivered two releases of Object Studio. The company was then acquired by a bigger company called V Mark, mainly because of Object Studio. So then the team had to split up because only half of the team wanted to move to the new location.

Jeff:
So it was very interesting. People were really … Some of them were in my office crying, say, “I’m going to be looking for a team like this for the rest of my life. Hu, hu, hu. I’m never going to find it. What am I going to do so?” So fortunately, today, we have Scrum. So there’s a lot of opportunity.

Richard:
Yeah, that’s a wild story. Now, okay, this team, how many people are we talking about?

Jeff:
There was about eight people when we got fully maxed out. I’ve written this little book called the Scrum Papers. I’m updating it now. It’s on the web where I tried to document all this. I have the names of every team member except one. I’m still trying to figure out the name of. He was a master’s student at the University of Massachusetts that we hired. He became one of our lead tester. We were building a very sophisticated automated testing system. He was a great, but I’ve forgotten the guy’s name. I have every other name.

Richard:
I hope we can find him, maybe through this podcast.

Jeff:
Maybe we’ll listen to this podcast.

Richard:
We’ll find him. Okay. This team, I also like to ask people about one word that when you take yourself back to this team and re-experience it, relive it, and we were just doing this. You’re definitely reliving it more than I am, you’re telling the story. I’m listening to the story. What does it feel like within you, as you are experience this team? Is there a one word you could use to describe that sensation?

Jeff:
The one word that comes to me was transcendent, they transcended their personal limitations. My personal experience coming in every day, at the time, I had spent many years going all the way back to my time in Vietnam, flying over North Vietnam. I got interested in Tibetan Buddhism. So I have been meditating for 30 years.

Jeff:
At the time, I was actually undergoing multiple initiations. The Tibetan community, they would have these conference. They invited a senior Lama from Tibet over and then he would do this initiation. They would say, “This is like a seed, that we’re going to put in your heart. You won’t notice much immediately, but it’s going to sit there, and then it’s going to grow, and it’s going to change everything.” So as I came in to the Easel Software team every day, all of a sudden things would happen. I’d feel strangely compelled. Okay, out of my gut, it was not mental. We need to do it this way. That kept on happening every day.

Richard:
Wow.

Jeff:
It’s the kind of thing a good Scrum Master would do, right? You come in every day. Then the team contexts may be changed a little bit. How can we steer things in a little different direction? As we were doing that every day, all of a sudden, the team performance and capability just started building and building and building until it was unbelievable to people what we could get there.

Richard:
I’ve never heard you tell the story, that relating this to Buddhism. So that’s really fascinating.

Jeff:
Yeah. I don’t talk about it much.c I know Jim Copeland can relate to it. He came to a Scrum Master Training in Denmark. He says to me in the middle of the of the Scrum Master course, he says, “This smells like Buddhism.” He was a very deep thinker. So we started kind of drilling down, and we got to this. But the issue is that life is full of problems, right?

Jeff:
The Four Noble Truths starts with life is full of dukkha. Second, there’s a reason for that. The reason is you’re holding on to old ways of doing things. Then the third noble truth is there is a way out. Then there’s these eight rules for living a good life. We just took that and apply that to Scrum, right? Life is full of impediments. Your Scrum Team is full of impediments. There is a way out, identifying, prioritizing, and systematically remove those impediments, it actually changes reality. It changes the way things work. Both objectively and externally, but also people themselves.

Richard:
Sure. Our company is full of problems. Why? Because we’re holding on to old ways of working and there is a way forward. Wow. Okay. Okay. I mean. Okay. Now this Easel team, subjectively, what else about this team lets you know that this was a really great team?

Jeff:
I think all the members of the team went on to do great things. Jeff McKenna considered himself the first Agile coach. He was a consultant of the team. He would come in for a week. He lived on the west coast, he would come in for at least a week a month. Then he’d spent time with each of the team members. Because we had this engineering tool, all team members have on their wall a complete … Today we’d use UML. At the time, we’re code URM, one of the other design, a complete object diagram of what they were working on.

Jeff:
I remember one day, I walked into a developer’s workspace after Jeff had been there for about an hour. He had a map of objects that filled the whole side of the wall. But about 75% of it had been clipped by scissors and was lying on the floor, shredded it. He said, “Jeff, just threw away 75% of my code.” So that kind of thing produces radical innovation. I mean, you’ve got somebody that’s expert enough to walk in, and one day throw away 75% of the code you’ve written and says, “Start over with us.”

Richard:
Yeah.

Jeff:
Seed and do that constantly.

Richard:
That’s more like a leader who serves than a servant.

Jeff:
Yeah. A leader who serves. Yeah. The other person, John Scamletales, who is the first Scrum Master has gone on to be VP Visionary of many companies, started his own companies. He went to Rational Rose after Easel. Rational had one of the big tool, he tried to fix that and did a lot of good work. But I think if you go back and track any individual that’s on that team, they’ve all gone on to do great things for their life.

Richard:
Wow. All right. Then the other side of this objectively, how do we know this is a great team? One thing you said was that somebody is still using this product, and it’s like 30 years later.

Jeff:
A while back, I was in Sweden. Simcom, which acquired the product was having a mob programming demo, because the product today, you can do mob programming. We had about 12 people in an hour long session. We built a game together in an hour. Everybody’s working on the same code, looking at the same screen from different rooms, some of them, right. All just working on that same code, built a game in an hour that would have taken days, a normal thing. Simcom said, “This product, revenue has gone up at least 10% a year since the year we acquired it.” They acquired it I think in 1996, it has never stopped improving.

Richard:
All right.

Jeff:
There’s objective measure. As Scott said, in his view, today it’s still one of the best five development tools available. So that’s another thing that I felt good about. In several domains, we’ve been able to have teams create products that 20 years later are still great products.

Richard:
Yeah.

Jeff:
So that’s been this lasting. The products go through multiple companies. Even though the company has all changed, the product has some kind of internal life of its own.

Richard:
Yeah.

Jeff:
That caused it to move on.

Richard:
Yeah, yeah, yeah, a way of working with it. That is built into the product now.

Jeff:
Yeah.

Richard:
Cool. Now I have another question. I’m sure you have an opinion about this. Do you have any advice for listeners about how to have a really great team of their own?

Jeff:
Well, the first thing that you need to understand is continuous improvement. You need to have the attitude that every day you’re going to get better. I learned that back when I was a kid at West Point. The very first day I’m coming in, I’m standing in line in front of the gym in a T shirt with my duffel bag. Working out in the gym off to my right is the US Olympic Gymnastics team. They were awesome. I mean, superhuman. You could not believe what they could physically do. I found out that the the army gymnastics coach was the Olympic coach.

Jeff:
So I decided to go out for the gymnastics team as soon as I got through that first summer in beast barracks. I was on the parallel bars. For years, the Olympic team member, the best parallel bar guy on the Olympic team was the assistant coach. Every day, he would have me do an exercise over and over again. Every time I do it, he said, “Okay, this is not quite right, make this change,” over and over. No judgment. That taught me how Olympic teams be great, continuously small improvements.

Jeff:
Then in my last year, I became what they called training officer of my company. One of the responsibilities was getting the cadets to march well on the parade field. My company was one of the worst marching companies. They had been for a hundred years, they’ve been known as the loose dues because of their laid back attitude.

Richard:
For a hundred years.

Jeff:
Nothing I tried made anything any better. Until I started putting color coded notes on the company bulletin board, okay, here’s the things that cost us points in the last parade. To get better, here’s the impediments we need to fix in priority order. So making that work visible and particularly making, getting the impediments into the backlog. That is what team members need to understand. Every single day you come in, it’s going to be a better day because you’re going to make an improvement. You have your sticky notes on the wall. You’re going to have the product backlog of what you’re building. But the way you work that backlog, the impediments need to be built into it. You need to be working that backlog so it’s getting better every day. If you do that, the team will self organize to be great.

Richard:
I’m so inspired by this, I need to get myself a piano coach who watches me and listens to me and tells me the thing to do next.

Jeff:
Right.

Richard:
Things to do next. I think I know. But I bet there’s somebody who knows better.

Jeff:
Of course, the challenge from a Scrum Master’s point of view or team leader’s point of view is that people don’t necessarily want to get better every day. There are constantly problems getting everybody on the same page and then executing that approval process. That is the real leadership.

Richard:
Yeah. Okay. So here’s something interesting. I’ll say it in first person. I get paid by salary, I’m going to get paid anyway. Right? Why do I have to work harder every day and do things a little bit differently every day? I’m going to get paid anyway.

Jeff:
Well, let’s go back to the first Scrum Team. At the time, I was a volunteer, the President Advisory Board of a company called ACCION, a nonprofit. That was doing micro enterprise lending in South America, hundreds of millions of dollars a year. Lending small amounts of money $25 to really poor people, people who could not feed the children.

Jeff:
What they found is that if you formed like a team, and then you coached everybody to come up with a little business plan, then a guy might say, “Well, if I have $25, I’ll buy some wood, I’ll make a fruit cart, I’ll sell fruit.” This is town square. One might say, “I can buy a sewing machine for 25 bucks, I’ll start selling dresses.” Within a few weeks, they were able to feed the kids and they had a little money left over so they could buy clothes, which was really significant because if you have no food, you have no clothes for the kids.

Richard:
Right.

Jeff:
If you have no clothes for the kids, they can’t go to school. But once you have clothes, now the kids are in school, now their business can ramp. Some of these people within six months, starting from not being able to feed the children, six months later, they’re building a house for their extended family.

Richard:
Right.

Jeff:
I was stunned by the effect of that. Professor Yunus in Bangladesh who figured this out, got a Nobel Prize for it. I went back to my team one day, which at that time, they were working a lot of overtime, kind of late, management thought they were bad developers. I said, “How long has this been going on?” You’re working over time. You’re working nights and weekends. Management thinks you’re really bad developers. Every person on the team said, “This has been going on as long as I’ve been in software development.”

Jeff:
Some of the people had been in software development a year or two, some of them 10 or 15 years. Everyone said 100% bad developer, work over time, always late, always too many bugs. I said to them, I just came from a meeting at ACCION. I think if we had a different way of working, within six months, I mean, we’re like the poor people that have no food. We have food, but we have no software, right? We are deprived of software. If we did what they’re doing and working together, I think within six months, we would have so much software, it would be such good software that the management and the customers would ask us to slow down. It would be like drinking from a fire hose. When they did that, we could take back our life and regain our dignity as people. Would you like to try it? I vividly remember the meeting where everybody thought for a minute and they said, “We’ve got nothing to lose.”

Richard:
Let’s try.

Jeff:
Let’s try it, and that’s what got them.

Richard:
Okay. All of that.

Jeff:
That’s what the leader who serves to convince those people that are just coming in and collecting the paycheck that life could be great. You could have more fun. You could have more time off. You could work with a team that you just … I mean, the only way to describe it is love. It’s so great working with these people that you remember for the rest of your life. You want to try it? That’s the challenge.

Richard:
It’s wild. It’s crazy talk. So going back to that story of the gymnastics practice what was it about your past that got you to that point? What happened in your past that got to the point where when you got to the gym that day and you discovered that the gymnastics coach was the Olympics gymnastics coach, and the best gymnast was the assistant coach, what was it that led you to be so eager to … I mean, you could have done anything while you were there. But suddenly, you said gymnastics.

Jeff:
Yeah. I grew up in a small town in Massachusetts. I’m pretty laid back. But something about that environment and seeing that Olympic team working out, it inspired me. I mean, I’d never seen anything like it. So I said, “Well, I know I’ll never be as great as these guys. But I can be better. They can help me be a lot better.” Then once I’d gone into the training program, I said, “Wow, this is different. This is a different way of thinking about performance.” It’s much more rigorous. It’s a radically different way of working from the way I was brought up as a kid. So they took me into a different world, right? That’s what happened.

Richard:
All right. Is there anything else you want to add on? We talked a lot about teams in general, a specific team, Scrum, the new Scrum and Agile.

Jeff:
I think as I mentioned earlier, I had one set of teams at a company called PatientKeeper. They were able to do something that I never thought a software team would ever be able to do. I was the CTO of the company. I started Scrum there. I was actually a member of the team for quite a while, building out our systems to support Scrum. We were building hospital systems. We went install applications for physicians that would do everything both on the mobile and the web for physician. To do that, we had to connect into the back ends of any major system in the hospital that had any information a physician needed. There were thousands of them in big hospitals.

Jeff:
So we would have to come in and install on top of all these hospital systems in the biggest hospitals in the United States or the world for that matter. So that whole installation, training of physicians, bring in the hardware and software was like this huge enterprise deployment. So in the early days, by implementing Scrum, we really tuned up the Scrum process and the tooling so that the teams eventually were able to deploy to four major hospitals every sprint like clockwork. In that timeframe, they probably update 35 or more of the hospitals we already had deployed.

Richard:
Right.

Jeff:
So that meant almost every week, we were going live at major hospital systems. So the level of automation and focus, today, they call it DevOps, but most people don’t really do it. DevOps means complete automated testing and deployment. You push a button, and it deploys like at Amazon, what they’re doing now with 3300 teams at Amazon. You finish a story, you hit a button. It rolls through all the automated infrastructure and deploys automatically. If there’s problems, it automatically rolls back.

Richard:
Yep, yep. It works. We know it works, and somebody uses it.

Jeff:
So we have that kind of thing going at PatientKeeper. The thing that I was really looking for was not just a high productive team, but a high productive company. That company was a startup started in 2000. It took till about, and the revenue is just very slowly ramping until about maybe 2004. Then we hit that point where we can actually deliver full DevOps, full on DevOps. The revenue went from 10 to 15 million to 50 million in one year. We got on that, which is what we’re seeing now in the COVID environment for many companies doing Scrum.

Jeff:
Okay. So those teams did something I didn’t think was possible. They actually far exceeded my expectations. So I’ve seen that a number of times, but never as dramatic as PatientKeeper, where you implement Scrum, you fix some impediments. You got to do a little coaching. Then all of a sudden, that team takes off, and they just do unbelievable things that you didn’t even imagine it was possible for people to do.

Richard:
So you mentioned this happening during this past 12 months with COVID worldwide. Now, many of us, you talked about a demonstration of people doing mob programming or ensemble work, and a couple of them were remote. What’s happening, that even though we can’t work together face to face, or most of us haven’t been working together face to face, what’s been happening that has helped teams and teams of teams accelerate so much?

Jeff:
Well, one of the things that we know, we wrote the first paper on this I think back in 2007, we had to globally deployed Russia, Canada, United States, multiple teams, many dozens of teams, where every team was in multiple locations. So all teams were remote. That implementation was able to hit what we call linear scalability, actually went super linear. They doubled the number of teams and they more than doubled production. So we know from that experience that it’s possible to work as well remotely as it is locally with Scrum.

Jeff:
Even though it’s needs more discipline, it is a little harder, you have to be more focused. So as soon as you went to this COVID lockdown, I mean, I started getting notes. I got a note from a senior vice president of Amgen, one of the biggest biotech companies said, “Jeff, thank God we went to Scrum last October. Because within a week of lockdown, we’re working totally remotely, and everything’s back to normal.” He says, “Our competitors who are using traditional project management are dead in the water. They are going to be dead until COVID is over.” It’s still not over. He says, “When it is over, it’s going to take them a year or two to climb out of the pit that they’ve fallen into.” So COVID all of a sudden gave a tremendous competitive advantage to people who can do remote Scrum well.

Richard:
Okay.

Jeff:
So they are capturing all the business from their competitors, thousands of which are going bankrupt. So we have this situation, Amazon, it’s obvious, they’re going to go up in COVID because they’re delivering stuff, people need more deliveries. So their stock went up two, three, 400%. What people don’t realize is companies like John Deere, we’ve been working with, percentage wise, their stock went up more than Amazon. They are the biggest pharm equipment manager in the United States. And it’s because they’ve been really working on deploying Scrum enterprise wide. That’s given a tremendous advantage. So there’s dozens of companies like that.

Jeff:
The world is changing right now. COVID was a catalyst for the changes that were emerging all of a sudden our forced. Production needs to be much more rapid, we’re moving much more to using robots. We can pull things local, use 3D printers. That is causing a wave of technological change that is accelerating faster than people can really keep up with. So if a company has a good Scrum implementation, they can take advantage of that globally to dominate the world and even companies that don’t do Scrum well like Tesla.

Jeff:
Tesla is one of the most agile companies of the world, so that they’ve got agility down. We’ve done some Scrum training inside the company. They have some Scrum and they want more. Because basically, Elon’s strategy is everybody works 80 hours a week, right? Our strategy is you work 40 hours a week, and you do twice as much work as the guys doing 80 hours a week. Right?

Richard:
Right.

Jeff:
That’s all concept. So there’s a bunch of people inside of Tesla doing Scrum that want more of that. But even without, the company is extremely lean, which is the first half of getting Scrum right. Not only do they update my car every two weeks with new features. It’s not just software right now. Hardware is 80% software today.

Richard:
Yeah.

Jeff:
So you can put in a new software release. All of a sudden, the car runs faster, it turns better, it has more range. It stops quicker, right? So you’re able to actually do hardware upgrades because of the software capability. The hardware itself on Tesla assembly lines is there on the average, 13 major hardware innovations rolling off the assembly line every quarter.

Richard:
Which is crazy.

Jeff:
Which is the guys that work at Ford said they maybe did one a year. So 13 a quarter, that’s 52 times faster than Ford.

Richard:
Right.

Jeff:
So they are accelerating. They’re 10 years ahead of the competition in many areas. People say, “The competition is going to come in and crush them.” But they are accelerating ahead of where they are now. So Tesla is going to be like Bitcoin.

Richard:
Sure is.

Jeff:
It’s going to go up. It’s going to be the iPhone of cars, right?

Richard:
Sure.

Jeff:
Half of the people in the world have an iPhone and half of the people in the world will have a Tesla. That’s a lot of Teslas to build.

Richard:
I know there’s observation that seems like half the people who live around me have a Tesla.

Jeff:
Yeah, we don’t have it that many around where I live, but it’s always increasing, right?

Richard:
Yeah. Well, alright. Jeff, thank you so much for joining us today. How could listeners and viewers get in touch with you?

Jeff:
You can email me, Jeff@ScrumInc.com. You can go to ScrumInc.com and you can see all of the courses, stuff we’re doing. You can go at Amazon and download, Scrum: The Art of Doing Twice the Work in Half the Time. We’ve got a couple of other books that are really important. But what I’ve tried to do particularly in Scrum: How to do Twice the Work in Half the Time, I’ve really tried to write the story of what we talked about today.

Jeff:
What was at the root of the creation of Scrum? The team’s going into a super flying state. How can everybody else do that? We made it really simple. I remember a guy running an energy company in Kenya, in Nairobi, came to New York. He was a Ford Foundation fellow. Came to New York, he said, “I want to talk to you about what I’ve done. I read your book six months ago, and twice the work in half the time. We’re doing a lot better than that. Every one of my teams is doing three times of work in a third of the time.” This guy had never done anything except read that book. Okay?

Jeff:
So if you haven’t read it, strongly recommend it. It’s written for the average business person. Okay, it’s not written for a software developer. It’s written for the average business person that’s just trying to be more successful.

Richard:
All right. We’ll include links to this in episode notes and on screen for people watching the video.

Jeff:
Great.

Richard:
Jeff, thank you so, so much for joining us today. I really appreciate this time together. Listeners and viewers Remember to support this podcast, visit my website Kasperowski.com.