← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
BONUS: Exploring Lean Principles in Software Development | Doug Rabow
00:43:21
BONUS: Rediscovering Agile's Roots, What We Can Learn From Lean Manufacturing with Doug Rabow In this BONUS episode, we reconnect with , a previous guest and an expert in Lean-Agile strategic management known for his dedication to fostering...
Loading summary
Transcript32 lines
- [00:01]
Vasco Duart
Hi, I'm your host, Vasco Duart. Welcome to the Scrum Master Toolbox podcast where we share tips and tricks from Scrum Masters around the world. Every day we bring you inspiring answers to important questions that all Scrum Masters.
- [00:15]
Host
Face day after day. Hello, everybody. Welcome to a very special bonus episode. We're going to be talking about Lean and Lean software development and our guest joining us from beautiful Canada is Doug Rabo. Hey Doug, welcome to the show.
- [00:37]
Doug Rabo
Thanks for having me. It's great to be here with you, Vasco.
- [00:40]
Host
So Doug is a passionate practitioner of Lean and agile strategic management with a focus on developing empowered teams and Lean process improvement. Sorry, I was going to say investment. We're going to talk about investment later, but in a moment. Let's not jump ahead of ourselves. A while back I interviewed Doug for the regular podcast episodes and as we were talking, we discovered that we both have a passion for Lean. So that's what we are going to talk about today. I have my glass of port wine here to inspire me to talk about Lean. Doug has his cat is probably going to give him some inspiration as well. Today we'll talk about Lean, Lean software development and cover some of the reasons why Lean emerged in the first place, as well as we can learn from that approach that comes from manufacturing, but has a lot to teach us regarding how to develop software better. True to the Agile manifesto, Lean is inviting us to uncover better ways. So, Doug, let's start with you giving us a quick intro of how you got into Lean, the Toyota production system, and also how you think these ideas influence your perspective on software development.
- [01:55]
Doug Rabo
For sure. So I think what's interesting about today's conversation, and we spend so much time in the space of Agile and talking about what is Agile. So, you know, if we want to take something that's, that's even less well understood and has a more broader definition than Agile, I think Lean might be a great candidate for that. The. One of the, one of the things that's really important, I was having a conversation the other day with a gentleman by the name of Brian Erickson. You can look him up on LinkedIn about what is the definition of agile mean? There's a hashtag no such thing as an Agile coach because what does Agile even mean? If I ask you, it might mean one thing and if you ask me, I might give you a completely different answer. And so with Lean, I think I am going to tie this back, I promise. With Lean, I think it's so important to start with the definition of what does Lean mean to us, what are we actually talking about? Because depending how you came about to lean, it might mean something very different to you. So, for example, if somebody's first exposure to lean was, hey, I went and took a lean Six Sigma course, then the lean that you're going to see there is very much tools and techniques going through 5s and Kaizen and all these different phrases and things that are really valuable that we can apply. But for me, I came at this from a slightly different perspective. So for me, in my late 20s is kind of when I switched from working in trades as a truck crane operator to working in the business world. And I ended up in this very fortunate situation where this small chain of companies that I was working for, I had the opportunity to do a business development project for the owner of the company. And so I went and I kind of explained to him how I thought I could help. And he went, yeah, great, Doug, we'd be happy to have you invest some time in this. And I left that meeting and went, oh, man, I have no idea how to do this. So straight to the Internet went, what are the best books I can find on strategic management and operations management to kind of help me think more strategically about how we approach business? And luckily, the Toyota Way by Jeffrey Leiker was one of, if not the first book that I came across. And so for me, what I think is so interesting about leaning the tools, the techniques, all of these things are really important. But for me, the Toyota Way was a story. It was a journey that, I mean, it's very focused around Taichi Ono, but it is, it's a journey of the problems that they solve, the environment that they were in. And so rather than a set of lessons that I could just go and take away and apply to my work, it was about understanding how they had gone on this journey and really taking that and internalizing it and trying to understand how this applies to my environment and, yeah, continues to be my basis for Lean. Is that kind of understanding.
- [05:01]
Host
Yeah. First of all, I'm happy that you mentioned the Toyota Away. The book is one of the foundational books for me and also because I started studying process improvement from the Lean perspective before I discovered Agile. Lean has a big impact on how I look at what the Agile ideas are, including, of course, something like a language pattern that Scrum is, or process improvement framework like Kanban is, or other things that shall not be named for now, but maybe we come back to those later. One of the key things for me, going back to Leiker's Work on the Toyota Way was how he discovered how he defined Lean as a way to solve the problem that is caused by in manufacturing. As he was describing what is a socio technical complex environment. And the fact that he brought up these two aspects, social and technical, put me back to the book Peopleware by DeMarco and Lister, where they argue exactly that the biggest problems we have in software don't come from the technology or difficulties with the technology. They come from the people working and how they relate to each other and how we organize that. And that actually leads me to talk about one of the fundamental aspects that Leiker then wrote about later in.
- [06:29]
Doug Rabo
Was.
- [06:29]
Host
It the Toyota culture? I'll look up the book name, but it was a book about the culture of Toyota, right? So he took the Toyota Way and kind of deepened some of the concepts and started talking more about what the culture was all about. So for me, Lean is the origins come from the Toyota production system. But also, and this for me is very important because that's how I found Lean, through Deming's work, right. W. Edwards Deming, which is kind of a curmudgeon from the US who was kind of kicked out of the US after the Second World War and exported to Japan. And accidentally, through the work that he did there, plus other people, of course, including Tai Shihono, like you mentioned, ended up creating what later became the highest productivity, highest quality manufacturing country in the world, which is Japan even today. Right. And for me, that's also part of what the essence of Lean is about, is these ideas from Deming, the work by Taishi that later became the Toyota production system, and then the perspective that Leiker brings from his books, which is that Lean looks at organizations as socio technical systems, not just a problem of process improvement.
- [07:46]
Doug Rabo
So while you were talking there, I think I actually heard all of the engineers, software developers that are listening to this podcast go, actually, the technology is really difficult too. But I take your point there and I think for me you gotta have both. And especially as we start to operate at scale of more than 100, 150 people, if you're missing one or the other, for sure, the technology has to be built with quality built into it. We'll probably come back to that at the topic, but absolutely, managing the people side of it, the way we interact with each other, the number of people who've ended up in situations where they're in meetings all the time and don't have any, have any time to actually build software because of the organizational structure and the amount of work being placed on them and things like that. And so that aspect of it is really important. I think that to me is where my interest in Lean comes from. Now, again, going back to mention Agile, we won't get into Agile's dead and why that may or may not be the case, but Lean went very much through the same phase. It was long before my time, but where there was this broad adoption of people trying to implement something that they were calling Lean. Again, we kind of need to keep in mind that Lean is really the North American to my understanding. And somebody will correct me later if I'm wrong on this, but Lean is very much the North American understanding of what it was that Toyota done had Toyota had done that made them so successful. And I think the problem that we run into with the tools and techniques, which is a lot of people's first exposure to Lean, is I'm actually going to read just a very short little quote here from the book Good Strategy, Bad Strategy. And it's that we take these tools and techniques and we treat them like a crank winding exercise. So the quote here from Good Strategy, Bad Strategy, when engineers use a nice clean deductive system to solve a problem, they call it winding the crank. By this they mean that it may be hard work, but that the nature and quality of the output depends on the machine, not on the skill of the crank winder. Later, looking back, I realized the group had expected strategy to be an exercise in crankworm. They'd expected that I would give them a logical machine that they could use to deduce business plans, a system for generating forecasts and actions. And I think that's one of the mistakes that gets us into a lot of trouble with any kind of framework is when we treat it like a crank winding exercise, that we can just take these tools and techniques, we can put whatever our problem is into these tools and techniques and. And out the other end we're going to get beautiful spaghetti or whatever it is we're trying to make there. And what was so interesting to me, and it's right in our. And we talk about the Toyota way. And Jeffrey Leifer captures 14 Lean management principles. There right in the 14 Lien management principles, we have two different principles about the kind of people that we need within an organization. And what's so brilliant about what they did is what made Toyota so successful was really creating a culture of problem solvers. They created an environment of uncovering problems. And that's something that's really challenging and is missing from a lot of our organizations where it's not safe to uncover problems. People hide problems because performance reviews and all of these other things. And what Toda did that was so brilliant was really creating a culture of problem solvers, a culture of problem solving where we're constantly going and trying to uncover problem solvers. And then it goes one further than that, which is actually to develop people, to teach people how to take a problem solving approach. So not only do we need problem solvers, we need managers who are going to train other people in problem solving. And that to me is really what I see as the foundation of lean management.
- [12:02]
Host
That's a very good point. It's funny that you mentioned that Leica in the Toyota way has these 14 principles, damning all also had the 14 key points of management for what he called the system of deep understanding. So 14 number repeats. And then you talk about how important it is to have the right people and to develop those people. And that actually comes from an American program that was used during the surge in manufacturing to support the war effort during the Second World War, which was training within industry. Just two weeks ago we published an episode about that program, the training within industry. And all of the things that you are saying actually also came from the U.S. and the funny thing, ironic also is that TWI stopped completely in the U.S. for reasons that Hugh Alley, who was the guest two weeks ago, also explains in that episode. And in Japan, it kind of started to take off because of course Japan needed to rebuild, right? And they had very few resources, which is one of the reasons why Toyota developed the whole idea of waste in manufacturing, because they literally didn't have the people or the raw materials to produce everything they needed to produce. Therefore, they needed to be very careful and very mindful and deliberate about how they used the resources and how they used people's time and how they developed the people that were there. Let's not forget that they started right after the Second World War. When we think about these aspects, we talk about creating a culture of problem solvers like you mentioned, developing people. We start to understand that actually lean is a cultural system, or as I call it, a philosophy of business. And the Toyota Culture, which is the book by Leiker and another author that I'm forgetting now, puts a lot more focus on these aspects than the Toyota Way did, even though the Toyota Way does mention many cultural aspects. And there's these four categories that Leiker talks about in the Toyota Way book, which encompass those 14 principles you mentioned. They talk about long term philosophy. The right process will produce the right results. And we'll explore this in a minute in a lot more depth. Add value to the organization by developing your people, which is one of the key aspects, and then continuously solve root problems. Continuously solving root problems drives organizational learning and organizational learning, which started way back when we talk about TWI or training within industry. And then Toyota production system later on in the 80s became a whole program and a change process called knowledge management. We spent ungodly amounts of money and people's time in trying to formalize how to collect and retain knowledge within an organization. But that problem had been solved by Lean already in the 40s and 50s through developing people. And that is the key aspect that I very often kind of face and am flabbergasted by. How many people, even in our industry, which is all about knowledge, don't really pay attention to that aspect, the developing people to keep knowledge in the organization.
- [15:32]
Doug Rabo
And the reason that I went back to that quote from Good strategy, Bad strategy, see how many plugs I can give it today is because. Because I just find that idea of treating knowledge as a crank pointing exercise to be such a valuable concept. I think when most people, they heard those four different categories you're going through, I don't know how many people would be able to say that that reflects the organization that they currently work in.
- [15:59]
Host
Well, the first one fails in most organizations long term philosophy.
- [16:04]
Doug Rabo
Yeah. So for sure it takes a tremendous amount of discipline. Let's be honest about this Lean. There's actually a quote from a video on Lean that I came across a while ago. I'm going to forget the gentleman's name, but everybody wants to be Lean until they find out what it takes. The things that Toyota accomplished, especially in their time, was a global renaissance in manufacturing. They were the best in their industry. And, and we need to recognize really what you're striving for here is to be like the people who are innovating, who are doing things in a new way, and we're really chasing excellence in their environment. And that's why taking the tools and techniques and the knowledge that we got from them and just treating it like a crank winding exercise does not work. Really. What made Toyota successful was the culture of the right process will produce the right results and a relentless pursuit of asking the question, do we have the right process? This is something I advocate for. And we, we can call it a Lean Management principle or we can just call it good business. When we talk about any sort of governance practice, whether it's financial governance or project oversight, which still comes down to financial Governance. And everything goes back to financial governance in a way. But it's like we should be reviewing our governance processes every six months or at least once a year. You know, all of these controls are in place to mitigate some kind of a risk to the business. So are, do we have the right process? Is it producing the results that we expect it to? These are the sort of questions we should be asking on an ongoing basis, but too often we don't. And so that's why for me, the important aspect of lean, or at least the area that I focus on the most, is what is that culture that actually led us to creating this culture of problem solvers where we are asking these questions and going through that sort of process on a regular basis.
- [18:10]
Host
I remember when studying Lean and also the history of Toyota, how important this aspect of developing people was. In fact, when I read Liker, the term was respect for people. And it was portrayed as one of the core aspects of how Toyota looked at their socio technical system. Let's not forget that in the case of manufacturing, technology is of course the big machinery that is operated, but it is also the culture and the processes that are there to support the people in doing their work. And one of the anecdotes that very well illustrated this was when I don't have the quote here, but it's something like this. When asked about the difference between Ford and Toyota, they were the big competitors at some point because Ford was a huge manufacturing powerhouse at some point as well. And somebody from Toyota said, well, in Ford, they hire two hands to work in the production line and don't know what to do with the brain. In Toyota, we hire the brain and as a BONBUS we get two hands. I think that so beautifully illustrates the perspective of what this developing people and respect for people means. At Toyota, there is this ingrained philosophy that it is the people who create the process that produce the results. And in fact, this is so ingrained that in any given year Toyota will have an average of more than one implemented improvement per person in any given factory.
- [19:58]
Doug Rabo
Right?
- [19:58]
Host
Which means that the whole manufacturing team is constantly improving the process, constantly getting better. And no wonder that Toyota gets top marks and number one in all of the quality surveys when it comes to manufacturing cars. Right? Like, you know, very famously in the US for example, they every year they're number one with the least defects per vehicle sold in the us.
- [20:26]
Doug Rabo
So one of the challenges that I see, and we talk about, you know, respect for people, whether it's lean, whether it's agile, basically the same thing in my mind, but we can maybe get into that later. But the, one of the problems that I think we run into is that if you, if you start with respect for people, it doesn't necessarily get you to lean. And I think it's the same challenge that we ran into. And luckily this is kind of dying off a little bit. But the mantra fail fast was everywhere. And what I really feel like some of these things are is it's like somebody who has watched somebody achieved a lean process from the outside and is trying to describe what these processes look from the outside. So for sure, respect for people is a critical element. But like I said, I don't think you, if you just go, okay, we're going to have respect for everybody. Is the business fixed now? It's not going to get you to where you need to be. And so this is, again, I think one of the interesting things and why I'm so glad that my introduction to lean did come from the Toyota way, is there isn't a set of 14 principles. There really isn't. You can't, we can distill it down to useful things in the same way that the Agile Manifesto is distilled down to some useful things, but it's not enough to actually implement in a way that has a positive impact on outcomes. There's, there's more to this. And when you read through the toy away, it is, it's just a whole bunch of different lessons. And even when we go outside of Lean and we start talking about Things like Reinerton's 175 Principles of Product development flow. Yeah, there's probably about a hundred of those principles that you're going to want to be using at any given time to help your business be more effective. And some of them work together, some of them are things that you can apply on their own. But there isn't a shorthand answer. There isn't like a lean machine that we can give you that is going to pump lean results out the other end. It really is about understanding all of the different challenges that Toyota ran into and other organizations who were doing something that they were calling lean based on what they had learned from Toyota. There is now 75 years worth of lessons from manufacturing and from other environments. And you can't just, there isn't an answer for how to do this. You really have to go through and learn each one of these lessons and learn how to apply them in your own environment.
- [23:13]
Host
And that learning process, which very often is referred to as continuous improvement when it comes to Toyota and Lean is actually something that is supported by very specific activities. Like you said, respect for people doesn't encompass all the complexity that Lean brings to the table. And of course it can't, because respect for people is an after the fact rationalization of what was being observed in practice. And actually, Leiker is very clear about this. In the book when he wrote the Toyota Way, he talks about the fact that there's a difficulty of explaining what is actually happening, because the things that are happening are far more complex than could be created, could be described in a simple narrative that a book represents. And he has different anecdotes in the book. It's definitely worthwhile reading just for the anecdotes, let alone the insights. We need to understand that. For example, like you said, Reinertson does a great job of elucidating more than 100 principles of product development flow. But the principles are also an after the fact rationalization of things he discovered when he wrote Developing Products. Or was it Managing the Design Factory. Sorry, Managing the Design Factory was his original book, which is, in my opinion, a better book than Principles of Product Development Flow. He makes a much more compelling argument and explains some of the core aspects that then lead to these 100 plus principles of product development flow. So we have this challenge, right, that when we are talking about Lean, we're trying to, in a short period of time or space, when it comes to a book, describe something that is far more complex than we could describe, as you said, without actually being there. And that takes me back to an anecdote in Taishi Ono's book. I forget the name now, but I'll figure it out in a second. He talks about how he developed managers, and he had basically he would take a manager or supervisor into a production line, he would draw a circle on the ground, and he would tell the manager, you now need to stay in this circle and observe what is going on. Then he would come back a few hours later and he would ask, what have you observed? And most managers would start by just describing what their eyes had seen. And this is where we are when it comes to Lean, right? We can only describe what we see. And then he would say, you still don't understand what is going on. You now need to stay here another whatever number of hours. And it took many managers several days to actually start to see what was happening in the production line. The anecdote goes on about what were the things that they were not able to describe when they first took a look because they could only see what was moving from left to right and so on. But then later on they would be able to see when people were not where they should be, what material was coming late and what might be causing that. And all of that depth of understanding, it took days for people in the system observing it to get it. That's one of the things that we need to also recognize as agilists that the depth of what Agile means, I very often refer to it as a philosophy of business cannot be understood by reading one or two or even ten books about Agile. We need to be doing the work and we need to be doing this constant and continuous process of reflection and improvement, which we call continuous improvement.
- [26:54]
Doug Rabo
Well, and I'll keep coming back to this idea that, and I love that the idea of the philosophy of business, it really comes down to just creating that culture of problem solving. And that's one of the things that I find really interesting specifically about respect for people, is you can't have a culture of problem solving without respect for people. The very basis, and coming back to your quote as well about we hire a brain and we get the two hands. It starts with the perspective of we have an organization full of people who have insights, they're working directly with the machines, with the materials, and they have access to knowledge that I don't have. And so this whole problem solving culture involves engaging them, leveraging this knowledge that we have of the people doing the work. Unless you start from a perspective where you have that respect for people, that would never be possible. And that is where we get into trouble. Doing it the opposite way, where, you know, we sit in our office and there's an over reliance on metrics and what have you.
- [28:02]
Host
So yeah, and defining processes without ever needing to be there present when the process get executed, which is another of the anti patterns that we see a lot, especially when it comes to processes related to PMO's Project Management Office, how to manage projects and so on, which are very often decided in an ivory tower without direct contact with how software gets made. And talking about software, one of the things I wanted to introduce in our conversation is of course Lean Software Development by Poppendick, Tom and Mary, which is one of the first books that brings the lean thinking into software development. And one of the key things that I really liked about their book and of course comes from Lean, but they needed to translate it into software, is how the concept of the different types of waste can be seen in software development. And what is waste? Very simply, waste is something that you want less of, right? Like for Example, one waste in software development, according to the POP Index, is partially done work. So work that has been started but not finished. Obviously we want less of that, right? Another one is extra features. So features that don't add any value to the product. Obviously we want less of that because they cost a lot of money relearning. So having to go and study something again to relearn it before you can change it or handoffs, right? Somebody does something, then they give it off to somebody else who then needs to do all the process of understanding before they can even work with it. Delays, task switching and defect. So this is how they translated the seven ways of Lean from manufacturing into software development. And I think that this is a very useful concept for us, especially when we go then to value stream mapping, which is something that the POP Index also introduced for software development and is a big part of the tool set for any Lean practitioner. We need to understand what are these wastes and how they materialize in our software development environments.
- [30:19]
Doug Rabo
So one of the most important lessons I've learned about Lean, and I'll even bring up someone made the point the other day that you can define the Toyota production system that's defined as the house of Lean. And there's certainly concrete practices. Lean management isn't a well defined thing. So it really is what lessons can you take away from their experiences? And something that'd be, I think, really cool to talk about here. So most people are familiar with the word Kanban, although I think to most it means you're bored in Jira when you're not working in Scrum Lean. Kanban in manufacturing comes is a very different thing and it actually teaches us a lesson that covers all of the points that you mentioned from the POP index book and for me is probably the most important takeaway in terms of actual lessons that I've garnered from Lean. So Lean can ban in manufacturing, as I'm sure you well know this Vasco, but we'll go through this for our listeners. It is basically if you have five machines that are working in a row and machine three breaks down, machine one and two will actually stop producing. And so the way Kanban and manufacturing works is the machine that is downstream actually triggers the upstream machine when to start work and if it's not ready for more work then, then this Kanban system won't will tell that machine not to start producing yet. And so this was a really, really important revelation that they had that Tatiana had that, you know, management accounting treats all of this work in progress as an asset, but truly it was a liability. You have all of this work that's been started, but it's not getting finished. So what are the problems that we see here? And this, this is a very simple system. And compared to other manufacturers, it. What Toyota was doing was a simple system because it is very linear when you're building cars. There's examples from Gold Rat and Theory of Constraints, how certain things that Toyota did didn't work in more complex environments. But the really simple lesson here is whenever we have a process where there's a dependency, where there is something that is going to start work and another station that is going to complete the work, we have the potential for a queue to start to form there and a backlog. So whenever the machine that's downstream breaks down, you end up with a bottleneck, and that's where we end up with all these issues you mentioned. So partially done work, handoffs, delays, task switching, if there's multiple different stations feeding work to this bottleneck. And so that was so interesting for me is I probably started learning about Lean nine or ten years ago, only transitioned into working in IT and custom software development about two and a half years ago. But I came in and the environment I was working in was a fairly high dependency matrix structure. There was developers working across more than one different team. My first revelation was, oh, my God, this is a 1980s manufacturing problem. We have a bunch of different teams that are starting work with other teams, other people that are dependent, they're the downstream receivers of those work. And what we're ending up with was tons of work started, very little work getting finished. We had all sorts of quality issues along the way. And so that's where this very simple idea of Lean, Kanban and manufacturing having a pull system where, you know, the downstream resources, team members and software obviously actually triggers the upstream resource when to start working and when to start producing again. That we can apply everywhere in software development. And the really important lessons here are that waiting time is incredibly expensive. Whenever we have this work in progress that's not getting finished, that actually costs us more in the form of waste than slowing down. And I think this is the really hard part, is that what Toyota did with Lean Kanban and manufacturing is that upstream, this, this is what, the part that freaks a lot of people out, a manager will walk into the plan and they'll see that, you know, machine three is broken down. So machine one and two have stopped producing and they go, yeah, but machine one and two aren't broken. Why? Why aren't they Continuing to produce. And that is the problem with pulse. It's not a problem with pulse systems. It's. It's an inherent part of the design. But I think it's why a, a lot of organizations, and maybe people who aren't formally trained in, in lean management or don't have this background, they see this idle team member or resource, whatever it is, sitting there and they go, oh my God, we have to get that starting to work again. And that really is where that lesson comes from, that the waiting time by the queues and the dependencies actually costs us more than having that team member or that resource in manufacturing sitting idle until we're ready to start producing.
- [35:12]
Host
If you have nothing to do, don't find something to do. Just take a break. Because it is also regenerative, right? Because you know, you get, you get rest, you are better than when you come back. And actually that's a. There's an anecdote from the Toyota guys and the phrase was something like, in a relay race, focus on the baton, not the runner, right? And we all know how in a relay race, three out of the four are standing still. And the fastest way to get the baton from the beginning to the end is exactly by having three out of the four standing still while one does the running. Because what you're measuring is the time the baton takes to complete the race, not the time that each individual runner takes to complete the race. And that's a very important understanding. And very often what happens is that we forget about the baton, the work, the value we want to produce, and we focus on the runner, the worker that is idle, and forget that there is no benefit for being busy if the bottleneck is either stopped or fully occupied, right? Or I think it was Alistair Coburn who said that productivity at non bottleneck stations is expendable. So you can actually use non bottleneck stations to help. And this is what the constraints talks about, elevate the bottleneck station. So, for example, take work off the bottleneck station, prepare things in advance and all of that, that would enable the overall system to be more productive. And this is, I think one of the key aspects and contributions from Lean is to help us and to even divide or decide that what we are trying to do is to optimize a whole system, not, you know, the performance of one worker or one team.
- [37:14]
Doug Rabo
And I do think that is one of the most important lessons that we can take away from, from lean manufacturing and apply to software. And I think that's fantastic analogy as well as, you know, Your customer doesn't care whether Susan or Bob or anybody working in the department was, was fully busy or maybe only working at 80% last week. What they care about is value delivered. And so yeah, to your point, what we really want to focus on and the lesson from Lean is how does this work as a system to produce value and how do we improve the system as a whole, not just the individual component parts. Now where we're luckily in software is there, there's actually a very simple explanation of this. So when we get into manufacturing, and I want to say it's Hitachi, that gold rat in Theory of Constraints, the author of Theory of Constraints references as being more complex and where, you know, conventional Lean Kanban didn't work because we have a thousand different parts that we're making and all this different tooling and equipment is constantly changing in manufacturing. It can actually be quite a complex process to figure out, you know, where are bottlenecks, how do we remove these? In software we have some very simple answers. We can move to cross functional teams. It's kind of like having a bunch of different, it's like having a machine that does the work of 10 different machines all in a single station. Again, we want to be a little bit careful not referring to people as machines when we switch in the software, but just this idea of we can pretty much get rid of the majority of our dependencies. Value streams is another important idea that comes out in terms of how we're going to align these cross functional teams. But really it comes back to this idea of if we recognize that dependencies cause queues and queues cause waiting time and we're gonna try to eliminate those, then anywhere that we can reduce the dependency is going to allow value to flow easier through the system. And so that's that. That is why there's so much value in these cross functional teams. And the other great thing as well is, I mean, how many organizations out there complain about the amount of tech debt they have? So if you ever do end up in a situation like there's so many opportunities there, there's no reason for anybody to ever sit idle is basically what I'm trying to say. So even if we're going to take this perspective of yeah, we're going to have a cross functional team and maybe the DBA is only utilized at 70% this week, that other 30%, like we can go do some refactoring work, we can go do some education on new techniques and new practices that we're learning we want to implement. There is a endless amount of ways that we can utilize people's time to.
- [39:59]
Host
And brains.
- [40:03]
Doug Rabo
Absolutely. Using their brains. Use this extra capacity that we have though. And it's just such a beautiful solution and such an easy way of solving for that problem. So, yeah, the benefit of reducing these dependencies and being able to leverage that time to do other productive things is I think one of the more important lessons we can take away from Lean.
- [40:30]
Host
So, Doug, we're getting to the end. We get to the point where we talk about recommended books. We've shared quite a few already, so not too many anymore. I did want to mention the Machine that Changed the World by Womack and Jones, which was the book that kind of introduced Lean to the manufacturing community in the US Even though Lean came from twi, as we've already discussed, which was an American program. But that's how things go. It came full circle, as they say. How about you, Doug? What is one book we haven't mentioned yet that you would like our listeners to be aware of?
- [41:15]
Doug Rabo
So one that's, that's very popular and it's, it's not specific to Lean, but I think it is so intrinsic to that respect for people and, and doing what we can to leverage the most out of our people skills. We'll reference Daniel Pink's Drive. I hope most people are familiar with it, but if not. Absolutely. I think it is the most important book I've come across on human motivation in the workplace. And it does on some level distill down to the ideas of autonomy. Mastery and purpose is what people value and in their work and it's what drives human motivation for most people. And so I think it's such a beautiful concept. If we want to create this culture of problem solvers, we want to leverage the collective knowledge of people in the organization. That means giving them autonomy to have span of control over the things that they're responsible for. And then that mastery as well is so important in terms of developing our craft and continuing to build on that knowledge as an organization. So awesome.
- [42:19]
Host
Doug, it's been an amazing pleasure to have you again on the show to talk about Lean, which is one of the topics we are both passionate about. If people want to reach out and get in touch with you, where could they go?
- [42:30]
Doug Rabo
LinkedIn is the best way to find me and happy to connect. So please feel free to send an invitation.
- [42:36]
Host
Absolutely. So do get in touch and ask a few follow up questions. Thank you very much, Doug for your generosity with your time and your knowledge.
- [42:45]
Doug Rabo
Great to chat with you. Vasco.
- [42:51]
Vasco Duart
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.