Replay: Agility with Jeff Sutherland

YC: Thank you so much for being here. 

JS: Glad to be here. 

YC: There's so many things I want to talk to you about it. As you know, in, in our podcasts that we focus a lot in terms of the soft skills. And this podcast is focused a lot on people who are actually work a lot in the technical field for like a software development. I want to ask you, since you were the founder and the creator of scrum, I want to start with your background. Cause you were at West Point grad, you were in the military. Why did you decided to have a military career? 

JS: For some reason when I was a kid, even when I was eight years old, I was, I knew I was going to go to west point. So it turned out. I actually did get in. Um, then towards the end of my four years at west point, the, at that time, uh, 10% of the class would go into the Air Force. The Air Force used to be the Army Air Corps. So west point had always sent people into the Army Air Corps. They, they started to decrease that when the air force academy started graduating students, but they still let a few people in. And so the Air Force was recruiting. I told them ‘if you make me a fighter pilot, I'll, uh, I'll switch services and join the air force.’ 
So I spent 11 years, um, mainly flying F four Phantoms, um, uh, the reconnaissance version, but also F 1 0 1 fighter aircraft. So that that's my experience. And it's directly relevant to scrum because the military experience is actually the operational aspects of scrum understanding, uh, rapid response, agile responses to situations, agile planning, or responding to change. All of that is, is, is burnt into muscle memory and a fighter pilot, right? And also John Boyd's OODA loop, uh, Colonel John Boyd, uh, changed the whole thinking about military strategy based on his pilot experience. And he taught all the war colleges and particularly the Marines as adopted his, uh, what he called the OODA loop, observe orient decide act. How do you approach a situation? How do you respond quickly? How do you change your approach to see, to get a competitive advantage? This is critical for particularly the product owner and scrum. So all of that is big. The burndown chart is the, is how, how do you get on the glide path at an airplane to land it right at the end of the runway, all that out of the military, even this, even the sticky notes on the wall, uh, I started doing that at west point and it had amazing effects and creating self-organizing teams. So that was my first career military. 

YC: That's very interesting that in terms of how those parallels of the, how that influenced the work that you develop, then that you do now in your book, The Art of Doing Twice The Work in Half the Time that you describe the, how confronting or working in at work, that in a work environment that had that kind of project management mentality of developing things in an extended period of time and, and planning everything perfectly ahead and then delivering a product at the very end and the failures of that. So how was, how was, oh, what was the trigger, I guess, for do, to start creating or to develop the scrum framework?

JS: There were several steps. One is I when my last tour in the military was I was professor of mathematics at the Air Force Academy. And I was completing a PhD at the university of Colorado in the medical school. And as I approached the end of my tour at the force academy, the medical school hired me to run a big grant and that grant involved, uh, supercomputing modeling the human cell, trying to figure out what caused cancer that led to a deep understanding of complex adaptive systems, which is the theory behind scrum. But it also, I worked with, uh, some of the, some of the leading technical people at Bell Labs because of the tools and technology that we're using. I was, I imported to the university. So all of that thinking came to, uh, a point where a big banking company came by the university one day. They said, you know, you guys have, you guys have all the knowledge, but over the bank we have all the money. And they made me an offer that my wife couldn't resist. 
And, uh, so I wind up at the bank. Well, uh, I, they made me a vice president for advanced systems, which was effectively the CTO, uh, for all the banks that they were running. They were running 150 banks all over north America. And I was mainly focused initially on the technical strategy. But as I looked at the projects, they were all late and I went into the CEO's office one day and I said, you know, uh, Ron, have you noticed all your projects are late? And he said, yeah, every morning, at least four or five CEOs or CEOs call me up. And he said, they scream at me. And I said, well, it's not getting any better. Every time they're late, the managers have more meetings, more reports, it makes it even worse. And, uh, because of a mathematician, I actually showed him a Gantt chart. And I mathematically proved to him that the Gantt chart would always make every project late
They went ‘what should we do?’
Yeah. You need a completely different model of working. Uh, we can't fix the whole bank at once. Let's take a business unit, everybody in the business let's find, let's take the business unit, that's losing the most money and introduce it to a model. And that basically had, uh, all the aspects of what a today, part of scrum, you know, it had a project manager, product manager who was acting as a product owner. It had, uh, uh, sprint planning. It had a sprint backlog. It had one week sprints. It had a burndown chart. All of that. I booted up right away, but scrum, the formalizing Strom calling it scrum didn't happen until 10 years later at a company called easel. And really the trigger for that. This is directly related to soft skills.
 I think I was on the advisory board for a nonprofit who was doing micro-enterprise lending in South America. And they were lending hundreds of billions of dollars, uh, to people. Most of them were so poor. They couldn't feed their kids and, and they get a group of people together. And then they talk about, okay, if each of you had a small business plan and we loaned you 25 Euros, what could you do with it? And when everybody had a plan, they'd loan them the money. And then they get together regularly to kind of check in. And when everybody paid back the loan, then they talk about how to scale a business plan. They'll loan them another 20.
They got amazing results. I mean like a woman who couldn't feed her children three weeks later, maybe she says, okay, I will, with 25 euros buy her a sewing machine, I'll start making dresses. I'll start selling them the town square three weeks later, she's got enough to feed the kids. And not only that, she's got a little extra for clothes. And so because kids can't go to school without clothes, now that she can put clothes on them, they can actually go to school. And now our businesses is scaling up, right? Six months later, the woman is building a new house for her family. And I was so stunned really by the effectiveness of that, it's kind of a team-based approach. Uh, I came back from a lunchtime meeting and the advisory committee to my team at the software company.
I said, just that, you know, you guys are always late. And, uh, and you're working nights and weekends and management thinks she really bad developers. Uh, you're under a lot of pressure. Um, I asked him, how long has that been going on? And every single person on the team said, as long as they were in software development, they were under this pressure, always being late, always being bad developers, always. And I said to them, you know, the people in south America, they don't have shoes, you have shoes, but you remind them, we have them because you have no software. You're, you're like a poor person that has no software, honestly getting beat up. So I said, you know, I think if we tried something different, just like the woman that could build a new house in six months at six months, we'd have so much great software that the management and the customers would say would ask us to actually slow down. And then we could take back our life. You know, we could spend time with our family. We could have more, we could have some dignity and respect.
I said, you want to try it? And they thought about it for a minute. You know, they said, you know, we've got nothing to lose. Why not? And, and that was the, that was the turning point that I, that marks in my mind the creation of scrum that started it.

YC: That's wonderful. What I really like as well is because it's always about quote, unquote a simple approach. It seems to complex problems because, and you have talked in the book about teams that have had, um, great talent. So it's not a matter of hiring the best people, but it's how people working together and kind of touching base regularly is that that'd be like the key, I guess, for, for scrum. 

JS: Scrum is about just regular people working together and doing great things.

YC: That's great. Now with the popularity, it seems that a lot of people are talking currently about agility and the one that kind of sprinkle agile in your projects. Do you see any misconceptions about agility or, or the scrum framework in organizations? 

JS: Well, there's huge misconceptions because if you look at industry data, uh, from the Standish Group, they've been collecting data on millions of projects for over 20 years, 58% of agile teams are late over budget or can't deliver anything at all. Wow. And so these people are calling themselves agile, but they're agile in name only. I mean, and basically they're unable to really deliver. And that means that they're doing something that's just making it pot impossible for it to work. And when you go in and talk to them, they have all kinds of misconceptions. And in the United States for the Department of Defense, it is the law that all it projects must be agile. … Defense appointed a board of distinguish, uh, people in industry called the defense innovation board. And they wrote a paper that went viral on the internet called detecting agile BS.
They say, okay, we're getting all these proposals, defense proposals from vendors. But a lot of them is just total nonsense. So here's how you can detect the nonsense. Number one, can they deliver working product to real end-users every iteration, including the first iteration, if they can, they're agile. And if they're not, it's, it's agile.
You know, so agility is not about saying you're agile. Agility is about actually delivering and doing it in a way that is really rewarding for the people. So, as I say since, and we, when we look at today, almost every major company is undergoing an agile transformation because it's business technology is changing so fast and it's so competitive that people need to change the way of working. And 53% of the agile transformations, according to the latest survey by Forbes magazine did not meet the expectations of management, which is almost the same number of agile teams that don't work.
Right? Yeah. We're seeing Agile BS at scale. Okay. So that's the area that's where that's mainly where I'm working today is, is to how to help whole organizations actually get this, get this in a way that actually really works for them. 

YC:  Is there any individual skill or kind of considerations that should be taken in order to work effectively in an agile team?
JS: Well, there's working as a team is always challenging. And if you look at great sports teams, I mean, scrum comes from rugby. Okay. So look, if you look at great rugby teams, the great rugby team captains are really legendary characters because they can inspire the teams to great performance, right? And how do they do that? And this is the scrum roster, of course, it's from how do they do that? Well, first of all, they set it up for the team. They block for the team. They, you know, they speak for the team. They, they encourage the team and the team is ready to get in there with them shoulder, shoulder, and move it forward. So that ability for a scrum master is really important. And then if you look at the team, I mean, I've had many people, rugby players in my classes, scrum classes,
In rugby, you're all arms linked in the scrum formation. And when the ball is put into play is a huge crush and you have to be really, uh, positioned exactly in the right way. And you have to trust that every other team member will support you physically. Or if you are particularly a short person, you can get crushed, you can get really injured. And so this ability to link, link up synchronize with the team and trust that everyone is going to support you. So you can, you can get through is critical. And, and the, the, the team leader, the scrum master and scrum needs to help coach the teams to work in this way. And of course there are always personal dynamics. So figuring out how to overcome that as a major job for both the team and the scrum master and the product owner for that matter.

YC: Yeah, absolutely. Have you seen any evolution of, or actually have you proposed or implemented any evolution or any changes throughout the years since Scrum was implemented, that are significant? 

JS: When we formalized Scrum in the beginning, it was benchmarked against other processes. And, and only when it went 10 times as fast as traditional processes, did we actually say, okay, this is what scrum is. And so scrum is a technology that is 10 times as fast. So it's very hard to make it go 20 times as fast,
But maybe we'll figure that out someday. So mainly the problem has been, how do you train people so that they know how to go 10 times as fast? And we found that it's very difficult for people. It's, it's, it's like, how do you win? How do you consistently win the soccer match and get the world cop? Okay, it's a similar kind of thing. So we know we've had to learn. We've had to significantly upgrade our training in the last few years. And we've also upgraded the scrum guide, try to get people focused more in the right way. So for example, we had a big problem with the whole idea of servant leadership and self-organization people were completely misinterpreting that, well, I'm a servant leader. I don't have to do anything. I just bring the team coffee, right?
No.  Now we say, it's a leader who serves, so leadership comes first and then you bring them coffee. Right. And self-organization a lot of developers would say, oh, I'm self-organizing. And they were doing something that was undermining the team's ability to deliver. So there was self-organizing in a way to destroy the team basically. And so we had, we had to change that term to self-managing, okay. To try to get people to understand what we mean, because the whole idea of self-organization comes from complex adaptive systems,  which is what I was working on to the medical field. And a complex adaptive system is an intelligence system. That's trying to self-organized to get around a problem, to achieve a goal. So the average developer was completely misinterpreting that they didn't, they didn't realize, oh, there is a goal. There is a goal for the team. The product owner has a sprint goal. And the only reason you self-organized is to get to the sprint goal faster. 
But it's hard, to get them to understand that, you know, it's oh, self-organization I can do whatever I want. So again, so from a soft skills point of view, explaining to people in a way that they can actually do it, that is a, been a huge challenge. And there's been constant upgrades to the scrum guide content upgrades to the training. And, and yet we still have 58% of the scrub teams. It can't deliver today. So we have a huge amount of work to do.

YC: I must ask you, because what I've seen in, in a lot of scrum teams as well is the kind of the tools like JIRA and others. What are your thoughts about the tools that are kind of used to organize the agile teams? Well,

JS: The best tool over the years has been proven to be sticky notes on a wall. There's no better tool. Uh, but today where we have so many remote teams, we need an electronic tool. Uh, JIRA has overwhelming market share. They have the same, they have about the same percentage of the tool market as scrum has of the actual market. My team uses JIRA at scrum Inc. And in fact, the whole company has recently said, okay, everybody's going to use JIRA so we can, so we can get consistent data. And it's consistent picture from every team. So you have to have it in a distributed environment or remote environment like we're working in today, you have to have them. And so the goal is to get something that is as close to sticky notes on a wall as possible, you know, something that is as simple and easy to use of sticky notes on a wall.

YC: Now what's a good first step if organizations either in the DOD or that may not be necessarily software development centric, what's a good first step to start approaching or becoming more agile in terms of what, what is a good first step to take?

JS: Well, the book you mentioned Scrum, the Art of Doing Twice the Work in Half the Time has been very useful because we put in there, all the things we're doing around the coaching and training that we're doing now to help teams. And I recently had someone in my, one of my trainings from Apple and she said to me, Jeff, do you know why apple always meets the (goals)?  And I said, no. Why? She said, because we do scrum by the book. And of course I was interesting. 
You know, Apple is doing a lot of things besides software, you know, it's mostly hardware and, and lots of other stuff. So, uh, that is a really good place to start. I've had, I've had people from all over the world, just read that book and then start and be successful.

YC: Absolutely. It has a lot of great information because it's narrated and in terms of providing specific examples and it's, uh, I like one of the things that I really, uh, that kind of stick with me in the book is in terms of, it's not the approach of just failing quickly. It's about delivering, uh, delivering fast and giving that value to customers. So I really enjoyed it. 

JS: Yeah. That's another whole challenge. Failing fast. People can easily  misinterpret that what we wanted to get, what we want to do is get to success as fast as possible. So to do that, we want to take small risks in short intervals. So anyone may fail. But the goal is to do that in a way that you're successful. And, sometimes developers can say, well, agile is all about failing fast and we've failed every sprint for the last two years.

YC: Thank you so much for your time today. It's been great talking with you, and I'm certainly recommend our listeners to, to read the book  because yeah, it was very great advice to get started with, uh, or to kind of refresh the knowledge and remind what's really important. So thank you so much. 

JS: Thanks for inviting me.