Lynn Thames' business Excel Software Services, helps manufacturing and distribution companies with software automation. She joins me to help answer the question: What does software development have in common with manufacturing?  Her answer: Agility.

In this episode

• Who is Excel Software Services, and what they do
• How Excel was founded by Lynn's father in 1978
• What kinds of companies Excel work with, and what problems they need help solving
• How Excel solves these problems, with SaaS and custom software solutions
• The challenge and dangers of vendor lock-in when building on a third-party platform like Magento
• Parallels between manufacturing and software development
• The challenges and benefits of doing agile software development for clients
• The importance of trust and buy-in for agile software development
• Value-pricing software development
• Excel's switch from waterfall to agile and Scrum
• Estimating development tasks for clients

Resources
Book: The Phoenix Project
Book: The Goal
Value Pricing

Guest
Lynn Thames
Excel Software Services

Transcript

Jonathan Hall: Ladies and gentlemen, the Tiny DevOps guy.

[music]

Jonathan: Hello, everybody. Welcome to another episode of Tiny DevOps where we talk about solving big problems with small teams. I'm your host, Jonathan Hall. Today I have with me, Lynn Thames. Lynn, thanks for coming on the show. I'm so glad you're here. I met Lynn on a slack group where we both talk about some of our business challenges, and I discovered that Lynn works with manufacturing companies with some of their software problems. I was really curious to get to pick her brain a little bit and learn about some of her insights on this. That's why I brought you on today, Lynn. Before we start talking about that, would you give our audience a little introduction, tell them about who you are, and describe better than I did what you do?

Lynn Thames: Sure. I own a company called Excel Software Services. I've been working in software for manufacturers since I was about 20 years old. I've always worked around manufacturers. I started my own business in 2001. I've expanded our offerings when we used to do only manufacturing plants software, and now we do a lot of integrations. We'll do some websites when we have to, but our specialty is really solving those business problems, getting their different systems communicating, especially with their e-commerce, and a lot of automations, and just workflow solutions.

Jonathan: Nice. How big is your company?

Lynn: There's nine of us.

Jonathan: What's the breakdown? How many of you do engineering work, software development work, sales, marketing, things like that?

Lynn: We have one full-time support rep, whose entire career has been spent in manufacturing and distributing as well. He can support from our customer's perspective. Then we have four developers and a business manager/salesperson, because we really don't do a lot of sales, we're mostly referral-driven. We have an IT person and then a friend and developer that are both part-time.

Jonathan: Really good. It sounds like a diverse group. Since many of the people listening I'm sure are not familiar with manufacturing and distribution and so on, could you maybe paint a little bit of a picture like that? Maybe what's the typical customer of yours look like, and what do they do?

Lynn: Okay. Gosh, no typical. I've got anything from a designer, boot company, like cowboy boots to cell phone accessories, racing motorcycles, an Italian racing motorcycle company. Let's see. Business forms, printing industry, health supplements, you name it.

Jonathan: That's a lot of stuff. That's interesting. I'm sure I'm going to make a wrong guess here, but that's why you're here to help me learn how this works. I imagine that they're involved in the physical manufacturing of, say, boots, they're sewing the leather together or whatever, and they have software that helps with that, and you help at that stage?

Lynn: I do not so much help with the assembly line or the manufacturing process. There are times when we might pull technology into that process to measure things that mostly my expertise is going to be in the fulfillment logistics for delivery and working with their buyers.

Jonathan: Once the product is complete, the boots are completed and put in a box, that's where your expertise comes in with helping to do inventory management and shipping. Is that right?

Lynn: Yes. There might be a little bit of crossover there. If they're focused heavily on just-in-time inventory, then we might dig deeper into their processes just to understand what levels we need to start triggering new orders and stuff like that.

Jonathan: Do you help on the supply side, like with the raw materials that come in, and that sort of stuff too, or just on the other end?

Lynn: Not at all.

Jonathan: I'm curious. What kind of problem does a client come to you that you help them to solve?

Lynn: Mostly it's going to be one of two areas. Either they've got an in house system, their ERP, whatever it is, and then they have some other platform, whether it's salesforce, their e-commerce site, another CRM, or really any other third-party software, and they're struggling with having to duplicate that entry, or one of the systems gets data wrong, and they don't have any checks and balances. That's one big area.

The other one is just in processes that don't work well, for example, spending too much time manually processing payments for orders, if their model requires lead time, they can't actually charge the customer's credit card when they place the order because of the limitations of the merchant account. Automating that process so that they don't have to manually post payments three to four hours a day. That's just one example, but the automations can be anywhere. It's just really anytime you have a broken process, they'll reach out and say, "Hey, can you help us figure this out?"

Jonathan: You do this with some custom software, or do you have off the shelf, maybe a SaaS or something? What do you do then to solve these problems?

Lynn: We actually do both. We do completely from the grounds custom software for some people if their needs just don't fit anything we have. We also have a few connectors that are built around specific ERP systems, and that we can easily customize to match pretty much any e-commerce platform or CRM. Then we do have a couple of SaaS products that are just out of the box that really fill a specific need. We have a customer portal, where if you do most of your sales to wholesalers or resellers, and you want a very B2B experience, we have a customer portal that takes e-commerce to a B2B level, where it's really meeting the needs of a wholesale buyer, instead of the bells and whistles of an e-commerce shop.

Jonathan: I'm curious how did you get into this line of business? You said that you've been doing stuff like this since you were 20. What got you interested in this, and how did this business grow out of that interest?

Lynn: That's my favorite story. My father, who founded the company in 1979, he started working in a business forms manufacturing plant in his early 20s sweeping shop floors and rose up from there to running a printing press. Then through the years, he rose all the way to be the VP of costing and estimating for one of the bigger manufacturing plants in the country. He was tasked with the job of creating a computerized estimating system. He hired several developers and they could never get it, because they didn't understand the complexity of manufacturing and costing and estimating, all the different pieces that went in.

He eventually just decided this would work better if I just did it myself. He taught himself how to code so that he can write their application. That was on a huge mainframe way back when. After that was successful for them, he wanted to sell it to other manufacturing companies, and their parent company was like, "No, we don't want to sell this, we want to keep it internal for ourselves." He sold his stock options, quit his job, and took a little bit different direction. He ended up writing it on a super brain-computer, which is like a preemptor to the PC. Just sits on a desk with two floppy drives and rewrote it from scratch using a different language without the big mainframe, and that's where it was born.

Right out of school, I wanted to work with him in-- it's the only job I ever had until I bought him out with my brother and sister in 2001. Believe it or not, my dad still actually works some. Several hours a week, he pops in and he's always got some little project he wants to work on on the side, and he's always helping us with some of the things on the manufacturing end.

Jonathan: That's a great story. I understand why it's your favorite. That's a good story. I think we talked about this the other day when we were talking, but I was curious, is the software that you develop for your customers, is it cloud-hosted or is it hosted maybe in their manufacturing plant or some combination?

Lynn: Yes, a combination. Our software line that we have for printing companies that is housed in-house, it's built with Microsoft SQL Server on the newer versions. We actually still have some that are still using old-fashioned dBase IV files. It's an industry that doesn't move very fast. They're happy with what they've got. Until it stops working, they're not going to change. Most of our new development is web-based. Our SaaS products are all web-based. If someone comes to us wanting something custom, if it makes sense for it to be local, then we'll do it with VB.Net. If it doesn't, then we'll do it with one of the few PHP-based frameworks is what we use mostly in the web.

Jonathan: Now this estimation software that your father wrote, is that still being used, or has that evolved beyond that? It's still being used?

Lynn: It's still being used. When he wrote it, there obviously was no Windows back then. We turned it into a Windows software. Really, for the companies that use it, it pretty much just runs their entire manufacturing plant.

Jonathan: I wonder if you might be willing to talk about some of the maybe challenges that you've experienced, whether technical-- Probably technical challenges, but it could be anything. What is something interesting that you've had to deal with in maybe the last couple of years or so?

Lynn: We've got a couple of clients actually that have very unique challenges with processing payments that no out-of-the-box plugin would cover for them. Either their average payment is well above the maximum for an eCheck or something like that, or they just have a very unique workflow for when they can charge payments. We built a automated payment system that was specifically for our one client, but we've been growing that and adapting it to other needs. That's probably one of the things we do best, is utilize something that one client needed, and be able to just take pieces of that or pull up different solutions together to meet another person's needs.

The most challenging thing I think we've done was, I don't know how well versed you are in the e-commerce realm, but Magento. When Magento decided to make Magento 1 End of Life in June 2020, and their upgrade to Magento 2, which is their new version, it's not an upgrade, it's a totally different platform. You have Magento 1, you want Magento 2, you basically are starting from scratch. That process, which started sometime in 2018, towards the end of 2019, was just such a challenge that we actually realized as a small company, we cannot keep up with the Magento world.

We tried to let go of all of our Magento customers. Some of them are holding on for dear life, and we still help them, we still serve them as we can. That was our big challenge, was just deciding that a platform was not feasible for us to continue with and cutting ties and then finding new things to do to replace that which had been it'd become about 35% of our work at that point. I would say that's probably the biggest challenge when you're mostly writing around other software is when you either outgrow that software or that software outgrows you, or it just turns into too much trouble for the money that you're bringing in on it and then you have to pivot again. We've done a lot of that in 20 years.

Jonathan: Yes, I can imagine, especially when you're in the tech industry. Very few tech companies are doing the same thing today they were 20 years ago. That's almost impossible.

Lynn: Exactly.

Jonathan: One of the reasons I was interested in picking your brain a little bit is because I work with DevOps. One of the most popular books about DevOps is called The Phoenix Project, which is based loosely on a previous book called The Goal. I don't know if you're familiar with the book, but it's about the manufacturing process and Slack in the manufacturing process as a way to identify bottlenecks and stuff like that, which I realized isn't exactly the area you work in, but it overlaps with what you're working.

I was really curious to talk to somebody who's actually worked with manufacturing companies and not just the theoretical idea of how computer software is similar to manufacturing. You do both. You work in both software and with manufacturing companies. What parallels do you see, from where you work, between the work you do, the technical work you do, and the manufacturing work your clients do? What lessons can we learn from each other?

Lynn: That's really fascinating. I think to put in one word, agility. We do all of our dev-- We operate Agile methodology as much as we can. It's a small company. We had to pick and choose the different pieces of different frameworks that we use. We try to do Scrum, but there's a lot of similarities to being Agile in development and that continuous improvement or continual improvement. With Lean Six Sigma, and whether you adopt that fully, and whether you have all of the roles in your manufacturing business, which most of my clients do not. They know what it is, and they may if they have a big enough problem, bring in an expert.

Mostly, they are not manufacturing to the level that they need to get to the .034 defects, because they're not making oxygen, as one of my other mentors likes to say, is, "We're not making oxygen here." I think that the process is very much the same. Even if you don't have the Six Sigma experts on board, if you look at your manufacturing processes or your software processes from the Agile methodology perspective, then you can always find one next thing that you can work on, improve, and then monitor for whatever your timeframe is. Typical in Agile development, it's going to be a two-week to one-month cycles.

That I think would be similar. I think that's something that I sometimes bring to our clients when they come to us with a problem is I'll try to box it into that same framework. "Okay, what's one problem? Let's address that. Let's fix this one situation you have." Once we can say, this sprint is what we call them, "This sprint is done and we've delivered this. Now, what's the next thing we can help for you?"

You might remember, one of I think the things that got us started talking in our Slack channel was a post I had made about that ongoing type of consulting, where there's not one outcome or one result that they're looking for. There's maybe 100 of them, but if there's 100 of them, we're not getting all of them this year. The thing is the most trouble for them today, and we can knock that out on a month, then they're super happy, and they're ready to move on to the next thing.

Jonathan: Do you call them sprints, what your clients do? Do you talk about what are the goals they can accomplish in two weeks or something like that?

Lynn: Actually, if we're developing anything for our clients, we do use sprint, and we do use two weeks with them. When talking to them about their problems and how we can fix the problem, it's not necessarily going to be, "What can we fix in two weeks?" We'll maybe talk about it in the terms of what is your biggest pain point right now? Right now I have an email, but I keep having it snoozed until tomorrow morning because I don't want to lose track of that, that our clients send their next five objectives. Maybe two of those, I'll be able to fully handle for them, but one of them is building a Shopify shop, and we're going to want your input. I don't do Shopify. I'm not going to do any of the development that they're going to want me to help with pieces of making sure that they do it in an effective way. If I was to take that top thing, once we figure it out, it might be like a three sprint job and that's how I'll communicate it to them, as you know, three sprint, six weeks, and are basing right now.

Our pricing is based right now on the sprint. We tried to do value-priced, but it also was, when we're doing continual work, it's a lot just based on how many sprints it's going to take us. I'm trying to balance on that beam right now trying to figure out the happy medium, between being truly Agile and the make decisions and change things as we go with value pricing the end result, because with Agile, you don't really box your customer into even an objective. They get to change their mind along the way. It's really hard to marry those two parts of the different ideologies, I guess.

Jonathan: Yes, I see. By the way, for anybody listening who's not familiar with the term value pricing is something Lynn and I are both very familiar with. It's basically the idea that when you're doing a consulting engagement with a client or any kind of engagement, I suppose, you try to determine the value for the client and you base your price on that rather than based on how many hours or days or whatever. It's a different way to come to a fixed price, just for clarity. I'll put a link in the show notes for anybody who wants to read more on that topic.

Back to what I was going to say, I think there's a strong correlation between this idea of value-based pricing and software agility. In the sense that both of them, when they're done correctly, are focused on the outcome the customer wants, rather than on the inputs that we create, or even the outputs that we create. Traditional waterfall software development approach is concerned with how many developer hours or whatever, is a take, which I think is completely backward from the approach you're talking about, and I love that you're talking about this because I completely agree that, what are the five things that you need the most?

It is a much more valuable question to ask the client than how many hours do you think it's going to take for us to do this, whatever thing it is? I'm excited to hear you say that. It's good to hear that, and actually, I want to ask you about this. I hear a lot of people talk about how Agile software development is great in theory, but it doesn't work when you actually talk to clients because clients never want to hear. They never want to give you a prioritized list. They want to know, what are we going to have done in six months? It sounds like you've succeeded in turning the tables somehow.

Do you ever get pushback from your customers that they want a six-month commitment or something like that? How do you deal with that?

Lynn: Pushback from customers, no. Pushback from prospects that never become customers, yes.

Jonathan: [laughs] Very good distinction.

Lynn: Yes. I actually have one client right now, and I hope they never listen to this because they'll know I'm talking to them. They wanted a mobile app to replace a web app, or to work in conjunction with the web app that we've built them before we were in Agile. We're probably going on 18 months since we had the conversation and they still want it, but they're still just not happy with pulling the trigger on doing it Agile. They're pretty dug in. They haven't gone to find someone else to do it yet, because I just don't think they feel like that's even feasible. They know who the right people to do it.

Some people are just very, very opposed. Now, some people can listen to a reference, for a caller reference that can say how it benefited them to do it that way. I think that's helpful, but to be honest, there's a lot of trust. You have to have a very high level of trust level to go into a project with a software company, not knowing what your final cost is going to be. There's a way around that. You can do Agile and do value pricing if you're really good at it. I don't know that I would say I'm really good at that, but we have done value price projects where we actually quoted a price, and we just treated it Agilely.

We've had some that have been successful and a couple that have not been successful, but to do the real, truly Agile, where you start with a roadmap, and you work with someone on the client's team, who is the product owner, to build it out as you go. There's a lot of trust there because there's too many unknowns, and they're scared. We're finishing one right now that was really anxious about that before they bought in. We've come in, so far, we're almost under budget, we might actually finish under budget or not under budget, but under roadmap. For them, because they were able to not pay us to do some things that they realized weren't that important, they ended up saving money.

There's a lot of give and take, and I think it is a hard sell. I think it's going to be easier to sell to really large companies. We don't work with really, really large companies, but when you've got a whole team of people that are going to be working with the development shop on it, then I think that you would probably have a little bit more because they're going to be more technical anyway when you're dealing with the IT part of a bigger company. I don't believe it's true that it's good in theory, and not so good realistically to work with clients more. I just think it's a harder sell. When you're doing it with existing clients that already trust you, it's a lot easier.

Jonathan: Right. You mentioned that you have a mobile app client that you started with before you started doing Agile. What made you change to Agile. What convinced you that it was a good idea and how did that work?

Lynn: That's a very good question. I have to say, probably the biggest thing is I've got two kids who are engineers. They both work at companies that utilize Agile methodology. Probably the biggest thing is just the talk around the Thanksgiving table. It's pretty pathetic, that that's what we talk about around the dinner table.

Jonathan: I wish we would talk about that at my Thanksgiving table.

[laughter]

Lynn: We're not allowed. The dad's side of the family gets in trouble when we get too deep into that. Being able to leverage their experience, and we have been struggling with finishing projects on time, and within budget. When you're fixed pricing, and you're not in budget or on time, it hurts you the most. I had been looking for ways to be more efficient, but that wasn't really helping.

There's just aspects of the Agile framework, or the Scrum framework is what we've adopted mostly, that it's not that we're necessarily pricing different. It's just empowering the dev team, making sure just all the little pieces of what makes Agile and Scrum great. Just focusing on those little things has really made all the difference in the world to us. I hope that makes sense.

Jonathan: Yes. Well, it does to me. I think it's good to hear a success story because, I don't know, at least on social media, there's so much negative talk about how, like I said earlier, Agile is great in theory, but it doesn't work in these situations or it doesn't work when you talk with clients or doesn't work when your CEO doesn't agree. It's great to hear of a company that's doing it successfully.

Lynn: Yes, and I think there has to be a lot of buy-in. That might be why you've got devs on social media saying, it can be really hard to convince your salesperson to try to sell a client on a different project management perspective, but any client that I've taken through a project using the Agile methodology, even if they paid a flat fee upfront, even if we didn't charge them by the sprint, but just the ability to have input along the way and knowing-- Some of the biggest things that we found are number one, putting more emphasis on the user stories and the story mapping so that the developers actually know what they're building and why and for who. It's easy to talk about user stories.

As a soccer mom, I want to search for the right soccer shoes for my child so that they can become a soccer star. You see all of that, but really the value in a developer knowing the whole story behind what they're working on. That brought a lot to us and then just the team effort, instead of all the developers working on their own thing and being accountable to each other. That was probably a six-month to nine-month learning curve, but once we got that, that being such a small company-- both of my kids that are engineers, their companies have dozens if not way more teams of nine or more people each. Even with a small company like ours, just having that accountability to each other.

That was another thing and then the last thing I would say is, when do we finish this sprint and showing it to the client. It just really keeps you. Once we got to that mark where we could do that and started, how can we do it better? How can we finish more? Now our goal is to not only have something finished, but have it finished, installed and signed off on and built before the end of the sprint. It just makes us laser-focused on getting things done, which is super helpful in a smaller company.

Jonathan: I'm curious if you don't mind talking about this aspect, you said you build per sprint and you do value pricing. Can you paint that picture a little bit more clearly? I don't want numbers, but how do you figure that out.

[laughter]

Lynn: Probably not. I'm trying to learn to do value pricing better. To me right now, I don't have a lot of experience with pulling the value out of prospects. It's actually easier with prospects than it is with existing clients just because the relationship dynamics are already there. They're going to be really weirded out if I start talking to them differently than I always have. Even with prospects, I'm just not comfortable with the value pricing. I know something's very, very valuable because you can sense it by the way they're talking about it, but getting to the point where I can put a number on it, that's a struggle for me.

This is not advice for anyone else to follow, but what I've done is just somewhere in between it's going to take us. The way we do our scheduling for sprints is we have four blocks and we can't have anything that won't fit in four blocks. If we're doing a bigger project, it's going to take up two of those blocks on its own. Then we might be able to fit in one or two smaller things that can be done in one sprint or two sprint at a time. We don't bring on anything else until those are completely done and over with. To bring that back to pricing, we have a specific price that we charge for being one of those blocks.

That's really just our way of knowing if we hit this target we've covered our cost, we've made our profit goal and we have plenty of time to actually get it out the door. Somewhere in between that number and what I think it's valuable for them is usually where we're hitting when I talk about doing a value price and that's really just because I'm not confident, is probably the best word, in my abilities to actually a value price.

Jonathan: You said that a client will tell you their goal or objective and you'll tell them how many sprints. How do you determine that? How do you decide how long this thing will take?

Lynn: I still get estimates from my developers and then we add on time for QA and then I realize knowing about how much time they have available in the sprint per block, which is what we call them, and that's something we just totally made up because we're not in a position where we can ever just work on one project to the exclusion of everything else until it's done. When you're working on a project for a year, you can't tell everyone else, you have to wait until the year's up. We don't have a second team to give things to him.

A lot of it is just instinct and knowing if a developer tells me the actual coding time is going to be 25 hours, then I can figure out, "Okay, I think that's probably going to take him or take us two sprints or whatever to turn that around." We started doing it by what we think we can turn around in a sprint instead of the number of hours. If we miss it, we just work harder in that sprint to still get it within the sprint. I feel like it all washes out eventually.

I've become much more focused on getting all of the objectives done in the sprint than how much time we spent against any one task versus what we estimated for that task. Which is what we used to try to do that is, okay, we estimated eight points for this story and we track time and it was five and a half hours, which is technically more than you should have spent on an eight-point story. We just don't really do that anymore, we really do it by what did we think we were going to get done in this sprint and did we? If we didn't, why?

Jonathan: You started to answer my follow-up question, which was going to be what happens if the estimate turns out to be wrong? I think you've already answered that.

Lynn: Generally, we just start working harder in the middle of the sprint because when we realize we're off, we just up our game. Because it's easy to see when you're looking at it from the Agile standpoint, we know what we have to finish within two weeks, you see when you're off track. You don't really see that-- maybe the project manager with the waterfall chart and the gantt chart, he sees it. When you're just talking about different tasks and where they stand in a longer-term project, you don't really see that correlation.

We see it, we fix it. A lot of times when we're off, it's more because we didn't get information from the client or we didn't finish it enough before the end of the sprint to be able to get the client to sign off. In those cases, we have something we call overflow and we just take it in the overflow bucket, and then that client just-- we also try to bang it out as fast as we can in the next sprint, but it affects the next sprint, so we really try not to do that. It eats up a block.

Jonathan: How often does that happen, that you underestimate something?

Lynn: Not as often. Early on, it happened every single time, and we've only been doing this-- we're probably only about two and a half years into doing Agile. The last few months, maybe two or three times, but usually, they're very close. For example, the last one we had that had to go into overflow, it was finished. It could have been signed off one, but the client was off Thursday and Friday, so we just couldn't get the sign-off. We had to put the sign-off into the following sprint. It's been a learning process for sure.

Jonathan: It sounds like it and of course, we always all have more to learn. It's encouraging to hear your success and some of your challenges too. Lynn, if anybody's interested in catching up with you-- First off, maybe you want to tell us how to find your company. If anybody listening has a family member who does manufacturing that needs some automation help, maybe they can point them your direction. How do we get a hold of your company?

Lynn: Our website is excelss, as in Excel Software Services, .com. That's the best way. We don't really do social or anything like that. There's a phone number on there. We actually answer phones because we work in industries where people like to pick up the phone and call. It goes to our support desk and so our support guy picks it up when he's there. When he's not there, then it just goes to voicemail and he returns the call. That's the best way.

Jonathan: Lynn, thanks again for coming on. I learned a bit, I hope that the listeners enjoyed it.

Lynn: I appreciate it. Thank you so much.

[music]

[00:39:59] [END OF AUDIO]