GA 178 | How to Apply Lean and Agile to Software Development with Liam Brien and Greg Zimmer

You're listening to episode 178 with Liam Bryan and Greg Zimmer. Welcome to the Gemba Academy podcast, the show that's focused on helping individuals and companies achieve breakthrough results using the same continuous improvement principles leveraged by companies such as Toyota Del Monte and the U.S. department of Defense. And now, here's your host, Ron Pereira. Hey there. This is Ron Pereira with Gemba Academy, and I'd like to welcome you to another edition of the Gemba Academy podcast. As always, thank you so much for taking time out of your day and your week to listen to the show and for watching our Lean and Six Sigma training videos over at Gembacademy.com we definitely appreciate each and every one of you. Now today, I'm excited to welcome two folks to the show, Liam Bryan and Greg Zimmer. Now, I mentioned two because I truthfully thought it was just Liam that was going to be on. And so at the very beginning I'm like, hey, Liam, welcome to the show. And then come to find out there was Greg was on as well. So we had a great chat with both of them and kind of the topic of the day is Lean and agile within the IT and software development arena. And this is a topic that we've not explored a lot on the show. We had Richard Sheridan back on back with Mendel Innovations. We had him back on in the past and I maybe had a few other folks in kind of the IT world. But today Liam and Greg really kind of dive into how they're using both agile and an even more traditional kind of lean thinking and their work and super smart guys, as you'll hear, and they're really creating some really good products over at Cardinal Solutions. And so I think you're going to enjoy the show. We'll link to everything that we talk about in the show notes which you can find over@gembapodcast.com just look for episode 178 again gembapodcast.com and look for episode 178. And a quick plug for the AME conference that's coming up here. It's going to be here before we know it. All the information for that conference, including how to save 10, can be found over@gembacademy.com ame so you can save 10% on a ticket to the, to the show. And most importantly, you can sign up for our cocktail party, which is going down on the Tuesday night on the 50th floor at the Prudential Tower. We got a live band. It's going to Be incredible. So if you are going to the show, you definitely want to come hang out with us on Tuesday night. So all that can be over@gembacademy.com. okay, enough from me. Let's get to the show. All right, Liam, thank you so much for coming onto the show. Where are you calling in from?

We are calling in from Tampa, Florida.

Okay. Is it just you, Liam, or do you have others in with you?

I've got Greg Zimmer here with me as well.

Oh, wow. Okay. Hey, Greg, I didn't know you were there. All right, very good. So we'll just kind of tag team this one, so that's fun. Okay. Well, guys, as you know, we like to begin the show with our guest sharing a quote or two of something that possibly inspires him. So do you guys have one? Or even more than one is fine?

Yeah, so I have maybe a slightly non classical source for a quote that I like. I heard this from supposedly Mark Cuban. He says it's not about money or connections, it's the willingness to outwork and out learn everyone. And if it fails, you learn from what happened and do a better job next time. I think that's kind of a nice, simple way to remember a good principle of learn a lot, work hard, keep trying, keep improving things, hopefully turn out for the best in the end.

Yeah, I like it. Oh, good stuff. All right, guys, well, let's go ahead and have you both kind of tell us a little bit about your backgrounds, how, how you first got introduced to all this continuous improvement stuff that we talk about and then tell us a little bit about, about your, your, your day jobs today, what you guys are up to.

Sure. So yeah, this is Greg Zimmer. Been in the software development industry for 15 years now. It doesn't seem that long. And have worked in all sorts of environments from startups to big corporations. Been with Cardinal as a consultant for almost nine years now and a big chunk of that has been doing agile software development. So that's been sort of my avenue into continuous improvement and lean and so on.

Okay.

Yeah. On my side, I've been involved in IT or software development for around 10 years with a few different industries, so financial services, manufacturing, and then consulting. Most recently been with Cardinal Solutions for about a year now as a consultant and focusing primarily on custom application development using mostly agile project management approaches.

Are you guys familiar with Menlo Innovations and Ann Arbor, Rich Sheridan and the guys over there?

No, I don't think we've come across them.

Yeah, it's a really cool super, super kind of lean thinking organization. Menlo Innovations. Yeah, they're in Ann Arbor right there at the university and really cool stuff. And so probably a great network for you guys to meet up with. Rich, he's an awesome guy, wrote a book called Joy Inc. It's really good trying to bring Joy into the world of software development. So good stuff.

All right, excellent. We'll let them know that Ron promised they going to buy a round of beers and we'll head over there.

I can promise you Rich will take care of you man. Just take, just head on over. Head on over. All right, we'll get some. Well, so let's kind of begin with the software development topic. What does that actually mean when someone says they're in software development?

Yeah, so in our case it means, you know, we're building custom software solutions. So that, that's everything from initial discussions about what's the problem you're trying to solve and what's the value you're trying to get out of some custom software through the process of refining those requirements, building custom solutions, hands on coding, testing that, deploying it and then iterating on that process.

So is it everything from just kind of like web based type applications to iPhone apps or everything in between or.

Yep, everything in between. So everything from sort of cutting edge virtual reality, augmented reality stuff all the way back to some really dated legacy things that banks and big corporations still have around and still have to make money with.

Now do both of you guys, do you have similar job titles or what do you guys kind of do on a day to day basis?

So I'm more on the project management side and Greg is more on the application development management side. So.

Okay, all right. So agile is obviously a great complementary concept to what we would consider kind of traditional lean. But I'm curious, are you guys practicing traditional lean as well or is that more just agile?

I would say we're bringing some lean concepts to an Agile project.

Give me an example.

Yeah, so trying to optimize or control the amount of work in progress, trying to improve the flow of work through.

The process, measuring cycle time, measuring throughput, making decisions and on how we break down work based on those metrics, keeping things very visual, including the team or giving the team well I guess now teams full transparency into all of those metrics as well.

So cycle time is an interesting one. We're a video development team here if you will. And one of our challenges is always, you know, we will plan out a new course or whatever it might be and the guys are they'll do their best to kind of estimate how long things are going to take, but then they might get into a project and all of a sudden this crazy artistic thing pops in their mind and they really go after it to try to make it happen, but it takes a little bit longer than they planned. But we don't obviously penalize them or criticize that because at the end we want an incredible product. So how does that work in the world of software development? When I imagine there might be similar things, you know, where it's how do programmers feel about a cycle time measurement being done on their work?

Yeah, I think that's a very valid point. There is that similar concept where maybe they come up with a more robust solution, but it's going to take more time or they kind of uncover some things as they're going through the work and it just ends up taking more time because we didn't fully understand the complexities involved before we started. When we talk about that cycle time metric, though, it's less about setting that target and living by it, and more about measuring it and trying to over time improve it and bring it down into a narrower range. There are definitely outliers that will pop up. But trying to drive toward an SLA of some sort where when we break down work we have in mind it's something we expect to be able to complete within a certain amount of times from the time we start.

Yeah, and like you said, Ron, nobody's holding a whip over anyone's head or saying you must meet these deadlines. They're metrics that help us measure. Are we actually getting better at the work or not?

Yeah, yeah. Well, I want to dig in a little bit deeper into maybe other Lean principles that you guys are implementing in your work. But I do want to circle back. Like, how did you first find out about Lean? Was it the Agile connection or was it something else?

Yeah, for me it was actually just reading a lot of different business books and I think probably the biggest connection was the Lean Startup by Eric Ries. That was the. I'd heard of Lean, I'd heard of Toyota and the Toyota production system before, but that never really had or played a big part in my work life until the Lean Startup kind of made that connection between software and Lean principles.

Yeah, for me it was more from the Agile development side of things. There are definitely pieces of it that show up there. And then in the local tech community, people start talking about, hey, we're doing this Kanban thing, and various people have opinions about whether that fits well with Agile or not. So start some conversation then. I've had an opportunity to talk with Daniel Vacanti who is big in that Kanban space and that really got my mind going. And then like Liam, read a few books. The goal comes to mind as a good example.

Yeah, yeah, Classic continuous improvement book right there. Yeah. So when you said when you might guys mention Kanban, I'm assuming that you're kind of more on the, you're talking about kind of the visual Kanban in process to do that sort of thing. Are you talking about Kanban cards like we have, you know, in factories?

Yeah, it's definitely more the what, what's sort of called the Kanban boards. Yeah, and it's, you know, it's a type of visual representation of a value chain or a value stream. Much less on the sort of queue or signal.

Yeah, yeah, yep. Yeah, no very powerful tool. We use them here all the time. So I love it, I love it. All right, so I want to talk a little bit about Agile. I don't pretend to be an agile expert and so I know many of our listeners are more, I would say on a traditional kind of lean side, give us a rundown on Agile, like what is it and what's it do, what's its benefits and how is that helping you guys?

Yeah, so in general, from a kind of high level, the main concepts there are about embracing change and in contrast to sort of traditional project model, project management approaches where we, the traditional way would be to do a big design phase up front and try and lock in the design and then do a big development phase and do development and then move on to testing and so on and kind of big chunks, big batches of work. Whereas with Agile we're in a much more iterative, shorter feedback loop model where we're trying to build a little bit, validate that it's going in the right direction, build a little bit more, validate that's continuing to improve, continuing to deliver value, etc. So that's the general principles or big picture view of things.

Yeah, we actually had Eric Reese on the show, oh gosh, year or so ago and to talk about lean startup and kind of the whole minimal viable product concept. So is that, is that also kind of a sounds like similar concepts within Agile, is that right?

Yeah, absolutely. So with software there are obviously advantages and disadvantages, but I think one of the advantages that we have inherently with how software works is the fact that we can produce a small amount of functionality and put it in real people's hands to test and then we can add to that functionality every so and so amount of time. So we can have a product that just gets improved or changed or updated or iterated on as time goes on and as users provide feedback. Whereas we don't really have to. Typically we don't have to deliver one huge batch of work at one specific point in time with all the difficulties and risks that are associated with trying to put something that big and that complex into users hands all at once.

I mean, obviously it varies on whatever type of software that you're, you're building, but are there certain character things that you're looking for in those early, I don't know, beta tests, for lack of a better word?

Yeah, definitely. So there are several aspects to what we look for and what we work on and some, some of those aspects are more clearly on the user experience side. Do, do people know what to do when they come to an application when they see it for the first time? Is it intuitive? Does it make. The ideal is to have a sort of frictionless experience where someone can approach, can use a tool online or use a tool in their business and not need a user manual because the flow and the user experience is understandable and designed well enough to allow that. On the other hand, there are more, call them technical or administrative concerns where we want, whatever the state or the richness of the application, or the website or the mobile application or the virtual reality application, whatever the richness of the feature set, we want it to be manageable, we want it to be stable, we want it to have, in a lot of cases, especially these days, the application has to be built in a way that it's extendable or scalable from day one. That has to be part of the feature set. I'm sure a lot of you yourself and your listeners have heard all about cloud, cloud services. That's a huge part of what we do. And it requires a lot of thinking and a lot of design on how do you bake that scalability in from day one.

Now do you guys get into like any kind of behavioral type stuff where, I don't know, I'm thinking like Amazon, you know, like buy now versus Choose Plan or something like that, you know, or a B testing. And do you guys get into that kind of stuff?

Yeah, so we, we, I would say that we don't personally get into a lot of the nitty gritty around that. Folks that we work with on our teams definitely drive a lot of that type of user experience, research, et cetera.

Yeah, well, there's a lot of cool kind of multivariate type testing and you know, if you have enough traffic to a website like an Amazon. Right. I mean, they're just constantly running experiments on what converts better. So it's always kind of a really cool tie in with many continuous improvement principles. So talk a little bit about, I don't know, maybe challenges that you guys have faced as you've been implementing more of what we would say, traditional lean concepts into your work. What's been hard.

So I think the most.

Sorry. Even better, even better. What have you messed up? Tell us some stories.

Sure. I think that the most obvious challenge that we face, and probably everyone in the industry faces, is how do you scale these types of principles? How do you go from creating, let's say, a mobile application which can be fairly standard, can have a lot of standard components, have a fairly stable language that you write the application in, and not require a lot of size? How, how do you take a situation like that where just sort of quote unquote, normal agile principles work fantastically? How do you take that and now scale to a situation where you have 50 developers or 100 developers or 200 developers required to build a enterprise level application or an enterprise level piece of software? How do you do that effectively? How do you keep communications running smoothly? How do you keep the design coherent and stable? How do you coordinate the work of 50, 100, 200 people? And how do you do that in a way that's effective, efficient, and at least somewhat predictable so you can give more of a reliable prediction to customers and, and internal resources on when is this all going to be done?

So, I mean, do you have any, I don't know, not share too many horror stories, but any lessons learned that you can share? I mean, I assume there's some IT kind of professionals listening out there who might be interested in dabbling in this stuff, like what kind of, I don't know, kind of mistakes have you made and what did you learn from them?

Yeah, I think early on, one of the mistakes I think we've learned from quite a bit is trying to create a solution that's robust enough to match the future vision of the, of the project. And I know that's a little, a little bit unclear, so I'll try and clarify that. One of the projects that we've worked on is a project that requires immense scale, immense resources. There's a significant amount of complexity. In a sense, it would be like an entire factory all focused on trying to deliver a suite of products that would be a good parallel for the manufacturing industry. And trying to bake in all of the security, all of the scalability, all of, all of the manageability of an application like that from day one has been very painful. We've had to pay a bit of a price of things being too complex to get any kind of efficiency out of them. So needing to really work on how do we break complex features down into much more simple, much more manageable tasks that developers can knock out.

Good stuff. Good stuff. All right, I want to circle back to the whole topic of kind of cloud based applications and obviously everything is not everything, but a lot of things are in the cloud these days. I'm looking at my computer here. I've got Box and Dropbox, I've got Google Drive, I've got Evernote, I've got just all these things and they're all cloud based. Right, right. And I've left off 32 other things that are probably running on my machine right now. And you guys have played in that arena quite a bit. Sounds like. So what lessons have you learned from that? I don't know. That type of an application that might relate to lean and continuous improvement.

I think for my part, Greg, I'm sure has a different perspective on this. But for my part, the fact that cloud services and all of the new options and new functionality that cloud brings are almost irrelevant. If you're not hooked at the hip with the customer, if you're not fully aligned and really understand what it is the customer is trying to accomplish, cloud in and of itself isn't going to solve any business problems. It enables you to do a lot of things, scale up the amount of processing that you have, scale up the amount of data storage you have, do a lot of very cool things. But if you don't really understand what the client is trying to accomplish, if you don't really understand the specific challenges that a client has, then you're not going to get a lot of benefit out of it. I think a quick example is we work with retailers who need to expand the amount of processing that their websites are able to handle, the amount of traffic that they're websites are able to handle on given days, so holidays or big shopping days. That's a solution where we can use a lot of what the cloud offers to provide us a solution for that. But that's very different than some of the big manufacturers that we work with that need very consistent real time data analytics. That's a whole different situation that again, cloud can enable. But you have to understand what the client really needs.

Yeah. What problem are you trying to solve?

Right, exactly. Yeah. Start with that simple thing and work back from there.

Yeah. Even we get back to some of the earliest lean books, you know, thinking of Womack and the guys wrote, you know, understand value to your customers. Right. And if you don't get that. Right, it doesn't matter how. How awesome your product is, no one's gonna want it.

Exactly it.

Yeah. Good stuff. Good stuff. Now, I want to go back to something we talked about earlier, a little bit about. You talked about cycle time, some of those, and you've talked about a few other examples. But are there any other lean principles that you think would be interesting for folks to know about that you guys have played with, aside from cycle time and value and that sort of thing?

Yeah, I think visual learning, or I'm sorry, visual management is huge. So we have quite a few tools that keep the work in progress and the upcoming work and the state of work in general, very visual and very easy to access for all of our teams. We're spread out across seven different offices with six different teams all working in coordination with each other. So having those electronic visual tools is immensely important, improving the capability and the proficiency of every person. So continuous improvement, not only in our processes, but also in the skill and knowledge level of the people that we work with has been immense as well.

Now, do you guys dabble in any traditional visual management with things written up on whiteboards and that sort of thing, or is it all electronic?

Yeah, as much as we can. We love the physical visual tools. I mean, if we had all our teams in one location, we would have the ability to have one kanban board up on a big wall and use cards or sticky notes and all g around a physical space. I've done that in previous jobs. So has Greg. There's just something that works much better when you have the ability to have everyone co located and use physical tools to share that visual status.

Yeah, yeah, we use. Sorry to interrupt. We use very large CRM at Salesforce. Everybody, that's okay. I think it's okay to say we use Salesforce here, Gamba Academy. And you know, obviously, as you guys probably know, Salesforce is this monster, right? I mean, everything's in there. But our customer success team has most recently created this huge whiteboard over in our office and it's got all this information and guess what? It's all in Salesforce. Right. And so they pull it from Salesforce and then they put it up on the board. But I'm Telling you it's like changed our world by just having these things up on a wall where, you know, different colors mean different things and just bringing it all out into the open has just been. Not that we will abandon Salesforce because we still need that for, you know, the heavy data analysis and crunching and reports and so forth. But yeah, putting it up on a whiteboard has just been a game changer for us completely.

It's. It does. I don't know how to explain it, but I've seen it personally. So has Greg time and time again. When you have the ability to get people around a physical board and just use sticky notes or cards or whatever you need, you color coord it and you make it fit the specific team, it works great.

But again, you need smart software to help you get that information because without it, you just have a big whiteboard. At least we do. We're not smart enough to do without. Tells me so. All right, hey, so let's say someone's listening to this right now. Maybe they're in kind of a traditional IT world, software development world, and they're thinking about maybe kind of getting into this. Maybe they've dabbled with Agile, but they want to get more in understanding of Lean. What advice do you have for that person as they kind of begin their journey?

I think the biggest advice is don't be afraid to fail.

Right.

Mistakes are a great way to learn is what I found.

Yeah, yeah, yeah.

I'd say there's actually a good number of IT or software specific people who are talking about Lean concepts. You have people like Steve Bell, Mary Poppendieck, Jez Humble. There's a lot of people out there. YouTube is a great source to listen to talks by these. All of these people, they have lots of books. A nice, I think gentle introduction into some lean concepts is a book called the Phoenix Project by Gene Kim. It's certainly something that will give people a sort of a high level understanding of how Lean concepts actually can work in an IT world.

Gets stuff. Last question for this section, guys. What kind of trends do you see coming perhaps, I don't know, five, ten years down the road? I know it's probably in. Maybe that's too far out. I don't know, maybe in the next few years as it relates to Lean and also maybe just technology with manufacturing.

Yeah, we're seeing a huge amount of data collection and data analytics that is massive and that has quite a few facets. So if it's actual physical devices that produce data and send it off to a database and then collecting that, storing it, securing it, and analyzing that, and then providing a usable dashboard back to manufacturers or big utilities that we work with. We see a huge amount of that. Virtual reality and mixed reality are literally exploding right now. There are so many business specific applications that again, a lot of the manufacturers we work with have found a huge amount of ways to improve how they, let's say, path people through a plant to sort of reduce wasted motion, how they help people understand how to go to a rack of bins and how to sort of pick and sort parts and prep them for assembly. There's an immense amount of work in that space. And then I think the last biggest thing we've already talked about is cloud. What does that mean for your business? What can cloud do for you? For example, that ability to scale up instantly, or more correctly, scale out instantly. Have the ability to store your data in multiple locations around the world for security purposes and redundancy purposes. Those are all things that have become extremely important. And cloud allows you to do that fairly easily.

You mentioned databases. I just want to let you know I used to be able to create a mean access database. So if you guys ever need any help, just holler, man. I'll pull out the old books and we'll get back after it. Oh, boy. Definitely wasn't the most awesome things that I've ever created, but they served their purpose when we didn't have any money. All right, good stuff. Well, hey guys, let's go ahead and transition into the reflection section. And really curious to hear your answers on some of these because you're coming from a very different industry than most of our past guests. And so this first one is we spent a lot of time within Lean talking about those two pillars of the house, so to speak. And one is this continuous improvement. So those are the tools, the things that we can do. It's a little easier to define, but the other pillar is respect for people, and that can be a little bit more difficult to wrap our arms around. So I'm curious to hear from, from both of you what respect for people means to you guys.

So I'll kind of echo something I've heard on your show in one of the past episodes. I apologize, I can't remember the person's name who said this, but someone said that if you take the Japanese concept of respect for people and break it down a little bit more, it more correctly translates into respect for humanity. Yeah, that's echoed very strongly. Understanding that at the end of the day, reducing waste, improving Communications, improving processes, making better products. It all comes through understanding who we're working with, understanding the fact that we're all people, we all have emotions, we all have variations in those emotions and being very comfortable to work with the human side of technology.

Yeah. Well, I'm sure that the folks that you work with directly, but also you have a very awesome opportunity to develop more human, like applications that people are going to really benefit from. So that's pretty awesome.

Yeah, absolutely. The better the job that we do, the less of a job it looks like we did.

Yeah, yeah.

When things are just simple and easy and you just get it the first time you use it, that's success.

But curious to hear maybe some of the best advice that you've ever received.

For me, I think I just have the sort of cliche answers. Right.

Of.

Never giving up, learning from your failures, always striving to do better. All of those roll together into having persistence and a desire to learn and improve and. And that's really the biggest thing for me.

Yeah. Back to Mark Cuban's quote, I guess. Right. So has there been an experiment or project that didn't turn out quite like you guys planned? And if so, what did you learn?

I can give a quick example while Greg kind of thinks that one over. In a previous company I had worked with a fairly large financial institution on introducing a new financial product and the project was not expected to be too long. So around four months, start to finish. I think the big lesson for me came from the fact that in a sense that project was run perfectly, quote, unquote. We did a huge amount of design and discovery and talking to the customer and really understanding the end state and the value of the product and understanding how customers would use it. We had expert people who knew the software, who knew the platform, who knew the business side of it. We had experienced managers, experienced executives on the side of the client. Everything was sort of poised for success. We did pretty detailed analysis on all the requirements, designed a solution that was fairly simple and implemented it iteratively, did frequent check ins with the client to make sure that we were always on the right track, tested everything as we were going, did a very organized deployment into production, validated it within a very short order of time, a few hours, validated that everything was working in production as expected, great success, everyone slapping each other on the back, and then a week later coming to find that a big part of the functionality was just missed in all of the conversations and all of the documents. And now had to, now we had to scramble to get that up and running and into production, which of course then throws off the relationship with the client. It can have some effects on, on the, the software itself. It certainly can mess up some of the financial side of, of things. So I think the big lesson there for me was mistakes are going to happen. Always plan the best you can, but always have a contingency plan. Always be ready to handle that completely unexpected eventuality. Interesting.

I was just going to say, I think I have many examples of projects and experiments that didn't pan out the way that we had hoped or planned. I think the most relevant things though all really come back to that respect for people and when we don't do as well as we need to with that. So whether it's we're going to roll out a process change or we're going to bring new people onto a project or any of these things that introduce change into sort of the system of our teams and project and, and so on, underestimating the people aspect of that. So getting buy in from people, making sure they have an opportunity to contribute and understand and be involved and all of those things that if you skip any of that, really results in a less than desired outcome. Right? Yeah.

Yeah, good stuff. All right, last question guys. So you've both got a lot of experience in this kind of software development world and you've got good experience in Agile and also learning a lot about Lean. But is there one knowledge or skill area that either of you feel like you want to improve in the short term and if so, what's your plan?

Yeah, I think domain specific knowledge is something that I have always felt I need to constantly get better at. So whether it was in financial services, truly understanding what mutual funds are, how they work, what stocks are, how they work, what are derivatives, how they work tended to always reflect right back on the quality of the projects that I was working on. Having deep domain understanding in manufacturing, understanding what a lathe is versus what a CNC machine is, understanding what, what a caliper was, understanding what a quarter inch ball end mill is directly helped me talk to people and understand what they're talking about and how to work better with them. Software is exactly the same. Understanding what a web socket is, understanding what a reverse proxy is, understanding how an IP address works, those are things that seemingly aren't necessarily required to do the job of managing a project, but understanding those domain specific principles is a massive help. So in terms of a plan to follow up on that, a big part of that is keeping a journal with specific terms that I come across and then making time, specific time to meet with people to understand the term or how a system works, or finding a specific YouTube clip or a book that talks about a concept like domain driven design is another example.

Good stuff. All right, well, hey, guys, it's been great. Gosh, I'm looking it up. It's like we've been on for like 40 some minutes, so that's a great sign that. Lots of stuff. Stuff talked about. So thank you for carving out so much time to visit with us. Let's kind of wrap things up with you sharing some final words of wisdom. And then why don't you tell folks how they can connect with both of you?

Sure. So I think final words of wisdom are there's a lot of knowledge out there about it and how to manage it successfully. There's a lot of knowledge about how to manage production successfully. And I think there's a massive amount of crossover and a massive amount that each industry can learn from one another. And it kind of goes back to that old kind of the theme of the conversation, respect for people, respect for humanity. I think at the end of the day, there are very clear guiding principles in manufacturing that translate perfectly over into software development and vice versa.

Yeah, good stuff. And how can folks connect with you guys, you social media hounds and all that?

Probably less than we should be.

Okay.

For me, I think LinkedIn is typically the best way to get in touch with me.

Okay. And go ahead and spell your name so everyone, if they're only listening, so they can.

Yeah, absolutely. It's Liam L, I, A M, Brian B R I, E, N. Okay. And if you look that up, we both work for Cardinal Solutions. If you look up Liam Bryan, Cardinal Solutions, or Greg Zimmer and Z I.

M, M, E R. Correct.

And I'm on Twitter, but very rarely post. But feel free to reach out. To me, it's just Gzemmer.

Yeah, I'm on Twitter. Don't reach out to me because I won't see it. Yeah, I'm not a big Twitter guy, so. All right, well, good stuff. Hey, guys. I really appreciate talking with you. I had a good time. Perhaps. Well, I don't. Do you guys ever get out to any kind of conferences or anything like that?

We do, yeah. Mostly on the software side.

Yeah.

Yeah, we should. Guys should come out to, like, the AME conference. I think you'd like that. It's, you know, obviously more of a manufacturing world, but you guys have a lot to offer that world, so that probably be some pretty cool networking we do a killer cocktail party, too, if nothing else.

Well, if you can figure out how we can get a demo of some kind of crazy 7 axis, you know, CNC machine. You got it.

Well, hey, there's a lot of people listening to this, so hit us up if you got one. All right, good stuff, guys. I appreciate you, and we'll talk soon.

Thanks a lot, Ron. Take care. Bye.

Thanks for listening to the Gemba Academy podcast. Now it's time to take a free, no strings attached, fully functional test drive of Gemba Academy's School of Lean and Six Sigma. Over at Gembaacademy.com gain immediate access to more than 500 Lean and Six Sigma training videos free of charge@gembacademy.com.