Dr. Jeff Sutherland invented Scrum to help people make better stuff faster and have a good time doing it. Avi Schneier helps Jeff do that, specializes with Scrum outside of software, and shares how using Scrum with large firms led to the Scrum at Scale G...
Dr. Jeff Sutherland invented Scrum to help people make better stuff faster and have a good time doing it. Avi Schneier helps Jeff do that, specializes with Scrum outside of software, and shares how using Scrum with large firms led to the Scrum at Scale Guide for multiple teams. Avi Schneier is a Principal Consultant at Scrum Inc. responsible for international needs in the Asia Pacific region and some Fortune 500 and 200 clients in the United States. “A bad attitude and a Brooklyn accent goes a long way to get leadership to listen to you.” Avi shares how any organization can adopt Agile and Scrum and why the framework goes beyond Plan, Do, Check, Act (PDCA) Lean Thinking.
YouTube Video at https://youtu.be/XWdzyaFR97A
Follow Avi on LinkedIn at
Today's episode is sponsored by the Lean Construction Institute (LCI). This non-profit organization operates as a catalyst to transform the industry through Lean project delivery using an operating system centered on a common language, fundamental principles, and basic practices. Learn more at https://www.leanconstruction.org
The EBFC Show Intro Music: California by MusicbyAden https://soundcloud.com/musicbyaden
Creative Commons — Attribution-ShareAlike 3.0 Unported — CC BY-SA 3.0
Free Download / Stream: https://bit.ly/al-california
Music promoted by Audio Library https://youtu.be/oZ3vUFdPAjI
Avi Schneier 0:00
Scrum beyond IT. So, if you if you work with IT organizations, most people are actually starting to be like you it's very difficult to find a way in it who's not familiar, like they haven't heard Scrum or agile. Everybody knows it's from this vein of business. So the, the, the obstacles you meet there are, okay, so it works in software fine, but it can't work in my company, and my company's a silver unicorn that pokes rainbows. And, or, or it can't work in my in my vein of it. So I'm sure we can work in app development. But you know, we're still doing mainframe legacy systems. It can't work there. Right? You always meet those two objections work here, or it can't work in in my domain or whatever you want to call it. When you go outside of it. That is magnified 1000 times.
Felipe Engineer 0:53
Welcome, Avi Schneier, to the EBFC show. So glad to have you here. Yeah, good, man. You're excited. I know you want to talk. I love the excitement. Go ahead. I'm keeping that in. Welcome to the nbfc show, the easier better for construction podcast. I'm your host, Felipe Engineer Henriques. This show is all about the business of construction. Today's episode is sponsored by the lean construction Institute. LCI is working to lead the building industry and transforming its practices and culture. Its vision is to create a healthy and thriving industry that delivers outstanding project outcomes every time for everyone. Check the show notes for more information. Thank you, LCI now to the show.
Avi Schneier 1:46
Thank you, Felipe. sincerely appreciate it. Yeah, my name is Avi, I am principal consultant with scrumming started in the business. Many, many moons ago, as they say essentially, as Dr. sutherlands protege used to live in the public class world with him. You know, it's really assisting and learning, learning Scrum from a very academic perspective, right? I would say my career started by literally being a parrot, a parrot of whatever Dr. Sutherland said. And about eight or nine months into it, he turned to me one day, because I was after I taught the class, and he's like, he's like you, you got to get out of here. And I'm like, No, like, and I'm like, what he's like, he's like, Yeah, he's like, you know, now what you're supposed to know in order to be able to do it. But now you have to go do it. And so he essentially threw me out into the cold now it's his boss pushed.
Felipe Engineer 2:38
He pushed you out of the nest. BOOM!
Avi Schneier 2:40
Did he put, he did, he pushed me out of the nest, he really did. So one of the things I did in those early days, because I came my background is my background is very, very what part of it is sales. So in those days, I also helped to cultivate the accounts and people we met in class into larger engagements. And so I cultivated my first engagement with a marketing digital marketing company called ignition one. And he basically said, okay, he goes, you cultivate that relationship now goes from the client. And, and I went down there, it's a great company, it's still around, they've got a branch in Japan, down located in Atlanta, Georgia, a really good company, awesome, people, great product. And we went down there, and we scrubbed the hell out of them. We had a great time, it was a tremendous success. And that was when my career track changed from being just somebody who understood them academically, and could explain it to people to actually going out and doing it in the field. So one of the reasons why I was chosen as a trainer was because before all this, I was a school teacher for for 14 years. The science a science educator, right? Yeah.
Felipe Engineer 3:45
Avi Schneier 3:45
So it was funny, because I always tease Dr. Sullivan. And I'm like, you know, you gave me the easiest teaching job I ever had. I don't have to tell anybody to sit down, shut up, take your hat off with none of this stuff, right?
Felipe Engineer 3:58
It's over your students when you're teaching those 14 hours.
Avi Schneier 4:01
I taught high school. Ages 14 to 18. You know, like traditionally speaking? Yeah. So yeah, so that that's how I got started from education into an education of this and then now implementation and consultation. So you know, after after ignition one, I went on to work with a lot of other companies. And then eventually I got tapped to work with the biggest companies my my company deals with so I work now I only work with really, and I've worked with startups Don't get me wrong, like that work with 10 people at one team, right. But most of my clients, if not all of them right now, our major industrials, fortune, fortune 500, fortune, fortune 200, even, right, we're talking really big companies that are trying to do this. And when people ask me, how did you make that switch? I always tell them the same thing. Apparently a bad attitude and a Brooklyn accent goes a long way. Forget leadership to listen to you. It's certainly true. Isn't this certainly isn't my Mona Lisa smile?
Felipe Engineer 5:03
No, when I first met you is like a couple of weeks ago, I heard your voice and right away I was like, Ooh, this is I like this accent I want to hear more about how different it is...
Avi Schneier 5:14
You just you just made me remember a really funny story you just really, really nice. So I went down to we got hooked up with with a guy who was running a department and was in one of the largest banks in Australia. Okay, one of the big one of the big three. And he came all the way to America to learn Scrum at scale from us. And it turns out that I was teaching that class not about the song, I'm one of the. So in the beginning, it was only Dr. Sutherland and me teaching that class. That was it. And then there was one other person who then left and then it was just me and him. And then I started teaching them by myself, right. And this guy came all the way from Australia to learn. Because I talked to him on the phone. He's like, I'm coming. I mean, you might have to somebody flying. It's not just across the world this way. It's across the world this way too. Right? You know, it's like, it's like, really across the world up and over. Yeah. And he came to class, we had it, we had a great time, he learned a tremendous amount. And he's like, he's like, I'm gonna bring you to AWS. He was American, by the way. He was not okay. Like, I'm gonna bring it on. Because I don't know, I don't know how when I want to take I'm going to cause we're going to do this. It took six months of planning and isn't that we finally I finally went down to Australia to the bank, and helped him fix a ton of problems. I actually went back twice. It was a really it was it was a long, long engagement. We did a lot of a lot of stuff together. But the reason for the story is the funniest thing was the one day I'm doing class down there, right? Yeah. And I'm teaching this class. And there are these two women in the front row. And they're just like, smile, like smiling up and I'm like, I'm like, oh, like, I'm doing amazing. This is a great training class. They really they're getting it. They love it boba. So I go with it. And I'm like, and I said, Oh, so are you really getting into understanding? Are you having you know, you have any time? And they're both like, they're both like, Oh, no, what we really love is your accent. It's like taking a scrum class from a guy straight out of Goodfellas. And that was like that. I'm like, that's what you're taking out of this. Yeah.
Felipe Engineer 7:11
Yeah. Yeah, American movies have made it all around the planet for sure. It was really, really funny. Really fun to want to put a link for people so they can contact you to record their voicemail messages. Oh, my goodness. Yeah. So the the scrum at scale class that he went into, that's something a little different and unique. I think, you know, people listening to the show, they've probably if you've listened to even one episode, you've heard the word Scrum at least 100 times. So like, Could you just tell people what is Scrum at scale? They might not know what it is. Yeah.
Avi Schneier 7:48
So a lot of people are familiar with the scrum guide. Right. You know, Dr. Sutherland, you know, he he put that guide out with with his with his former business partner, Ken swaybar. And they put it out in 1995. Like for free.
Felipe Engineer 8:00
I mean, it literally is still free today.
Avi Schneier 8:02
Still free today. They have never I always tease I always tease Dr. Sutherland. I say, I say How come you didn't put a trademark on this. You didn't put a copyright on like if you got a nickel for everything they would Scrum I always say you could have been another Silicon Valley, you know, kajillion. I would Bill Gates. And he comes back. And you know, a lot. A lot of people don't don't know, Dr. Sutherland, well, and that's because they, they judge him based on certain things instead of actually talking to him, because he's actually like one of the nicest guys you'll ever meet. And he says, He always says me because I didn't we didn't invent Scrum. For that reason. We were trying to figure out how to make people how to help people make better stuff faster, and have a good time doing it. He always qualifies that have a good time doing it. Now, a lot of people think that Scrum is all about, you know, just about delivering fast, fast, but it's not. It's not. It's it's if you think about it, right? Because it came out in like 95, right. And here we are playing right? It's essentially a 25 year experiment into how human beings can work better together. That's actually what it so when he can put it out. It was for free. They were just trying to figure out how can we help people do something that are the right way when it obviously was back in software was only software back then. Right? So that's what they were looking at the field of software engineering and and in that sense, you know, it's funny, like I kind of think Dr. Sutherland is one of the greatest philanthropists we know. Like everybody knows, everybody knows Bill and Melinda Gates, right. They all know, the Bill and Melinda Gates Foundation. Yeah, yeah. But who did Bill Gates give a dime or $1 to before he had Microsoft? See that now? You don't know. I don't know. But Dr. Sutherland has been given this away since the start. And how many people do know if you go on LinkedIn, or Glassdoor? There are literally hundreds of 1000s of Scrum jobs out there. Yeah, all these people receive it was all for free. All free doctrine doesn't care, you want you to make good stuff for people solve problems, faster, better solutions, and he wants the people who are doing this to be happy. So what is Scrum at scale? Right? Yeah, the scrum guide is how to do this for one team. And in that sense, it's really a very focused and limited documents very short. Matter of fact, they're coming out with a new iteration, hopefully in the next few months, because it's a living document. See, there's another difference between the scrum guide and like other things you see, right? It's not, you know, I'm from, from, from the Jewish tradition, right. So, unlike the greatest document my people made that was written in stone. This one, this one's been pretty flexible over the years. Little change it right, every couple of years. They change it, and they update it with learnings or findings from the field. But still, it's about one team, one team. So obviously, we need to do this at scale. And there are many different scaling frameworks available. Scrum at scale is the version of how do you scale Scrum using Scrum? So a lot of other companies have other scaling frameworks. We're not here to talk about him.
Felipe Engineer 11:15
We don't care. But we're biased. You and I are extremely biased. We both love Scrum. Yeah. And I love spending time with Jeff to just probably, maybe not as much as you do. You're You're spoiled that way.
Avi Schneier 11:26
You get more as well that way. So the idea behind Scrum at scale guide. So the idea behind Scrum at scale was born in Jeff's head from his earliest practices up until inventing Scrum. And then through However, he implemented it in a scaled version in the 11 companies that he worked at. And this has been for literally, you know, 10s of years. So, the codification of Scrum at scale, though, did not happen until much, much, much later. Much, much, much later, he sat down with another employee who's not with us anymore, but named Alex Brown, and another guy who works in our company still Patrick Roche. And they tried to help they tried to help doc synthesize all of his ideas into a distilled framework. And so they and so that's when Scrum at scale really started to get codified. Then it's funny, we mentioned it's funny, we mentioned the bank in Australia, right? Yeah. Original Scrum at scale diagram looks very different. It was actually two concentric loops. That's where like when I joined the company, okay. And I meet this guy, he and I go down to Australia, I go in there, fix their implementation. And when I came back, I said, Doc, we have to change the diagram. And he's like, What do you mean? I said, it's like the loops are wrong. Because there's one inside the other, we need to separate them, we need to make it the two rings with the intersection in the middle. No, that that specific change happened after the implementation of, of Scrum at scale, the way he had taught me helped me to envision it on site. And then we were Scrum. we iterated there, the diagram changed. And then I said to my, you know, I said, I said, Joe, you know, he had been thinking about it for a long time. He said, You know, maybe we should make a scrum at scale guide. And then after I said, we change the diagram. He's like, you know what, Avi, let's sit down and do this. And so he started it. And myself and Jessica Larson, and Alex Sutherland, his grandson, and Patrick also helped, we helped to edit the very first one. And then you know, and so I'm an editor and a contributing author of the scrum scale guide as well. So I've just stuff in there from especially the most recent one. Yeah. So I'll tell you this. I'll say this publicly, I'll say this publicly. So when, when we when when Jeff said, Okay, let's make a scrum at scale guide. I had a certain idea behind it, which I will readily admit was mine and failed.
Felipe Engineer 13:47
What is it?
Avi Schneier 13:48
The Scrum guide is owned by Jeff and can jointly, right? No, no changes can be made unless the two of them agree. And I would see the I would see the request for changes. So one thing that they did, Jeff and Kate had the insight to doing was to open it up to the peanut gallery, as we say in Brooklyn. Basically, anybody can comment and write in a request, hey, I think this should change. And year after year, I would see even the most popular request for alteration get rejected. Now at the time, I had never spoken to Ken swaybar. So I never could never understand it. Now. I've spoken against you ever many times. And I completely understand all those changes. And he was right let me just say that he's right. Jeff and him were like these this should be in there. I was always hanging out like no, it should be in that I was wrong. They were right.
Felipe Engineer 14:44
What What did you want in there all the velocity.
Avi Schneier 14:48
Oh, I really wanted I really wanted backlog refinement as an event. Okay. And I really don't like the phrase development team because my personal journey is Scrum outside of software. And so when you're working with a marketing group, they don't see themselves as developers, right?
Felipe Engineer 15:10
Hey, I'm in construction, I'm, I feel the same way. I change the phrasing a little bit project team. makes more sense for us.
Avi Schneier 15:19
But the lookout, I could see a rose by any other name smells sweet. My point is that the language of the guide, and they're doing this in the newest iteration, let me not say that my idea is that the language of a God of a guide, if it's this is this is the canon, this is the, you know, this is the canon, this is a clinical, right? The language should be as inclusive as possible, it should call people in not peep not make people feel excluded. And when you use the phrase developer and development team, you're already you're already kind of pigeon holing it towards software. So there were a lot of requests to change that the delivery team, they didn't do it. And that's okay. That that's something that people can make the suggestion that wasn't my suggestion that was that that was that was the, the interweb or whoever you want to call it right?
Felipe Engineer 16:05
Peanut gallery. There you go.
Avi Schneier 16:07
So when someone Jeff, when Jeff said, Avi, let's go make this go mid scale guide, I said, you know what I said, instead of the way you did it with Ken, I said, let's do it. Where? Because we were opening up the scrum at scale training program. I said, let's make it so that the other trainers that join us can have input into the guide and change it. And in the beginning, it went really well. Because we came out with the first iteration, and we don't you know, we have our vision, but everyone else has a different vision. So it became wider. Unfortunately, too many cooks spoil the broth.
Felipe Engineer 16:45
Yeah. What do we learn about team size? Avi?
Avi Schneier 16:47
Yeah. So when, when the team size got to 82, we had 82, swimmers, skilled traders, and everybody was sticking their fingers in our cake so to speak, although it didn't taste so good. And I looked at the last iteration, and I was like, this has gone way off the rails. And we got to rein it in. Now, the newest version is exactly that. I worked very closely with Jeff, very rare we were on I was I was working in Israel, believe it or not, I was doing a transformation in Israel. And I was on the phone with him in the middle of the night. Because we had to get this we had to rein it in, we had to get it right, we had to put it back towards what the original was. And we worked very closely together with another person who's on our team now, Elizabeth Frazier. And we helped to set it back in the original direction where it was intended. And now I think the newest version is actually way more readable, much cleaner, much more inclusive. For for people who are not software oriented to read it and understand. Okay, so that's what this that's what these terms mean. That's what I could do. Because the the notion of it is that what's the minimum amount of stuff I have to know in order to start doing this? Right, right. So we are coming out with something more specific. And Jeff and I started the first iterations of this as well the Scrum and scale Field Guide. So similar to what we have in the book selection, right. And this will be an implementation handbook. And this one is where I want everybody to contribute. Yeah, I realized I realized the guide should really stay with with with Jeff and everything he thinks. And then the implementation that the handbook we really want everybody to, to have input, because I haven't done it in construction yet. So if we want to put it if we want to put in a section that says, here's how you do is in construction, then I need someone like you to call us up and say, Hey, I can help write that part.
Felipe Engineer 18:47
Yeah, I have my hands up. I'm done.
Avi Schneier 18:50
I knew it would. And so the handbook that will be coming out, hopefully by the end of the year, I hope and I may actually, because I'm kind of in charge of the release of it. I'm actually release it in in iterative parts, because hey, we're Scrum. Why not release it? I should say increments rather than iterations. Right? Why not release it incrementally? Sure. We may actually put out increments one at a time and I'm actually I'm actually finishing the edits on the very first increment right now. And I may just start put that up for commentary into the into the trainer's group first before the horse goes live.
Felipe Engineer 19:23
I'm sure they'll they'll like they'll light you up, as they say, light you up. Let the flame wars begin. But it is great. You know, I met you at the scrum at scale course. I think Jeff brought you in. And you got to share some stories. So for people scaling, I mean it is I've read the scrum scale guide before that was pre reading for the course and it is it does read easier. And then you know, I work in a large corporation. So in my my corporate indoctrinate itself, it makes total sense.
Avi Schneier 19:57
Thank you. I appreciate that. We really work very hard. And a lot of that I'll give, I'll give credit where it's due. A lot of that actually was Elizabeth saying some of this language is is is a barrier for people who either aren't software oriented or actually what the real barrier was, was people who don't know Scrum. And this is a very common thing is we will have people come into the scrum at scale class, because of their position in the company knowing, hey, I don't know what Scrum is. But I got 100 teams that are think, Hey, I should take Scrum scale, and they don't know anything about Scrum. So we tried to make the guide readable, but with an understanding that listen, before you pick this up, you need to understand Scrum first.
Felipe Engineer 20:38
Yeah, and, you know, for those of you that don't know how long these guides are, they're both magically 19 pages long. So, you know, spend, spend as much time as you want at a coffee shop and digested at least a good read. And there's a lot of good stuff. scrumming. Let's plug scrumming. So YouTube age, there's some good videos out there that that show what Scrum is what good Scrum looks like. And also the there's a lot of case studies and a lot of people still like case studies. For some reason, Avi, I'm not a huge fan of case studies. I've got case studies myself, but I'm more of a fan of let's let's get dirty with it. Let's get down and in.
Avi Schneier 21:17
I'll tell you what, I'll tell you where that comes from. I'll tell you where that comes from. And, and I'm probably one of the few people in the business that probably meets that more than most only because I'm scrubbing beyond it. So if you if you work with IT organizations, most people are actually starting to be like you it's very difficult to find a way in it who's not familiar, like they haven't heard Scrum or agile. Everybody knows it's from this vein of business. So the the, the obstacles you meet there are, okay, so it works in software, fine play can work in my company, and my company's a silver unicorn that pokes Rainbows, and more, or it can't work in my in my vein of it. So I'm sure we can work in app development. But you know, we're still doing mainframe legacy systems, they can't work there, right? You always meet those two objections, or they can't work here, or it can't work in in my domain or whatever you want to call it. When you go outside of it. That is magnified 1000 times. Because Because unless they unless they hear that somebody else has done at first, there's no possible way for them to even believe it can work for them. And so we reason why the case study library and Scrum scale has a huge case i library we do too. But a lot of what you're seeing online are the so one of the things that we made different for becoming a scrum at scale trainer versus becoming a trainer of x system was you actually have to do it for real. No, a lot of people out there training Scrum, you have no idea if they've actually done the will not and it'd be good. You can't tell I know no requirement, there's no requirement for you just have to be a good trainer, which is okay. But to be a scrum at scale trainer, you have to have done this for real in the wild at scale. And so part of your requirement is to film a case study of what you did. So that's why we have that big library. And there's even more coming out that are in the Can I just haven't been published yet. All over. And the importance of this lead base for us to be able to put out different size companies, right? Because when people say, Oh, sure, it works for two teams, it can't work for 20. It can't work in three words, Amazon's got over 3000 What are you talking about? Yeah, Amazon's not run by magic fairies. It's run by intelligent people like you and me, and the people that we work with, right? And they'll say it's not going to work in my size company. So you have to have case studies of different size. Although say it can't work in a company like mine. So for example, if I'm working with if I'm working with an auto manufacturer, I need a case study from a different auto manufacturer. It doesn't work if I have a case study from from from from from a consumer packaged goods company, that that can't work, even though it's still it, what are you talking about? And then it goes to domain knowledge. So a lot of people have trouble translating what was done from software into someplace else. Without any understanding that Scrum actually is born from a hardware, all of the papers, all of the books, everything that gave rise to Scrum and agile had nothing to do with software, the total production system with software that's what gave rise to lean. And the book that gave us the name agile, which was held up by Mike Beadle at at the famous meeting in Snowbird when the Agile Manifesto was created was about Lean manufacturers going beyond right and when they when agile manufacturers go beyond lean manufacturers by inviting the customer in. So it was all a discussion around hardware manufacturing, nothing to do with software. Dr. sutherlands genius. By the way, in my opinion, was being able to see those things, see the benefits of lean manufacturing, and bring it into knowledge work. That's what he did. And he and he looked, of course at the paper by talking about, you know, knocking all of the companies in those people, all hardware companies know all what they were doing. And he put that into knowledge, right. That's what the genius was. So when people can't make that people can't bridge that gap. It's because they can't make that same jump back. We have advised large automobile manufacturers around the world. We have advised large chain break manufacturers around the world, other hardware manufacturers outlet even little ones, like you would think of outlet you could look this up on the Google a great product made with Scrum, Allah, it's this little bracelet that you put on the ankle of a baby's leg that connects to a pan a sensor underneath them that detects whether or not they stopped breathing. And it alerts the parents they can come in and avoid Sudden Infant Death Syndrome, you know, SIDS, which is a horrible problem. No product is made with Scrum. Those guys came to a public class, Dr. Sutherland I did like four years ago. And then they took off on their own. And they did it and they're awesome. They're awesome. Yeah. So but a lot of people can't make the jump. They can't make the jump to marketing, to sales, to procurement. But these are all things that we have now successfully Scrum. So we have to put the case studies out. Because the bottom line is, unless you can speak to that person, in their language. And in their frame of reference, it becomes very hard to bring them along on the journey, because they're already throwing up all these blocks. Right? They're throwing up their own impediments. You have to be able to tear them down. Yes, it works in a company of your size. Yes, it works in companies just like yours. And yes, it works in your domain. And here are all the examples how. So your only possible excuses. You just don't want to do it.
Felipe Engineer 27:01
Like you don't, I always tell people, you don't have to be awesome. You can just get by. I mean, you gotten by this far. That's what, you know, somebody asked me was doing a, like a high level Scrum class and construction this week. And, and somebody said, like, why did you even do it? And I said, you know, for me, personally, I couldn't keep up anymore. I couldn't keep up with the demands of what the job was and what it would take to be successful. And I needed something else I'd my organization skills were lacking to put any other way. I wasn't I wasn't a bad employee. I wasn't close to being fired or anything. But I just couldn't keep up with what the customer needed. And it wasn't until I started using the scrum framework that I was able to keep up and then make the customer hire more people to keep up with me afterwards. Which was it was awesome.
Avi Schneier 27:53
And this is a very common occurrence, right? The grassroot effort that then you know, and this is if you think about it, right. And I write this in this by the way. This is now part of the new handbook that's coming out, right? is most of the original Scrum transformations, right? The original like Scrum at scale transformations all started this way. One person comes in as a champion converts one team over that team does great. Management notices, and says, What are you doing? Other teams notice? Because you're getting all the kudos. And they're like, hey, I want I want to get a piece of that, too. Yeah. And then you have this grassroot efforts of what what some people call a bottom up transmission. I don't like that phrase, because I'm not into the levels business.
Felipe Engineer 28:40
I've never heard rocky guy.
Avi Schneier 28:41
I know I'm not happy. I really prefer the idea of how about we use the phrase team inspired. Even inspire transformation. Okay. What we find today is, so those transformations have limitations. Because until you get the executives to be behind it, a team inspire transformation is always doomed to fail. The minute it upsets the wrong manager, then it's over. Because they'll squash it, right? Yeah. More often than not, today, we're finding let's call them executive inspired transformation. Some people say top down, I'm not using that executive inspire transformation, where I have literally had a CEO of a company call me up say, Hey, I read this book, and like the yellow book, and you're in it, how'd you do this? Right? where people would have read the Red Book, the original book by by by Dr. Sutherland and JJ Scrum, you're doing twice the work and half the time. So that book was on like, it was an eye flip. I used to find it in the weirdest places. We I once found that it was a book an audio book on a flight I was on I was like, how does get here? People like an executive would be listening to this book on a plane ride. Yeah, get off the plane and literally call us up or emails immediately. I don't know who your people are. But you got to come in and speak to us. Yeah. So you get the ear of one executive says I want to do this. And so we have this notion of the executive inspired transformation. This is what we're dealing with more often than not because again, Scrum has now progressed to the point where it's more common. Agile is a buzzword. You know, every other article in the HBR is about agile.
Felipe Engineer 30:21
Yeah, guys, you guys made the cover of HBr. I think it was a year ago. Yeah. Jeff was on there again, with I saw it. I was in Nebraska. And I was walking by the book, the bookstore on my way to the airport. And I was like, Whoa, I know that guy. Look at that. It's on the front.
Avi Schneier 30:37
And they had to, like, prominently in the beginning, though, if I said, I'm surprised at the age gap in Nebraska. No, I mean, that's where we love you Nebraska. You're full of very smart people.
Felipe Engineer 30:49
There's a lot of billionaires in Nebraska Avi, of course, that's probably why it was there. Exactly. Exactly. We love you, Nebraska, you're the best to keep growing. I think that's the interesting part. You know, a lot of the other frameworks, I've seen diagrams, you know, there's some competition for different frameworks. And I can't think of one that shows the customer anywhere in it. Yeah. And that's something that's really different with Scrum and puts the, the client, the customer front and center in the process, like you'd like you were saying in that original agile book for the manufacturers bringing the clients in to see what we do. And that's been something really different.
Avi Schneier 31:28
It's all about that, you know, customer centric. I mean, it would be we would be we would be allies, if we said because customer centricity is new, right, we'd be lying if we said that customer centricity around for a while. But organizations just because they know the words, don't mean they're actually doing the practice. Right. That's really what the that's what the problem is. The problem is that people don't know what know what cut customers interesting is, people don't know how to actually become customer centric. That's what that's where the disconnect is. Right? And, and, you know, it's like the major disconnect, I shouldn't say that. I would say one of the major disconnects that I see being done in most Scrum implementations that I come in to clean up, right is, you have product owners that speak to internal customers and stakeholders. But for some reason, there that is becomes a layer in between them and the actual user. So it becomes a game of telephone where my job in order to keep my job as a stakeholder in a program manager, whatever I am, I have to talk to customers, you never speak to them. And then I tell you what they said. What that what the hell is that product owner should be talking directly to customers and directly even to end users, the people that actually consume the products that they make. Otherwise, you're relying on secondhand information. And you might have very different questions. And they have so like, just another example, right? Outside of software, okay. tend to consume in the consumer packaged goods industry, you know, people that make things that we eat, it's very common that marketing teams go and do the research. They talk to the people that eat the food that look at the packages or buy stuff. And then they go back and tell the innovative teams Hey, this is this is what we need next. I'm not saying the marketing people are wrong. But often they are. If they weren't, you wouldn't find so many consumer packaged goods products that fail. And we could everybody watching this. everybody watching this program could could at least think of two or three products in their head array like oh, yeah, I remember when I ate that was terrible why they make that?
Felipe Engineer 33:36
Right, we all we want. Like, we literally ain't...
Avi Schneier 33:37
Like why did they make this? Why did you make that? And what if you had had the people who make the stuff talk to the same customers? They might have asked very different questions. That would have gotten very different responses. That would have led to very different products. You can google it yourselves. Campbell's Soup did this. Campbell Soup. So this is a consumer packaged. No, the problem. I'm going to tell you can I tell you it? Can I tell you the case study. So you have any kids, Felipe?
I do. Who's 10? Okay, great nine year old boy.
When he was a little when he was a little kid. I mean, a little kid, like four, 3, 4 or five years old. What was his favorite snack? A cracker?
Felipe Engineer 34:20
Animal crackers. That's a sugar. That's sweet one. What about a safe one? Whatever. No, no, no, we enjoyed any goldfish? Nope. He didn't. He didn't like goldfish. He also doesn't like chocolate. So he's the oddball kid. I said, your kid is that your kids out out of the sky? He's out of discussion. We'll pick somebody else.
Avi Schneier 34:39
Most kids including mine was four years. Most kids United States the number one snack cracker. Is goldfish. is the number one selling cracker in their age demographic in the country. I don't know who the hell knows maybe the world thing is the people who can go fish like nuts, right.
Felipe Engineer 34:55
I've seen a lot of kids eating them. everywhere I go. Yeah, if I see little kids events They're eating goldfish crackers, like at the airports. And when I used to fly back in the day.
Avi Schneier 35:05
Right, it's perfect. The tan side, it's got a little smiley face on, everyone knows, right? What happens though. The kid hits nine years old. And that and the consumption of goldfish straight to zero. Because that's my baby cracker. Oh, yeah. So they out they don't really outgrow the taste. They still love the taste. But they outgrow it because, or maybe they do outgrow that taste, right? That's another factor. Right? They might outgrow the taste, or they outgrow the idea of that's my baby cracker. I'm grown up now. So the normal time it takes to develop a new snack at Campbell Soup was about two years. They wanted to fix this problem of kids literally going from I eat this crack everyday all the time to zero. This is the article they wrote themself, you know, full, full disclosure, scrumming had nothing to do with it. This is a self published case study by themselves. Why does it take so long, separate groups doing the marketing separate groups doing the innovation, separate groups doing the taste testing separate groups, then doing the marketing on the post production side, waterfall schedule, waterfall scheduling and silos. They said screw it, they may cross functional teams, they went to do it in an agile way. Nine months, and they launched goldfish epic crunch. You can look it up. It's a real product still out there. It's still successful. Adult flavors Ranch, honey barbecue, nacho cheese.
Felipe Engineer 36:41
I'm not very hungry. Not just chatter right now it's working.
Avi Schneier 36:47
So the idea was the kids wanted an adult, an adult flavored and an adult sounding cracker. And parents wanted something that was still baked and not fried. Many of those corn chips today that we know that kids graduate to are fried and were much less healthy for you, these are still baked. So they were able to satisfy if you think about it, the two customers, customer number one, the parent who buys it. And customer number two, the kid who eats it. And that's why they got a winning product, because they brought agile into food production. And we've helped other companies do the same. But Campbell Soup says so publicly. So you can even Google it.
Felipe Engineer 37:26
We see the same type of thing. And in the construction, and even design industry to especially I've got a lot of design friends, architects and engineers, and someone on their team will have a good relationship with the client. And that person has to try to translate what they heard in a meeting or on a phone call, or an email, which is the coldest form of communication second to, to just like contract documents, an email, you could go back and forth, but not ideal. And then you see the people doing a lot of things. And it's not. They get it eventually front of the customer years later. And it's like that's not what I wanted. Not even close.
Avi Schneier 38:04
You know, when I talk about stuff like that, in class, I always give this analogy I always say, Who here has had an argument with a significant other over a text or tweet? And everybody raise their hand? No. Okay. So basically is saying you have no ability to communicate what you want in 140 characters or less. And somehow you think a document like this is going to be somehow better? This is why they invented emojis. Yeah, because literally half of the messages I type. If I don't put the smiley face at the end, everybody thinks I'm a jerk. I mean that right, but not as bad as they really think. You know, yeah, we're just human beings are just not pure. We're not all pupils or prize winning authors. If we were we'd all we'd all be in a different line of business. That's the truth. So in order to in order to really get to the heart of the matter, it's all about the conversation. It's all about the conversation, right? I cannot look at a document. And I'm going to come up with a litany of questions that I'm going to send back to you and it becomes this incredible long back. Why don't we just sit down and talk to each other? You know, like, how many times have you had a back and forth text with somebody that got heated or went way off the rails that if you'd literally just been on the phone for 60 seconds would have been totally fine.
Felipe Engineer 39:23
Oh, oh, yeah. It used to happen more often, until I realized that I'm not appealing to prize winning author and just call me or FaceTime me for please. That's it. That's it. So that's what you know, for those that use Scrum. If you've gotten a chance to play, planning poker we teams discover in that dialogue. It's not the coming up with the number. That's the powerful part. It's the hearing the differences of how people are seeing what the work is. That is the powerful thing. I've seen teams, you know, exponentially improve, just because they have their rich conversation about what They think something takes, and then getting much more clarity on what the work is.
Avi Schneier 40:05
Right, right. Oh, 100%. And it's all about the conversations about the discussion. I don't know why we're I don't know why we're losing it. And I think, you know, and again, I'm not trying to get too, too negative, philosophic here. But I think technology is part of that problem, right? You know, I think about I think about my daughter's generation, right, my daughter, my daughter's 21. I think we're her generation. It seems to me that a lot of these people, they can't even they just they've lost the ability to actually have a conversation with each other. They can only they can only text. Which means which means miscommunication is only going to happen more and more and more. And Scrum is the remedy for that face to face conversations being agile is the remedy for that sitting down with each other and trying to understand what is it that you're trying to achieve? How is it that you think that your idea is going to achieve that? Because if you don't, you have to have both of those conversations, because more often than not, right? You'll have the conversation of product owner will ask the customer what the product owner will ask, What do you want? Right? What do you want does not always achieve the goal that you're trying to do? It's just what you think will achieve that goal? Yeah. If you want to unlock the true potential of a team in the true potential of Scrum in an agile way of working, you have to be focused on what is the outcome? What Why do you want me to do this? Okay. Now, what is the solution, you think that's going to do that because you might end so often customer may not even know. And that's even better, because then then the team can innovate it. So you want a new way of getting from the first floor to the third floor? That doesn't involve an escalator. All right, let's see if we can figure out. And that's where the conversation can happen. If they often they come in, and they think this is the only possible solution to this problem that constricts the team. And yes, they can still we can still work that way. Yes, we can still make what you want. Right? If but if you don't come in and tell us what the objective of what you want us to make is, we may be making the wrong thing.
Felipe Engineer 42:04
Now, the big why. Exactly. We were working with the team. And the client was a different type of pool system similar to Scrum. And the client that said, like really subdued what, what we're building, and what the outcome is, it's a health care client. And the team was getting hung up on like these tasks. And they were not thinking about, you know, what, what are we trying to do? Like they're trying to create a space where they can treat patients today, even though it's going to take two years to get there. And so the team needed just a little nudge, like, Hey, remember, we're asking you to do this faster? Because there are people today that need health care in this area where it's not available, right, like it's not available. So like what we do today is going to impact this entire community. And then I just said, you know, just think of don't have to answer now. But what's the big why that the customer is asking and take that back to your team, and then see what you come up with. When I came back the next time. They had taken weeks off of the schedule, because they they reprioritize it became sukh. So clear what was needed. So they can move forward. Yeah, it was questions like why? Why are we doing Why are we building this?
Avi Schneier 43:20
I work with a lot of pharmaceutical companies, some, you know, again, fortune 200 and larger, and working with them is actually some of the most inspiring work that I do. Because for them, and it's really weird, because even the people in the IT department feel this way, they still think this way. They know at the end of the day, it's all about better patient outcomes. So even though they're making even though they're like refining an email system between between doctors, like what's that got to do a patient outcomes, it's got a lot to do with it. If the doctors have better email communication between each other their notes, better patient outcomes can result. If they can find things easier, the better patient, it's always about better patient outcomes. And when we when we hold that up as the big why behind everything we do. It helps really to focus everybody towards what that true mission and vision is for why we are all here trying to do this in another way that helps it get done faster. Like right now for example, I'm working with two different pharmaceutical companies trying to we're going to try to do Scrum in we're not trying to worry doing it in drug development. People say people say to me, Why Why are you doing Scrum and drug development that's that's got nothing to do with software and who cares but and I'm like, you guys don't understand. If we get a drug out in eight years instead of 10 years and most people do not know but to try to get a drug approved and take a look what's going on in the world of Coronavirus, right they've they've pulled all the they pulled all the legal nonsense aside, right. You can just like anything right before a regular drug and BCE before Corona ever. Yeah. It's it's an eight to 10 year timeline for approval for a drug in the United States. It's similar in Europe, it's not that much better, right? What if we could get that drug out in seven years? How many more lives? Can we save? How many more people's whole worlds are not destroyed by these debilitating diseases that these companies are trying to solve? You have to think there always has to be a big picture. You know, what do they say? think globally, act locally, right? And if you really think about that, at its heart, that is a very agile message. think globally, what is the big Why, why we're doing this, but act locally? Let's get something done. Let's get it out the door. Let's put an increment out. Let's get some feedback. Let's iterate, boom, mumble mumble mumble. That is really, you know, if I if I could impress on people as another mantra they should take back to their companies, which because that that phrase has been around for decades now?
Felipe Engineer 45:49
Avi Schneier 45:50
Right. think globally, act locally. In the same way we can get rid of pollution by you and I throwing stuff into streams and rivers, if everybody followed that there'd be no pollution, the same way we can do that is the same way we can make better products in our companies understand what is the global vision, understand what is the global why, but then come to our team and say, how do we enact this? How do we help push towards this goal as a group together, right, arms locked, pushing in one direction. That's how Scrum got invented. That's why the word is chosen. It's from that paper by talking to Eugene nonaka, that they said the teams that they watched, acted like a rugby team. And if you look at the rugby team, when it's trying to win the scrum, they've all got a lock arms, they have their arms on the backs, and they line their spines up. So they're all all of their force that they're pushing out of the legs is lining up in one direction to win and get that ball. We have to do that as teams. And beyond that, when you come to scaling, we have to do that in the in the echelons of management do whatever they may be, whether it's in Scrum management, and we're product owners and Scrum Master and Scrum of scrums masters or chief product owners or whether it's a design, the only way we achieve this as if we're aligned with as management also. That's how the team they get in line behind us. We get in line behind the big global why and we all push together to the end.
Felipe Engineer 47:14
That's how we Yeah, that paper for those of you want to read it. It's the new new product development system. New new product development team, new product development game.
Avi Schneier 47:24
Yeah, the new new product development game by professors tagi General NACA, written in 1986, published in the Harvard Business Review, my apologies. It is only available in English as they didn't translate.
Felipe Engineer 47:36
Jeff calls them the grandfather's of Scrum.
Avi Schneier 47:39
Right they are they are.I've had I've had the privilege of working with both talk. He actually invited me in to teach a class on Scrum. For one of his clients from Japan, a large Japanese organization at Harvard Business School. I had a chance to teach there for him.
Felipe Engineer 47:53
I have had a Harvard Harvard shirt on today for you, Ivy. Oh, that's good. I love so much to you. You went there for the teeth, the guest lecture.
Avi Schneier 48:02
Yeah. And yeah, I've taught there twice. And I work and I've met no naka a couple times now, I think I think three times now and I spoke alongside him at a conference, as well as we had one of the best, most most enlightening lunches in the history of Agile was me and JJ and Professor nonaka sitting down having lunch with our good good compatriots over in Japan, Kenji and cascais and Chloe, it was just it was fabulous. You know, it was fabulous. He's such a wise, he's such a wise guy, he really an eye, not a wise guy, not a wise guy, like your neighborhood, or wise guy, but he's wise are so full of wisdom.
That that he is, yeah, he introduced me to a lot of really interesting Japanese Business Management concepts that we don't even hear about here because we don't translate a lot of business channels.
Felipe Engineer 48:57
Yeah, drop drop one of those on us to something easy one that you can remote into Maurice on the guy who eventually he was the president or founder of cow Sarah.
Avi Schneier 49:09
And he also founded kddi, which is the second largest telecom in Japan and one of my clients. And he came up with he so his theory is called he calls it Amoeba style management. Like an amoeba with pods of Gods really interesting stuff. If you want to Google it, Google Amoeba style management system, some stuff there. But what what some of the practices that Inamori developed were just their groundbreaking Okay, so Japan is a culture that is incredibly rooted in ancient traditions. And one of them is the family meal. Now, I'm not saying that Americans don't have family meals, Sunday dinners, we all got all that stuff. But as dust inherited from Europe, not from Japan, it's a very different way in Japan. So the family meal in Japan right. So one style of meal that they have is called knob a it's like a giant of pot of soup. And noodles, right? So think ramen, but much different thick a noodle and much and like a giant bowl like enough everybody, okay. And it's really fun when you go out to do this in Japan, I mean, they are all into communal eating, it's really it's a great time. And they have restaurants totally devoted a lot of fun. So it when you make the novelty the oldest person in the group, because you know, senior, being seniors like elevated there, and they treat their elderly the right way. The oldest person in the group is the knob and master who actually monitors the pot, right. And so they're helping making sure everything's cooked, right, because the cooks on the table, right, it's not brought to cook that cooks on the table, you put the raw meats and vegetables into cooks there, and they help dish it out. And everybody eats together, essentially out of the same big giant pot, you have your own little bowl, but all the same time. Anyway, it's a very traditional Japanese dish, it's very fun to eat. In a Morrison used to hold events after 5pm. So before people went home for work to their actual families, he had them all eat together. And when I say all i mean the whole company, everybody went to the cafeteria, and they would not be on all these different tables, everybody sat down for a company meal together to close out the day before you went home. Now what was innovative about this, he literally said, you have to come you have to sit down. And the first thing you have to do is complain about management.
Felipe Engineer 51:29
I'm liking him.
Avi Schneier 51:30
So literally, it became a gripe session. But what now we all have had gripe sessions or you know, around the water cooler that. So what's the difference? You're sitting down and it was that we talked about that phrase psychological safety. This is what he was creating. He was saying it is okay to sit down. And by the way, management is in the room. Maybe your table? Yeah, it's okay to complain about them and what they are doing. Right there. Yeah. with one goal. Once you clear the air, you have to decide how are we going to get rid of this problem tomorrow. So think about that. He's combining dinner, gripe session and retrospective, all in one spot. Yeah. And he's doing it and wrapped up in psychological safety. Where he himself This is the big CEO, this would be the equivalent of Bill Gates eating with the programs. Steve Jobs eating with the eating, that's the equivalent of this guy. He would sit there to. Yup, complains about upper management. Come sit at my table, eat with me, tell me what that tell me what the issue is. This is this is this is innovation in how management can be different. And I consider an A Moria, a tremendous visionary and a business leader who I owe, hopefully I can emulate. He might and I'm hoping I can still get back to Japan after this stuff ends and get a chance to meet him because he's still around. I think the other piece of wisdom I would tell you from nanaka. Before we close, because I know we're coming to the end of this, but it's a really good one is I was one of the one of the first times I sat down with him at the time there was somebody in my company who was very into the Toyota Production System and right. And he would Oh, and he said he would say that the Toyota Production System and and lean and Scrum are all the same, like that Scrum and PDCA plan, do check act. And I didn't see it that way. So now here I am in Japan sitting with nanaka son and I said, You know what? I'm gonna ask him this question. And so I said, I said, Hey, I got a, I got I got a compatriot who says this. And no, Naka says, and he goes on, he goes, obviously, and he goes, What do you think? And I said, they're not the same. They're very different. And he goes, tell me, give me an example. And I came up with a sitting on the spot. I came up with this, Philippe said, Actually, I said, I think it's actually pretty simple. If I had a factory that made candles, right, so I'm starting with a candle that doesn't light and all I apply, all I apply is PDCA. I will eventually get to a candle that can light and maybe burn brighter and last longer than whatever I had before. And he said to me, he goes, Okay, how is Scrum different. And I said, you can never go from a candle to a light bulb with just PDCA because it's not an innovation framework. It's an efficiency and a refinement framework. If you start with a candle, you will make a better candle. But you will never come up with something that totally blows the candle out of the water and says forget candles. This is the way we should become. That is what you need Scrum for because Scrum is engineering practice agnostic. So you can put design thinking in it. You can put lean production in it. You can put XP in it. You can Put all these different ways of doing things and figuring out the solutions are your problems inside of that Scrum. Scrum is designed to be disruptive and to be innovative. It's in the output of PDCA. The output of lean is efficiency. The output of Scrum and of Agile is creativity. That's the difference,
Felipe Engineer 55:20
Or what do you say to you?
Avi Schneier 55:22
He said, that's a great question. He said, he said, obviously, you're right. That was all I needed. No, Naka said I'm right. Mike, drop me to the airport. I'm out of here.
Felipe Engineer 55:35
Put it on your resume. The NACA sun set up right. I only I only needed once. Yeah. Oh, yeah. That's a That's awesome. It's a great way to close man. Thank you so much for coming on the podcast and sharing some of your insights with people. Where can people get ahold of you?
Avi Schneier 55:52
Maybe they can get a hold of me at scrumming obvious spelled ABI at scrumming calm or please find me on LinkedIn. Hit me up with the connection. Let's Let's exchange you know, contacts information. You have questions anything you want to say. You want to yell at me? Tell me I'm wrong. You know, knock yourselves out.
Felipe Engineer 56:11
He'll dance with you.
Avi Schneier 56:13
Absolutely. Let's, uh, let's, let's let's let's have dialogue. That's the way that's the way to move forward that unfortunately, our country's missing right now.
Felipe Engineer 56:20
It's all about dialogue, dialogue, dialogue. All thankfully. I really appreciate it. Thank you, man. Have a good rest of your day. Take care. Ciao.
Very special thanks to my guest. I'm Felipe Engineer Manriquez. The EBFC show is created by Felipe and produced by passion to build easier and better. Thanks for listening. Stay safe, everybody. Let's go build!