Reflecting on 30 Years of Scrum: A Conversation with Ken Schwaber
In this special episode of the Scrum.org Community Podcast, Dave West sits down with Ken Schwaber, co-creator of Scrum, to celebrate 30 years since the initial introduction of Scrum at OOPSLA 1995, based on the paper, The Scrum Development Process.
Ken reflects on the origins of Scrum, the cultural challenges faced during early adoption in large organizations, and the critical importance of transparency, honesty, and teamwork. He shares insights into how Scrum has influenced software development practices such as DevOps and continuous delivery, and offers his perspective on AI as a tool to support—rather than replace—human teams.
From early pioneers to the modern evolution of Scrum, Ken shares stories, lessons, and hopes for the future: that Scrum will continue helping people and organizations achieve fulfillment, innovation, and success.
Transcript
Announcer: 0:00
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.
Dave West: 0:25
Hello and welcome to the ScrumOrg community podcast. I'm your host. Dave West CEO, here at ScrumOrg Today, we have a very special episode as we celebrate 30 years of Scrum, 30 years and to celebrate this amazing moment, we have the one and only Ken Schwaber here today, joining me. Welcome to the podcast, Ken. Thank
Ken Schwaber: 0:50
you, Dave. I'm not sure if I'm one and only, but what the heck.
Dave West: 0:56
Let's try the one and only Ken Schwaber. Oh yeah, there might be more than one. Ken Schwaber, I guess, I guess you could always Google that to find out, but in my head, you're the one and only. So 30 years,
Ken Schwaber: 1:10
it's been a long time, who would have guessed, but the purpose of Scrum was to have people look at things in a different way, and because obviously, you know, like a previous way of looking at things was not working very well. So huge effort by a number of us, I mean yourself, included with Kent Beck and Ward Cunningham and many others, was to try to get software development back on track, to find what was the key thing that was wrong. If there were many of them, we were probably in trouble. But if there were only a couple of things wrong, a different way of looking at things, maybe we could do something. So that was the intention, yeah, and, and it
Dave West: 2:01
was, I guess, over 30 years ago, because obviously, in 30 years ago you, you wrote the very long paper that OOPSLA 95 in Austin, Texas, that that was the coming out party for Scrum, even though you'd been practicing it a long time, a long time before. So what were those things that you were really trying to get at? Ken, what were the what were the problems that you saw you're working at patient keeper, at Sentinel, and some of those other big projects and programs. And
Ken Schwaber: 2:33
right after OOPSLA, we went on to a number of large, highly visible endeavors like Fidelity and IDX. So things that were much more visible, the things that we noticed were, there are a lot of variables in software development, like who's involved, how skilled they are, and the things we were dealing with or had many different states, also, like someone passed you a data model. What shape was it in? How accurate was it? Were the data model? Were the entities broken down into understandable and definitive attributes? So there are a lot of things that were treated as as pretty much constant that weren't. And the way you approach things like that was very different. The way we approach it is we had a methodology of some sort, and it defined tasks, and tasks had number of people involved, their background and things like that, that were treated as constants because they were never looked at. They were just treated as right and correct, whereas when, whenever we got into development, we found everything was a variable, you know, and your job was to, was to get them to pull together into something that would represent value to the customer. So we thought, and I had met with someone who was an expert in process control for DuPont. And so this is with Kevlar and products like that. How do you control those to get a valuable product? I said, huh, very similar to us. And this guy said, Well, if you're using a lot of variables that are in different states, you better be checking them all to that time to see what state they're in so that you can figure out what the next thing you can do, like, if it's about to explode, you probably want to do something different than if it's not going to explode, like if the project's about to fail, versus if the project successful, your actions might be different. He said, so you know, if I'm looking at what you do. For software development, it's not too different from what I do with chemical processes, lot of variables, a lot of potential states for those variables, a lot of interactions. And the way I cope with it right now is I inspect the state of those variables and the state of their interaction at any point in time, and based on that, I take some action, or if it's a good day, I know actions heated, and then I can see what the effect of that action is. And I keep repeating that until, you know, like you get up one of our Patriot missiles, it hones in on the target, because you want an outcome. And he said, you can only hone in with on that if you have some sort of target. So that's the goal of the project, and also the interaction with the customer. So the customers, yeah, well, that's almost good enough. So keep going. That's fine. That's fine. He said, I can't help but notice that you don't do anything like that. And I wonder, because you guys are fairly smart, I hope aren't you? Long pause, well, a lot of us think we're pretty smart. And he said, so why don't you use your intelligence and look into how things are going. And by the way, I would, I would look in frequently at first, and then as you get to know how things are going, maybe less frequently, but don't be caught by surprise. I would develop a culture where you are expected to use your intelligence. I would develop a culture where you frequently change direction based on what you're finding as you're looking in and I would also, because there's so many different skill sets that are needed, have a culture where you work in teams, because you need all those skill sets interacting and interacting real time. So they can say, well, you know, that's your opinion, but in my opinion, are you crazy? And you can come up with the best possible state of affairs at any point in time. So people, you know, they're your asset. You're paying them a ton of money, use them, ask them to think, and use what they think. If you use more than one, which is good idea with software, have them work together and then say, you know, and this is just so for your benefit, we have a goal. We're going to work with you to check your progress toward that goal every so often, certainly in detail, maybe like every two weeks or every month, but for you in looking at each other every day, yeah, and to do this, you know, you need what's called transparency. What I would call is honesty, and that's not a highly valuable or known skill set today, and yet, if someone says to you, are you done with that for if you say, oh, yeah, and a killer of a job too, and you haven't even looked at it yet, there, you might do the wrong thing and you Created waste. So we're going to start introducing some interesting values. And so values become important, honesty, and all of that was what came together at that discussion in Austin, Texas. And we weren't describing all of that in depth. We didn't realize how deep of a culture change we were asking for, but we were describing a framework or a number of things that could happen across time that would engender all those things. And I think that was one of the big reasons people got so surprised by Scrum is when it engendered and required those attributes. Well, what do you mean? Then I was pretty honest. We used to give classes, and in the classes, we'd have exercises where people had a chance to tell the truth, tell what they really saw and tell what they really felt and thought or not, to cover it up. And over and over again, people discovered that they were used to the easy way out. And of course, you know, your parents say, Well, have you cleaned your room yet? Oh yeah, dad, oh yeah. We all learned very early, you know, that maybe shading the truth might be a good technique. And here we were saying, to really be successful with this type of work, you can't shade the truth. It might not be completely accurate, but give us your best. Best opinion impression. And you can imagine what people thought of that.
Dave West: 10:04
Some loved it, particularly the people building the things, usually. But then how that fitted into an organization is, is always very challenging. It's funny, you mentioned fidelity, you know, one of the earliest adopters of Scrum and and a fantastic company, you know, doing a lot of amazing things, but it took them a long time to reconcile the personal objectives that Fidelity has. Individuals, very individualistic, very, I wouldn't say, avoiding the truth, but definitely positioning the truth accordingly. And then, whereas scrum was sort of highlighting mistakes, early problems, Encouraging teamwork, requiring people to be flexible, all those things, and there was a, definitely a culture clash there, and it's taken them a long time to deal with that. Did you sort of appreciate that level of of culture challenge when you were because you were just trying to build stuff, right? Yeah, not at all. I was trying
Ken Schwaber: 11:10
to create an environment where people could build software more reliably with more value. And I had no idea. I thought, you know, maybe there'd be a parade down the avenues of Paris. There was a guy named John Cotter. I don't know if you remember him, yeah, yeah. He was from, I believe, Harvard, which, yep. And he recognized this disparity between value structures, for instance, at Fidelity and many organizations, if you're a vice president or anything, any role to get ahead, to get to the next position, to get more money, to feed your family with to send your kids to college, you had to fit in, and that meant not telling people what they didn't want to hear, except maybe in an extraordinarily careful crafting manner, so their values might be surviving, getting along, getting ahead, and the classic techniques we Have for that are, you know, lying, cheating, stealing, and you get put that into a team that's counting on clarity and transparency, and it falls apart. And what John Cotter recognized is the two cannot exist in the same organization. They can be in parallel, and you can when you're desperate or when you spot something that is really could be very valuable. You can do that and work on that research and build it in an organization that has the values that scrum describes. But if you are in a traditional organization that might be used to administer the products that you build, or to whatever that can't be the same organization. And John had a really neat book, which is your iceberg is melting, which describes this situation pretty well. I've kind of lost track of him, but I thought at the moment he really described it well,
Dave West: 13:22
yeah, and obviously he then wrote the book accelerate, which then described this idea of building these separate organizations, studios, as we called them. Scrum studio was an idea that we experimented with for a while, and they actually did this in many large organizations, and they found there was a an airline company, I probably can't say their name, but a large airline company, and they were doing fantastically. They'd built this studio. They were evolving. They built a totally different culture inside this digital part of their business. And then the antibodies of the existing organization took note that these people were suddenly the fave, you know, the favorites, and they did not like that. So suddenly they didn't have access to those API's, they didn't have access to those stakeholders. They didn't have access to the, you know, the legal department, or whatever they needed, or the web web deployment or and suddenly the studio started to fall apart because of that it is, and I think that's what Kotter found when he tried to build these he called them startups inside organizations, that the organization at a certain point, the existing bureaucracy and structures of the organization ultimately get fed up and and deal with with that. So I know it sounds maybe for our listeners are listening, and they're like, Oh, we're all doomed, but there have been lots of successes you scrum has actually, in my opinion, been fundamental to the. Amount of software like it or not that we're using today, because it has created this culture where people deliver more frequently, whether we call it DevOps or continuous delivery, a culture where people are trying to get to value goals we talk about the retrospectives and sprint reviews are now more common. The backlog is more common, those things. So there's definitely been some good things about Scrum. Are you ever shocked though, that millions of people are practicing scrum every day?
Ken Schwaber: 15:36
No, it's kind of like am I shocked that people look at what's happening and make decisions on it, no. And what scrum requires is you tell the truth. So I actually attributed agile, the agile movement and Scrum, with the burgeoning amount of software products that came onto the market, 9899 up through and including today, all sorts of places that were innovating used it. What I have also noticed, in parallel, which fits with John cotter's observation, was that organizations that based everything on agile and the values we discussed and used scrum didn't continue that way. The name of the company, a music company, Spotify. Spotify. Oh, yeah, the Spotify model, yeah. They use Scrum. They came up with some very innovative structures for and last I've heard, they've gone kind of more back into a formal structure and formal career paths and all of that. And that's what I've seen over and over again, is if you really need something, if you have a brilliant idea, if you really want to try something. Use scrum if you need a break, if you want to rest, if you don't have anything urgent or important to do right now, go back to the normal structure and just roll it along for a while. We saw that. I saw that really clearly at there was Motorola, oh, yeah, yeah, yeah, personal phones, yeah. And I'm there giving a talk about Scrum and, and someone said, Gee, you wish this is a lot like what the people who came up with the flip phone used? And I said, incredible. How many people were there? Said, Oh, it's a small team of like five or six, and no one thought we'd go anywhere. So they left them alone, gave them what they needed. I said, incredible. So they came up with the flip phone, and it said, so what are they doing now? Is, oh, well, obviously we can't change like that. So they're going around giving talks at Waterloo. And I'm like, okay, so good news is, I think we've come up with something that really, really works. The bad news is, it scares the Jesus out of people who would like comfort and relaxation and a large degree of certainty, it puts a huge demand on your values and your honesty and your intelligence and your ability to cooperate. But you know, that's what you pay to get something that you want. Yeah,
Dave West: 18:40
it is funny that organizations, at a certain point think there's too much to lose. It's almost as though risk becomes more important than value. Yeah, I've seen this over and over again, you know, I might have even been part of it. And is, you know, in in certain big companies, at a certain point, releasing things become so scary. You don't really want to. I wouldn't want to be a product owner and have the target on my back because it's so scary. But ultimately, that is the only way to innovate and to deliver value. And scrum teaches us over and over again. You have to get stuff in front of people, you have to get feedback, and sometimes you're going to make mistakes.
Ken Schwaber: 19:25
Well, Scrum also offers an agile in general, techniques, like you said, the product backlog that kept mainlined because there's no other way to do it. So we had a workflow product being developed in fidelity, and someone else was developing a variant of it in Salt Lake City, interesting, and tons of money being put into both. And we said, why don't we get them kind of like both? To be one product because they are supporting the same type of business. And the way they got that to happen is they said, Okay, well, let's look what you have coming up for the product coming out Salt Lake City, same in Boston, and create a backlog. And every month we will revise the backlog to figure out what to do next to the combined product. And if you're there, you get to say what you'd like, and we get to argue through and come up with what we want. If you're not, whoever is there gets to choose the direction for the next month. And people say, Oh my God, if that's how it's going to be done, I'd better be there. And the first sessions were very quiet, and then they got very grim and noisy. And then they became a way of doing business, because they realized they were going to be using that product. And that's part of Scrum, asking for honesty, is part of it, getting people to work together and agree on things, and it's also part of not wasting a ton of money doing things that are useless. Yeah. I mean, that's the
Dave West: 21:10
essence empiricism. Self management and continuous improvement are the other cornerstones of Scrum. So it's 2025, now, 30 years of Scrum since the paper, anyway, longer in real time, llms ai have become huge part of the discussion the narrative in organizations this technology, some people say it's going to be as big as the printing press. It's going to revolutionize everything. And, you know, I use it. It's certainly useful. What do you think that is? I mean, Scrum is all about people working together to deliver value. What happens if some of those people are AIS, what happens if we it's not just teams? What's your take on that?
Ken Schwaber: 21:59
Ken AI is they are tools, yeah, now when an AI gains sentience and can sit up next to me and talk to me and share ideas and be open and take criticism and be you know, sentience is being conscious and self aware, and those sets, those are some of the things that we'd like for a team member. So I'm all for anything as a team member that could display those attributes and work with me on a team. In the meantime, to me, What they are are tools that could help team members.
Dave West: 22:43
Yeah, though, I have to say, I have worked on some teams where I'm not totally sure some of my team members were sentient, but, but you know, let's give them the benefit of the doubt. Yeah, people,
Ken Schwaber: 22:57
are you sentient?
Dave West: 22:59
I'm sure some of them have failed the Turing test, that's for sure, some of my teammates. So the it is interesting, the as a tool, particularly these large language models, what I found is that the ideas of continuous inspection and adaption, transparency, challenging the outputs of these things is crucial, otherwise you'll end up in a mess and and that's what scrum tells us. And you know, maybe my sprints are going to be a bit shorter because we've got tools that help me be a bit faster, but ultimately, it just amplifies Scrum, doesn't negate it or really change it
Ken Schwaber: 23:40
really so that would be like those old computer and software engineering and object oriented tools that helped us build software, except now we've got aI anything you can use to improve the outcome is fair game, yeah, and
Dave West: 24:01
if it can help me be a little bit more cross functional, meaning, it can help me do things that I perhaps would historically have not been able to do, like do math and stuff like that, then I'm game on that. And it's incredibly useful.
Ken Schwaber: 24:16
I think we have some great examples of it being misused. So scrum agile very hard topics to present and discuss and learn about, except through example or through learn yourself on the job. And yet, what I've seen lately are some people trying to write books about Scrum and how to do it, and who use it, and they have aI writing these books, and the outcome is as flat and tenuous and uninstructive as you could imagine. So I think everything has its place. Everything does have its place. Yeah, so we're getting to the end of this podcast. And I guess you know, when you look the next 30 years, where do you think? What do you think is your hope for Scrum? What's the future of Scrum? If you were going to describe the future of Scrum, what would that be? I would hope it helps people. So for instance, all that a doctor uses it is inspect and adapt. So they're always looking and getting more information, more information, and they're trying to apply better and better tools, a little like us developing software. Yeah. So I hope that that whole approach of accepting empiricism in your daily work and the values that it requires is what happens if we've seen it grow a lot, I'd like to see it grow more and expand.
Dave West: 25:55
10 years ago, when you offered me the position of CEO here at ScrumOrg, we talked quite a long time in a in a breakfast place in Lexington mass. And the reason why I joined, other than your very strong personality, that encouraged me was was really that it's about helping people. I've been to so many companies like you have, and people are just so, I don't know, say down, sad, uninspiring. They just sit there, doing their jobs, going to meetings. And yes, they're trying to add value, and they're trying, but a tool like Scrum, it just unlocks so much human potential, and I would love to see more humans applying scrum every day. That's my, that's my that's the reason why I'm still here. That's what I get up every day. You know, I might not do a good job always trying to do that, but that's what inspires
Ken Schwaber: 26:54
me. Well, we look at our territory in our backyard, and it's software development, but you can see how things like honesty and cooperation collaboration could play very well in politics, in global affairs. So if we started anything that spills over into those areas, that'd be great. I hope we started something like that going because we certainly need it as a culture and as a world.
Dave West: 27:32
That we do it is not quite in politics, but Scrum is being used in organizations like dyno therapeutics, which is doing genetics research, machine learning and genetics research to solve some of the most horrendous genetic problems, illnesses, conditions that plague mankind. And so we are seeing it applied in those contexts. And it's getting scientists to work together. And you know what scientists are like, they sort of, they hold their in from their cards very close to their chest until they're published, right? So getting these people to work together is a great power that scrum provides, and that honesty and that transparency is certainly changing that organization, and I'm sure many other organizations like that. Ken, thank you for spending 30 minutes today talking about Scrum for 30 years. So is there any last words to our listeners that you'd like to
Ken Schwaber: 28:33
impart on them? Something I saw happen, both for myself and for other people that use Scrum effectively was people felt fulfilled, and that is a great thing to wish for everyone. So I'm wishing that everyone gets advice and support if they're trying to do better, and that includes inspection adapt to adaptation and the values we've talked about, if we've caused anything like that to happen, and we can help people take advantage of it, all the better. That's great. Words of Wisdom. Thank you. Thank you. Dave. So that was Ken Schwaber, the CO creator of Scrum, my boss. So it's
Dave West: 29:25
always a little bit nerve wracking. Thank you for listening today's ScrumOrg Community podcast. If you liked what you heard, please subscribe, share with your friends, and of course, come back. Listen some more. I'm lucky enough to have a variety of guests talking about everything in the air, professional Scrum, product thinking and of course, agile. Thank you, everybody, ScrumOrg.