Patrick Adams  00:00

Hello and welcome to the Lean solutions podcast. My returning guest today is Tim Skipper. Tim is a graduate of Calvin College and the University of Michigan. He has a Bachelors of mechanical engineering and a Master of Science. His career has spanned 40 years and includes time as a tool designer, engineering educator, engineer IT manager, Lean Expert, author and agile transformation leader. He has led Lean transformation since 2003. In areas of manufacturing, office process, it development global product development, new business initiatives, government agencies and nonprofits currently works for Steelcase right here in Grand Rapids, Michigan. Tim has also written two books on the topic of lean, innovate innovative lean development, how to create, implement, and maintain a learning culture, and the highly effective office creating a successful Lean culture in any workplace. Welcome back to the show, Tim.

 

Tim Schipper  01:28

Well, thank you, Patrick. It’s really wonderful to be back.

 

Patrick Adams  01:31

Absolutely. Now it was, it was great. We were before we hit record, we were talking a little bit about your past episode, and just had a lot of great engagement with that episode. And so if anyone’s interested, you can go back to season one and search for Tim, and find his previous episode. But today, we’re going to talk about something a little bit different than we talked about last time, and specifically around agile, lean and agile. So Tim, obviously, as I mentioned, in your bio, you have a vast amount of experience in lots of different areas. But the one that I think is super interesting to me is the work that you’ve done in the office and and also, you know in it and just the backend side of things. But before we get into some of that, what what do you appreciate about Lean? The more that the more experience that you have, the more you know that you practice it, the more that you see others practice it, what what is, what are your thoughts around just lean as a as a whole?

 

Tim Schipper  02:40

Yeah, so I’ve been involved with since 2003, which is when we first started to apply it in the office. Of course, it was even before that in manufacturing. And it started in the 80s and 90s. But what I came to appreciate more and more is how much it is about continuous improvement and every individual doing continuous improvement, you can talk a lot about the tools, you can talk about eight step problem solving, you can talk about Kaizen events and value stream mapping and all the things that we’ve done over the past years in Lean, but it really all comes down to continuous improvement and our people on a regular basis, like do that work, word continual? Are they on a regular basis making changes and improvement? And it’s it’s all about the workers doing that, though, yeah, we appreciate that. Probably the most is the core part of lean that a lot of us miss.

 

Patrick Adams  03:47

Yeah, I think there’s so many organizations that, you know, missed that over the years. And I think, just as of recent, it seems like many companies are starting Western companies, specifically, I guess. I’m talking about a Western in the western culture. But many companies are just now starting to realize the you know, that, that lean success really doesn’t depend on the tool set. It’s really about what’s behind the tools and having this, you know, this real culture of continuous improvement, a learning culture where people are always interested in, you know, what’s next, how do we continue to get better? How do we continue to improve? Why do you think it took so many companies and again, like you said, there’s still companies that struggle with it, but why do you think it’s taken so long for companies to understand that the power behind the tools, you know, not necessarily the tools themselves, but that that continuous improvement mindset?

 

Tim Schipper  04:43

Well, I think it’s all about culture change. The culture itself, has to change within the organization. And that’s the most difficult part and probably the slowest to evolve over time. And this idea that we’re going to get this critical mass of people out You’re all doing change and continuous improvement. And if I think back to some of the early stories from the NUMMI plant that was the success story from GM and and then how much the workers business pay more workers the same managers in the NUMMI plant, but you know Toyota and came in and turned it around because they changed the culture. And I think that’s the thing, because it’s maybe the hardest. It took the longest for companies to come around and realize, yeah, that is really at the heart of what Lean is. Right? Yeah.

 

Patrick Adams  05:37

So true. What if you could say, I mean, there’s obviously there’s many different lever levers that we can pull to try to to have an impact on culture. But could you put your finger on like, maybe your top one or two like these, these are the those areas that are definitely going to have a massive impact on culture, if you just focus on, you know, maybe making changes to this area, or this area that that will have a drastic impact on, you know, creating a continuous improvement culture? Can you could you throw out like one or two of those levers?

 

Tim Schipper  06:14

Yeah, I don’t know if I have absolute, Golden’s levers to pull. But David Mann used to talk about culture as being a hypothetical thing. You can’t change the culture itself. So what is it you can change, you can change the behaviors and the triggers. So one of the most successful things we did over the years is, you know, pull the right one, when you see that trigger, pull that handle. And triggers could be like a repeating problem that you see in the office or whatever group you’re focused on. And then if you see that event, you pull the lever, it’s like, Okay, now we’re pulling the lever, we’ll apply a step problem solving, or we’ll apply PDCA. Or we’ll apply in a three to that problem. And it’s best that if those triggers are closest to the customer, meaning you’re causing some disruption to something downstream, that’s affecting the customer. And those are the most critical to increase your quality. Right? Yeah,

 

Patrick Adams  07:20

that’s great. Good, great, great, great points there. And I like that you said that you obviously quoting David, David man, but the that culture is really, I like to say it’s an output, you know, and there are certain inputs, like you said, the behaviors, the actions of the people, and you can’t change the output, the output is the output, right? I mean, everyone has the culture. It just happens. But to your point, you can change the inputs, you can change the behaviors, the actions of people. And a big, big part of that is obviously leadership. So now, that’s great.

 

Tim Schipper  08:03

Support by leaders, for sure. And that faith that I should be working on these things, because it’s going to make a long term difference. It goes back to the stop and fix behavior, do you really believe in that principle, the fact that you can actually pull the line, stop the production. And think about, we’re going to fix this so it doesn’t reoccur. So you know, you’re looking for those types of triggers. And in the course, in the office, you don’t have that. And Don signal, he can’t actually see the lights flashing, because the line stop, but the principles are the same. You look for those things that are equivalent to an end and you want to, and that takes leadership support to make sure that you’re looking for those things, and then asking for the right behavior when you see it.

 

Patrick Adams  08:53

Yeah. What would be some examples in the office of what you would you would see and consider and and on or await, you know, a signal that you could use in the office that will you would say, you know, this is the signal, you have an issue, it’s time to stop and fix this, like, What would some examples be of what you would see.

 

Tim Schipper  09:12

So in the office, I relate it back to a different type of flow. So in production, obviously, we’re focused on the flow of products through the plant in aerials and workers, but in the office, it’s all about information flow. So you’re looking for places where the information stops, or is delayed, or perhaps has multiple handoffs because of passing through different gates. And usually when it has handoffs, there’s rework and other types of things that are going on. So it’s looking for that information flow, and then where does it get interrupted throughout the organization?

 

Patrick Adams  09:53

Yeah, that’s great. And obviously there’s different ways to develop some visual management or different ways to to I see, you know, the flow in the office just like you can out in production. So, and let’s expand on that just a little bit. So I want to, I want to tap into agile now and start start talking a little bit about that. What would you say are some more similarities between lean and agile as we compare? Obviously, many people when we, we think about Lean many times we, our minds go straight to the production floor, right? And not necessarily in the office or, you know, understanding what’s happening in the computer and how that relates. So what would you say what would be some important similarities between Lean and Agile that people can kind of make that connection?

 

Tim Schipper  10:43

Yeah, what I’ve realized after doing Agile now for about, but I’ve been aware of agile for probably eight, nine years, and then actually actively trying to help organizations put agile in place for the past five or six years, what I’ve realized is there’s incredible similarities throughout every part of Agile. And I had the privilege of being in a session with Jeff Sutherland. Jeff Sutherland is one of the people who signed the Agile Manifesto in 2001. So you’re talking like over 20 years ago now for the Agile Manifesto. And, and recently, I was on a podcast with Jeff and he said, we were celebrating the 30 year birthday of Scrum. So, so it’s been around for a while now. And that’s when they tried the first experiments of of doing Scrum or doing Agile with a small team. But what Jeff says is, lean is one of the roots of Agile. So if you think about, you know, the tree of agile, lean was one of the routes that came out of that original agile manifesto and this key resort in Utah, back in 2001, of which Jeff Sutherland was one of the signers of that Agile Manifesto. And so as I’ve looked at it, there’s so many different similarities, the one that it starts with the most is putting the customer as the focus of value. So this idea of, you know, an agile, where do you focus on you’re focused on customer value, you’re focused on working product, to make sure that you are delivering working product frequently. And then it’s about the individual. So here we go back to that parallel with Lean is it’s about the workers making the changes. In agile, you empower the workers to control the team process, which is a really kind of a radical idea, but it was already in Lean because you’re, you’re giving that power to the production workers to stop the line to change the process.

 

Patrick Adams  12:53

Right, yeah, so true. And those are those are just a couple of similarities. And I was just thinking while you were talking, there may there may be a few people that are listening in that are hearing the term agile for the first time. So I thought about that we should probably back up just a little bit. And you know, maybe a quick definition of what is agile? And how, how do companies use it? Do you mind just kind of filling in our listeners on just a general kind of high level definition of agile and how it’s used?

 

Tim Schipper  14:23

Sure, no, I’m very happy to do that as best I can. So prior to the 1990s, everybody use pretty much a waterfall methodology for any type of development, whether it be product development, or IT development or you pick the thing that you’re developing. It was a waterfall methodology. It had a very long arc as far as defining requirements, design, build, testing, and then showing it to the customer. And what people found is it wasn’t serving companies and organizations very well because you’d get to the end of that long arc and discover a lot of late changes, a lot of missed requirements, and a lot of rework and expense. And IBM did some studies on this. And they found that 80 80% of projects are going over budget or over time following the waterfall methodology. So what Agile does is it breaks down and you do short little cycles of plan, design, build and test. And you do those in sprint so you do those anywhere from one week to four week Sprint’s at Steelcase, we’ve settled on two weeks, we think that’s a good number. And you keep doing those. But at the end of every sprint, you are checking if you’ve created the right value for the customer. So that the end users involved. And in that way, it’s very adaptive. And you’d because you’re constantly delivering value. The other thing it is, is it’s fairly lightweight as a method because all you need to get an Agile team to work are the developers, product owner and a scrum master. And the product owner is all focused on what it is the team should do. And the Scrum Masters focused on the things that help the team do it so that they’re in charge of the team process. Right. And I should mention this briefly at Steelcase. We change those names, product owner, and Scrum Master because we thought it didn’t speak well to diversity, equity and inclusion. So we changed the name to Agile product lead and agile delivery lead.

 

Patrick Adams  16:41

Nice. That’s that’s a good call out. I appreciate you mentioning that. I think that’s definitely something that organizations need to consider for sure. And I love the fact that you are flexible with it. Because, you know, there’s so many times there are trainers or consultants or whoever out there that are like, No, you have to call them Scrum Master, you have to do it this way. This is the only way that it’s going. You know, and I just sometimes I just think, you know, a lot of times, that’s why organizations fail is because they’re not willing to be flexible. And do something like what you just mentioned, change the name so that it makes sense for the culture for the people for the direction that you’re heading. I mean, that’s okay. You know, if you’re getting the benefits of the methodology of the tools, in a better way, because you’re making some some adjustments to how you do it, then, you know, great. Yeah, we actually reviewed

 

Tim Schipper  17:39

that change with Jeff Sutherland and JJ Sutherland. The thing that they mentioned to us they actually changed backlog grooming, which had negative connotations, that word grooming, they changed it to backlog refinement. So this whole idea of adapting over time, this is important. Exactly.

 

Patrick Adams  17:59

So true. And so I want to go back to our listeners that maybe are being introduced to this for the first time. Where would agile be used in an organization? You know, is it product development? Is it project management? Is it only used in it? Where, where? And how is it used?

 

Tim Schipper  18:22

Yeah, it started out in software. And there’s no question about that. So the original agile manifesto actually had the words working software in one of its values, they change that later to working products, because the methodology has been adapted to all sorts of different types of development. So anywhere where you have to solve a very complex problem. And you have to do that in an adaptive way. That’s where agile can be applied. Yes, so it’s been applied in obviously it but now more and more, it’s applied in other areas outside of it. So other parts of the organization where they’re trying to solve a complex problems, they have to stay connected to their users in order to do that. And so they can use agile for for doing that. There was a Harvard Business Review article about three years ago and it talked about how agile is being used from everything from the accounting department right up to the C suites or the corporate top positions in teams and they were using Agile to solve those types of problems.

 

Patrick Adams  19:30

Yep, yep. So true, I see it being used more and more you know, and I love I love the short Sprint’s and keeping the customer you know, in the know versus waiting until the end and then delivering a product a final product or service or whatever it may be that they may or may not be happy with. We apply that that just that simple. You know, thought process is like okay, have we talked to the Customer. While we’re It’s so early, though, it’s so you know, why would we, we gotta get more work done on this before we bring No, no, no, no, no, bring them in, let them see the rough draft, let them be part of that, because we’re gonna give you, you know, information information that’s valuable to direct you as you continue forward. So that that simple thought process I think is so powerful. What would you say? Yeah? And what would you say, you know, going back to lean and agile? What is the central common element between Lean and Agile? Because we work with obviously a lot of companies that are deploying lean into their organizations. And then they’re saying, hey, you know, what about agile? Is that something that could benefit us and how does it fit? I just want to chat a little bit more about that. What would you say is that the central common element between the two?

 

Tim Schipper  20:57

Yeah, so we talked about the first one, which was customer value and putting the user first. The other one is this whole idea of continuous improvement. And the fact that you’re always looking at how to improve the team process. In agile, this takes form in the form of us retrospective at the end of the sprint, you do the retrospective? And that’s where you examine the team process, and how can we do things better. And in Agile, you actually measure this because you’re trying to increase the velocity over time of the work that you can get done. And, again, I’ll go back to Jeff Sutherland, one of the things he said is, a team should be improving 10% every sprint, so you can imagine a productivity improvement of 10% every sprint, that’s a big deal. And that’s what a retrospective is supposed to do is the team is constantly reflecting on their own team process, and thinking about how can they do things more efficiently and better? Love it?

 

Patrick Adams  22:01

What is the retrospective look like? Like? Are there very specific questions that you’re asking for that? Or is there structure around it? What does it look like?

 

Tim Schipper  22:10

A little bit of structure, not much, it’s typically a pretty short meeting of anywhere from 30 to 90 minutes. It involves the scrum master, who we call the Agile delivery lead, and the team. The product owner or the Agile product, lead is optional. But the team there was the scrum master is looking at the team process and, and asking questions, you know, well, how did we do last sprint? Did we get the work done? Where did we run into problems? What are our tools? Like, you know, we’re using the right tools? Do we need to adapt our tools? It’s not a lot of questions. It’s just probably half a dozen questions, talking about what went well, what didn’t go well. And what do we want to change?

 

Patrick Adams  22:53

Yeah, so important. And, again, I think this is a mess for so many organizations, you know, that that retrospective on anything, just asking those simple questions that you just that you just mentioned, what went well, what didn’t go, well? What can we do next time to make sure that the things that didn’t go well are gonna go? Well, the next time we do this? I mean, just a simple conversation around those three questions can be so powerful for any team, right? I’m sure you’ve experienced that.

 

Tim Schipper  23:23

And it’s the easiest one to skip. Right.

 

Patrick Adams  23:30

So true, we’re done. Let’s move ahead. We got other things on the docket? Let’s and man, you’re missing just, there’s some gold nuggets that can be pulled out of that conversation. So definitely a big one for sure. What, what about development? Tim? Can can lean and agile be applied to development? Is that possible?

 

Tim Schipper  23:54

Yeah, absolutely. I’ve seen people do that. You can apply it to development, especially early phases of development, because what are you doing, you’re solving problems, you’re making decisions. So it has to be, you know, a very adaptive process. And, you know, in the first book that Mark sweats and I wrote, we, we talked about rapid learning cycles, and going through that plan, design, build test phase, you know, early on, you’re really complex, knotty problems that the very difficult problems you’re trying to solve. And those rapid learning cycles, those are basically like an agile sprint, you’re just going to go through and quickly learn as much as you can, so that it’ll inform the rest of the development. So yeah, definitely can apply Sprint’s in any type of problem solving environment. Yeah.

 

Patrick Adams  24:43

And for for so many companies that are doing that are that are working our teams, I guess individuals that are maybe listening in they’re working in development. You know, sometimes they they’re like, Well, how do we how do we do these rapid these rapid learning cycle calls when we don’t have a, we don’t have a product, or we don’t have anything in front of us, like, how do we, you know, how do we do that? Like, what’s been your experience at Steelcase or other organizations? And you know how to how to have those rapid learning cycles pushed up front in the process, when you’re just so early in the process? What do you do?

 

Tim Schipper  25:22

Yeah, so the answer is in something we borrow from design thinking, and that’s to create early prototypes. And they can be very rough prototypes. You know, those can be sketches, those can be simple models that you know, make it a workshop, those can be very early representation, sometimes you have to build two models that looks like model versus a works like model, it’s gonna look like this, we can’t quite, you know, get all the mechanics in it yet. But we can show you what the mechanics would look like, eventually. And so you separate those and create those very early models, so that you can then bring the customer and say, Okay, this is what we’re thinking about this, you know, this is how it’s going to work. In it. Sometimes those can look like just rough drawn drawings of the of the screen of the application. So you know, this is what this screen will look like. And if you push this button, there’s another drawing, this is what that screen is going to look like. And if you do these things, you’re gonna get this. So without investing a lot of code, you’re getting a reaction from the end user very early. Right,

 

Patrick Adams  26:30

right. Yeah, that’s, that’s great. And I want to read, I’m trying to think back to our last conversation where we talked about product development. And in your book, I believe you call out like, hopefully, I’m saying this right, the Illa T’s they say that right? Yes. Yeah. Can you tell us a little bit about those and why those are important?

 

Tim Schipper  26:51

Yeah, ility is those are the adjectives you typically use about describing what the customer is looking for. Right? So you know, you know, things like, you know, movability, or might be something like adjustability, or some other ility. Think about those types of words. That’s actually came from BART Hathaway. So Bart was one of my mentors have since passed on. Sorry to miss miss him so much, but But yeah, he came up with that this idea of abilities and describing the requirements in the form of eligibilities. And then how well does your design meet those abilities? Yeah. Love that. Love that. And again, I

 

Patrick Adams  27:32

believe we talked about that in our last episode. So if anyone’s interested to go back and listen, we talked specifically about how to apply Agile to product development. When it comes to development. Tim, what, how do we measure success? What would be an important metric? You know, when applying lean and agile methodologies to development? How do we know that we’re heading in the right direction? How do we measure success for that?

 

Tim Schipper  28:03

It all comes back to your early customer involvement. And are you developing and delivering working product as early as possible? So take some thought, obviously, to break down a big project into smaller pieces that you can actually deliver, and get those in front of the customer and get that reaction. So that developing working product, one of the things just stolen, they asked Jeff Sutherland like what would you change the most about the Agile Manifesto? And he said, we put a line at the bottom? And it would say, yes, we really do mean deliver working product, every single sprint. This idea that you’re completing something, you’re completing the work, and you and you’re able to do that, and do it incrementally as you go forward.

 

Patrick Adams  28:54

Yeah. Well, and it’s an it’s an opportunity to stop and reflect like, we talked about the importance of that, but but also take a minute to celebrate, take a deep breath and then move on, you know, move to the next phase. That’s important for sure. No, that’s good. So going back to your, your, the two books that you wrote, Tim, if someone was interested to grab one of those is, are those available on Amazon? Are they Is there a website they can go to to get some information on those?

 

Tim Schipper  29:27

Yeah, they could go to Amazon and those are on Amazon. You can also go to productivity, press the publisher or get them there.

 

Patrick Adams  29:35

Perfect. Okay, good. So we’ll make sure that we put those links in the show notes and then that way, if anyone’s interested to grab either of your books, they can go right into the show notes, grab grab copies of those innovative lean development and the highly effective office. Both both highly recommended. Tim, it’s been great to have you on once again, love the work that You’re doing at Steelcase and how you guys are applying agile in lots of different areas within the organization. And just appreciate having you back on the show to share some of your your knowledge with our listeners.

 

Tim Schipper  30:14

Well, thank you, Patrick. It’s been wonderful talking with you again. That’s always a pleasure.

 

30:18

Absolutely. Thanks so much for tuning in to this episode of the lien solutions podcast. If you haven’t done so already, please be sure to subscribe. This way you’ll get updates as new episodes become available. If you feel so inclined. Please give us a review. Thank you so much.