About this podcast episode

External technology firms can complement your internal expertise and result in a lasting partnership. In today’s podcast, Mark Balbes, Ph.D., shares how World Wide Technology builds mutual trust with its customers to deliver positive outcomes.

Transcript

(transcripts are auto-generated, so please excuse the brevity)

About today’s podcast

Bill Raymond: Hi, this is bill Raymond. I used to lead the software development team in an IT department at a global manufacturing company. This company was well known for providing high quality products to other companies with very high standards.

Bill Raymond: Our previous CFO retired and the new one came on board. This new CFO started asking for things you would probably expect such as master procurement plans, plant efficiency reports, and much more. Unfortunately, the results were frankly a bit of a mess.

Bill Raymond: Each manufacturing plant had a General Manager managing nearly everything, including their own procurement systems, IT staff, and had their own financial teams.

Bill Raymond: When the CFO asked me and my colleagues to visit the corporate office, he had a very straightforward question, which was why the heck – well, he didn’t say heck, so feel free to select from your library of expletives and choice, colorful words, and you will understand the tension in the room – but the message was this: why the heck don’t we as a publicly traded company that has to report financials to the street, have to rely on 300 people with paper, pencils, and adding machines to get the numbers that should be updated daily in front of the CFO on his computer screen?

Bill Raymond: Of course you could go in with a bunch of “that’s how we always did it” excuses, or you could bring solutions. We proposed some groundbreaking stuff and I think at this point, you’ll probably notice that I’m being a little sarcastic, but we proposed a centralized corporate IT division that would standardize our email and network infrastructure, and most importantly, build a centralized financial system.

Bill Raymond: The CFO agreed to this and working with the CEO and his colleagues formalized that corporate CIO role. However, he did not want to wait for us to get started. We immediately began hiring third-party vendors to help us bridge technology gaps while we worked on the more challenging part of implementing a full scale global financial system.

Bill Raymond: Unfortunately, some of those contractors were better than others and of course, some did a great job. But there were others that had important roles where they could not get the software written in a timely manner, they did not understand the scope, and we generally had poor communications with them.

Bill Raymond: As part of that learning, we let a number of companies go. We sat back and created a model for how we would work with outside software development firms. Instead of looking for the fastest people to turn the work around, we looked for more experience. Instead of hiring the most well-known firms, we found the ones that would offer our teams the best cultural fit. With these and other criteria in place, we found some great companies and fairly quickly I noticed we stopped calling them contractors and started calling them business partners.

Bill Raymond: Later I worked with one of those partners and I had the unique opportunity to learn what it was like on the other side. I quickly learned that it is not necessarily the surface you provide, but how you build and maintain trust with your customer. I also learned that as a service provider you often have standards and practices for how you work.

Bill Raymond: However, the customer may have a vastly different way of doing things. We see this in software today where software developers adopt agile practices and methods to deliver their software. But maybe the customer does not. Even small things like terminology and communication styles can be vastly different.

Bill Raymond: Many of you as regular Agile in Action podcast listeners tell me that working with outside service providers can be, shall we say, trickier than you might’ve thought. That is why I asked Dr. Mark Balbes to be a guest on today’s podcast. We’ll get into Mark’s role in just a moment but what I hope you get out of today’s podcast are some practical ways to bridge the gap and build highly effective teams when working with third party service providers.

Bill Raymond: Of course, if you are a service provider, Mark provides invaluable insight into how you can build the best possible relationship with your customers.

Bill Raymond: So with that, let’s get started!

Introductions

Bill Raymond: Hi and welcome to the podcast. Today I’m joined by Mark Balbes senior director of modern software enablement in application services at Worldwide Technology.

Bill Raymond: Hi Mark, how are you today?

Mark Balbes: I’m great. Thanks for asking how are you?

Bill Raymond: I’m doing great. Thank you. We’re going to be talking about quality agile delivery with external stakeholders, but before we get into all of that could you introduce yourself?

Mark Balbes: Yeah. You already stole my name and my title and everything. Balbes Senior Director at Worldwide Technology. So my background, I am a high school dropout. I’m a PhD nuclear physicist. I am a trained salt miner, software developer for many years, and uh, now I have the joy of leading multiple teams at Worldwide Technology across different services related to software development including our agile transformation practice and our software modernization practice.

Bill Raymond: Wonderful. Let’s get into that a little bit. Could you explain what Worldwide Technology is for anyone that doesn’t know them?

Mark Balbes: Yeah we’re a unknown gem for folks that don’t know us. Started out really in the computer networking equipment resell business, where the largest Cisco reseller. So if you’re in, in the business, people know about us, we’re also solution providers. So we have different capabilities around helping folks with digital transformation, with agile transformation, which is part of what I’m doing uh, software development.

Mark Balbes: So all services related to the IT industry. We can, we can help you buy the hardware, install the hardware, configure it, write the software for it, help you find people. So really a lot of different services. It’s really fun to be here, because there’s so much going on.

Bill Raymond: Yeah, I absolutely love working with a company that has a diverse set of clients and different types of work that you can do. There’s nothing better than being able to just wake up and see what’s new the next day.

Mark Balbes: It’s fantastic because you’re right. It’s a lot of it is what toys do I get to play with today?

Challenges of working with exterrnal business partners

Bill Raymond: And from that perspective, we’re gonna be talking a little bit about quality agile delivery, but we’re gonna do this in a little bit of a different way. Normally, when we talk about this, we’re talking about how you do it within your organization. And you’re going to talk about that, but there’s another layer of this that I think, as a company that does consulting business and having worked with many in the past.

Bill Raymond: One of the challenges that we’ve always had with agile is we create these great i nternal processes, but then we have these clients, these pesky clients that have their own yeah, that have their own way of doing things and it might still be agile, but it may not be the way we defined it either. So it’s gonna be interesting to talk to you about the differences between the two. But before we get into the external part, let’s talk about the internal part. You said you’re part of an agile transformation effort and you have mentioned that you’ve adopted agile. Can you talk a little bit about that journey and what you have adopted so far the types of things that you’ve done within your own organization at Worldwide Technology?

Mark Balbes: Yeah, absolutely. I’ve been with the organization for about 15 years. So I’ve gotten to see a lot of change going on and that’s one of the interesting things is to look back at how we developed software 15 years ago on the cutting edge of agile. Where we are today and what’s changed and what’s still the same, which is just as important.

Mark Balbes: So like you said, we’re a large part of our business is building applications either for our customers or with our customers. We have our own internal teams that we run in a extremely agile fashion. And I can describe that. But then we also have models of engagement with our customers where we’re co-developing with them, or we’re helping to enable them to develop so helping to teach them better practices around software development, like being more agile or moving to the cloud or any of number of things that we can do to help them.

Mark Balbes: So with, within our own teams we really have embraced strongly the agile manifesto and the principles and originally for probably the first 10 years or so. That was really our guiding light was the agile manifesto that we would go back to. And what we realized was in working for so long with our different customers, different kinds of customers. And I know we’ll get into to the wide variety that we have just within application services. We wanted our own delivery principles, cribbing a lot from the agile manifesto, but focused on what we do. So the manifesto is really meant, it’s very general for software development. You could be applied to a product company, a services company anyone developing software, including us.

Mark Balbes: And we develop software for other people. We don’t have our own products for the most part, we have a couple. But most of what we do is building stuff for our customers. That’s a very specific kind of way of working and we wanted to be more tailored to that. And so we came up with our delivery principles and we have 10 of them. I can rattle them off if you’d like me to and say what they are.

Worldwide Technology’s Agile principles

Bill Raymond: Yeah. Could you share what the principles are that you’ve developed internally?

Mark Balbes: Absolutely.

Mark Balbes: The first one is customer value that our highest priority is to provide value to the customer in alignment with their expectations. So that alignment piece is different from the agile manifesto. It’s not about what we want. It’s about what our customer wants and making sure we’re working together toward that.

Mark Balbes: Embrace change. We embrace changing requirements even late in delivery. So that’s pretty much the same.

Mark Balbes: Deploy often release working software as frequently as the client can tolerate. So that’s different, right? It’s not released as frequently as possible. It’s as frequently as the client can tolerate, we have a customer, the Department of Defense and we build for them what we call the Mobile Field Kit.

Mark Balbes: And you can go out and find videos on the MFK. Every time we do a release of the Mobile Field Kit, it costs them millions and millions of dollars because it’s not just accepting the release. They have to go out and train all of their people on it, which means doing actual exercises with it, going out into the field, deploying and making sure they understand how the new features impact their mission.

Mark Balbes: Testing first of all, does it work the way it’s supposed to, but more importantly, does it improve their operational capability? And releasing more than twice a year, big official releases is really expensive for them. So we release often internally, but they can’t tolerate big releases frequently. So that’s a difference, right? How frequently they can tolerate it, not how frequently can we do it?

Bill Raymond: Yeah. And that’s an interesting one because I’m thinking about an agile team, especially in software development, you’ll see it normally be somewhere between one and three weeks where something gets released and it’s, and we call those sprints usually or iterations. And what you’re saying is you might still work in that fashion, but the customer may not see the, all the effort around that work for some period of time.

Mark Balbes: That’s right. We will still release internally. We still do regular demos every week or every couple of weeks with our customer so they can see our progress. We do everything as frequently as possible up to the point of release at least with the Mobile Field Kit. And of course it depends on the customers and how we’re interacting with them, how far we can go before we have to match their schedule instead of our schedule.

Bill Raymond: Sorry, I interrupted you there. You were on number three, which is deploy as often as a client can tolerate.

Mark Balbes: Yep. Work together. So customers and the delivery team must work together regularly throughout the project delivery.

Mark Balbes: Next one is communicate effectively. So we intentionally choose the most effective ways to communicate with our teams and stakeholders. Different customers respond to communication in different ways, more than just do we email you or do we, text you or something like that, but there’s different formats for how we do status reporting. One of my projects that I’m working with the team now. We pretty much revamped how we do our status meeting with our customer to more closely align to what they want out of that status report versus our standard out of the box status report that we do.

Mark Balbes: Ours is pretty cool. We had our UX team go through it and we did all kinds of usability studies to make sure that, our standard report status reporting was as good as possible and our customers could understand it. You do all that work and you show it to the customer and they’re gonna tell you they want something different and it’s not for us to say, but we did all this work! It’s yeah, okay let’s figure out what’s effective for you.

Mark Balbes: Sustainable pace. So the delivery team’s processes should enable them to maintain a sustainable pace throughout the project delivery cycle .

Mark Balbes: Design or sustainment continuous attention to good design maintainability and sustainment enhances agility and aids, ongoing support.

Mark Balbes: So sustainment is, I think with my experience with agile, it’s one of those things that you have to be really careful about. That you’re thinking about it. We’ve had challenges in the past before we started really paying attention to it that, agile teams can work fast and they can get stuff out the door and it’s really cool. But did anyone think about how do you maintain the system? How do you sustain it going forward for us, how is our customer going to take over that running application and actually keep it running and add to it and keep it a living thing. So we pay very close attention to that.

Mark Balbes: Simplicity. Simplicity, the art of maximizing the amount of work not done is essential. I think that’s word for word from the agile manifesto. It’s so important.

Mark Balbes: Measure and improve continuous measurement and improvement is vital at the individual and team levels. We do a lot with our people around their own professional development and helping them qualitatively and quantitatively know where they’re at with their capabilities, with their careers. We spend a lot of time doing that.

Mark Balbes: So agile tends to be about the team. How fast is the team going? How productive are they? How can we go faster? We do all of that too. That is essential, right? When you’re on a project, you are optimizing the team, not the individual, but there’s still the need from a company perspective to know how your individuals are performing. So we try to not have that be anecdotal. We like it to be a little bit more concrete that gives that person more feedback for them about where they can improve or where they’re doing well. That’s just as important and, lean into the things they’re doing well and get even better and help with the things where they need.

Mark Balbes: And then healthy teamwork, the best outcomes are produced through healthy teamwork. We absolutely believe in that. It is very rare that we have a single person working on something that is, a larger kind of engagement. We’ll always try to get at least a pair of people on it, if not a full team. So those are them.

Bill Raymond: Thank you very much. And that last one was so important. I used to run a software development team at another consulting firm. One of the things that I was always trying to do was just have sort of a developer on a project because we kind of got stretched a little thin usually, and one of the biggest challenges that we had with that, which is interesting was that the team member that was doing the work, were always struggling to find someone that can do the, that can QA the work. And they’re trying to find people they can bounce ideas off of, but there’s, they’re not there on the project. And I was worried about increasing the team to have this sort of multiple people on a client team, because that means more money to the customer.

Bill Raymond: But what I saw was the quality went up very significantly when we staffed a little bit more for the team and sometimes the customer would come back and say Bill, how come your estimate is much higher than these other estimates? And I’ve found that actually not only was it a selling point, but it was a fact that they were going to get a higher quality product when we have that healthy teamwork those teams that can work together just because someone else is paying for the work the people on the other ends that have to do the work, they need to be part of something where they can work with other people and feel comfortable that they’re doing their best.

Mark Balbes: That’s absolutely true. The other thing you have to think about is the total cost of ownership, that when you have that lower quality product, you are gonna be fixing bugs. You are gonna have a harder time maintaining it over time. And so I I’m maybe a little bit nasty when customers ask can we not do pair programming?

Mark Balbes: Can we not do a utomated testing and my response to things like that is, is, yeah we can add some time to not do those things because that’s what happens when you pair program the, they go faster, the quality goes up, which means you get more features in the same amount of time. My observations from doing this for 20 plus years is that you get more when you do the pair programming for your money and especially true when you look at the total cost of ownership.

Mark Balbes: So one, one thing you don’t see with these delivery principles, we don’t have any thou shall do pair programming, thou shall do continuous integration, thou shall, anything. We have our own beliefs in what makes our team successful, but they have a lot of autonomy in how they choose to work. So there are some things that we insist on because we just need them to manage the, our projects effectively and interact with our customer. So I talked about, status reporting, which is a boring thing, but you gotta do it. But our teams get to choose how they work.

Mark Balbes: And if they want to do KanBan process, if they want to do a, a SCRUM process for our internal teams where we’re managing them, that’s really up to them. But for the most part, you are going to see the hardcore pair programming test-driven development, continuous integration, continuous deployment if that’s possible we, will have CI/CD servers up and running. We have all the different kinds of tools to do the collaboration either physically or like a KanBan process.

Mobile Field Kit for the Department of Defense

Mark Balbes: One of the things I talked about Mobile Field Kit, I ran that for almost five years. That’s my kind of my baby. We had 24 linear feet of Kanban on three, eight- foot wide corkboards. Our entire process was mapped out on that. And we had other teams that are using, Trello or JIRA or something like that with big large screen monitors.

Company culture

Mark Balbes: The other thing we believe strongly in is co-location and what we’ve learned is that can be physical or virtual. So especially with COVID we already had what we called our virtual office. And so we didn’t talk about remote people. We talked about people in our virtual office and we treated our virtual office the same as our physical office there’s office managers, there’s policies around the virtual office, there are benefits to being in the virtual office that you wouldn’t necessarily get if you’re in a physical office. So for example, if you’re in a physical office, you would expect to have a desk. Somebody in our virtual office they have, they get a desk, things like that. And so when COVID hit, because we already had this virtual office concept set up and we had teams working effectively in it, we moved, we had a hundred people in the virtual office before COVID and we moved over 500 people into the virtual office in a weekend, and never missed a beat because we all knew how to work together. We already had those virtual tools that everybody was familiar with and yeah, and we just kept going. It was really pretty amazing. How well our agile capabilities helped us with dealing with COVID.

Bill Raymond: If anything comes out of this I’m happy to that we have a success story about COVID. Because those are those, there are, those are some tough times that it sounds like that was handled pretty well. I appreciate that you had already thought through all of that.

Bill Raymond: And I’m sure this is all part of some of your agile transformation work that you’ve been doing as well.

Mark Balbes: Yeah, our customers are dealing with the same thing. And so a lot of our experience up-front, we were able to help our customers do those same things and show them what we’re doing. But back to the topic at hand. We can’t assume that what works for us is gonna work for our customers. And so we can help, but we also have to adapt to their requirements.

Understanding your customer’s culture

Bill Raymond: When you talk about adapting to the customer and their environments, what are some of the challenges you see across industry? And I think you told me prior to this call that there’s a pretty wide variety of work that you do as well.

Mark Balbes: Yes. So I already talked about the Mobile Field Kit, which is one of the things we do for the Department of Defense. We have others. We build products for the quick service restaurant industry, fast food places. A lot of the pizza, mobile apps, if you’re using them, came from us and other companies like that that had to adapt very quickly to pick up delivery services, things like that.

Mark Balbes: When you’re dealing with the military, It is very different from dealing with quick service restaurants commercial customers. We do a lot with the banking industry where it’s heavily regulated and they tend to move slower. They can’t absorb changes fast.

Mark Balbes: There are You know, parts of those customers, they have divisions that are responsible for making sure that they’re maintaining their compliance. So they’re very resistant to any change and you have to be able to I won’t say overcome that resistance, but adapt to the resistance maybe is a better term.

Mark Balbes: You have to show them that they can still meet their requirements to make sure that the, the bank is meeting all of its obligations, because if they don’t, there could be huge financial penalties to those banks. And they’re also dealing with as they grow and these, the banks have consolidated over the last 20 years or so. They have different systems that work in different ways that have all been integrated together. So a lot of it is held together with these different integrations that you have to really understand the details of to know what’s going on and making changes to them is fraught with fear that you’re gonna think you’re making something better and you’re going to lose something in, a business rule or something in the process.

Mark Balbes: So banks can be really challenging to help them become more agile or even just in general, working with them on their software. It’s fun. It’s important. But it’s a different challenge from helping a a fast food chain, get their latest mobile app out and delight their customers. So those are some of the industries.

Bill Raymond: You’re stating very clearly that your objective is to do what the customer wants.

Bill Raymond: But there are things, as you said, you have some basic principles and standards that you use internally. So what happens when that gets shaken up? How do you address that?

Mark Balbes: Carefully. So there’s different ways of addressing it. One of the most important things when we’re working with a new customer is establishing trust. The faster, the more we can establish trust with the customer, the more we can do with them.

Mark Balbes: Occasionally we get a customer who’s we just met you. Great. Here’s a boatload of money. Let’s start up, a big team or five teams and let’s go! I wish they were all that way. But they’re not. And so typically when we’re working with customers initially the best thing we find is to start with some kind of a small engagement. Even though we could do something big and flashy and, fantastic for them.

Mark Balbes: Doing that successfully, without first doing something small means you’re risking that you don’t understand the culture, that you’re gonna have a mismatch, more opportunity for clashing with a part of their company that maybe we don’t even know exists until we hit that clash. And so finding something that that they’re excited about, but that’s small either building a capability for them or helping them to to build something for themselves and improve. And so a common engagement for us, initial engagement is what we call a subject matter expert engagement. Let’s take one of our, you know, senior people uh, with a lot of experience in the area that, that, that customer, you know, is in the domain they’re in banking, your fast food or whatever, and just have them go in and spend time with the customer, learning their environment, helping them understand where they can be better. What’s really important is helping them get some quick wins. It’s not about going in and assessing the customer and giving them a report card and telling ‘em, here’s all the things you’re doing wrong.

Mark Balbes: Because that, that doesn’t go over well. It’s about going in and saying, hey if we make this tweak to what you’re doing, you know, we’re gonna get some improvement. Let me do that for you. Let’s do that together and get that improvement. And that’s how a lot of our big work started was just do something small. But that’s, impactful.

Bill Raymond: Yeah, that’s interesting. I think, when we take a look at a lot of the agile frameworks out there. Almost all of them mentioned something along the lines of an MVP or an early win or, something that shows the value in what you’re doing. And that’s, it sounds like you’ve really embraced that idea.

Mark Balbes: It’s understanding what the customer wants too because some customers are, yes, please come in and help us get better. That’s what we want. And other customers don’t want that at all. They’re like, we, we think we have good processes. We know how we work. We need help with this technical problem, help us solve this technical thing or this business thing. And then we know to stay away from any kind of, process improvement or agile kind of talk with them, if that’s not what they’re already doing.

Bill Raymond: Have you encountered situations where the environment on the customer side is vastly different?

Bill Raymond: Maybe they’re using what we like to term, a waterfall method. Where everything gets planned up front. And there’s a schedule that we call a Gantt chart that shows every last task. Have you encountered those situations in these software development efforts?

Mark Balbes: Absolutely. A lot of times, it depends on the industry. So we’ve talked about the banking industry. They tend to be more conservative. They tend to be less agile in how they work. They want to know upfront how things are gonna work and whatnot. So the important thing is to recognize that agile i s not a methodology, right? It’s not SCRUM, it’s not Extreme Programming, it’s not SAFe. Agile is about the principles and the manifesto, so when you’re dealing with a customer who says, look, I’ve gotta have a high level design before you start working. Then, you know what? That is a requirement that is coming from the customer and you deal with that the way that you would deal with it in an agile process, there’s a requirement.

Mark Balbes: We’ll put the card on the board for the requirement and we’ll do that requirement. Now we’re going to recognize that doing some kind of high level design there’s a point of diminishing returns just from our experience, not just as being Agileists, but just expert software developers with all of our experience.

Mark Balbes: And so we will try to do the minimum necessary to satisfy the customer requirement. Obviously trying to make it as right, as possible, but then we’ll also want to prove out the design by doing some work. And so that’s where we can coach the customer about somebody like that is who’s asking for those designs.

Mark Balbes: What they’re trying to do is mitigate risk. It’s I wanna know that you guys know what you’re doing so that when you start building it, we’ve already thought through all the problems and we figured out what they are and how we’re gonna solve ‘em and we know that’s not true. You’re never gonna be able to do that.

Mark Balbes: Talking to the customer in their own language, talking to them about risk. We’ve got this high level design, let’s start working on an MVP or a prototype, whatever words resonate with them and prove out that design before we get too far. Guess what? Now you’re on the agile path of delivering something early and you give them that flavor for it and you can hopefully keep going in that direction.

Different working styles

Bill Raymond: When we talk about agile, is that teams. Should be as close to the customer as possible. Now, in this case, of course, the customers come to you and they’ve said we want to do this work. So that’s great. You’re gonna have that, that communication there, but the actual customer, the person or people using it, they might be somewhat separated from the team that you’re working on. How do you address that situation or do you make it a requirement that you are able to talk to these customers? What’s what are some of the methods that you use to make sure that you aren’t just following the words a, let’s say a, a small group assigned to work with you are saying versus the people that will use the product at the end?

Mark Balbes: Yeah. So first of all, I was on a project once that was building a medical application for a physician’s office. And the development team sat in a physician’s office. They gave us a conference room and that’s where we were doing the work. When. To talk about close that’s pretty close.

Mark Balbes: It’s a tough problem and so for us, ourselves, we have a product ownership team, we Have a user experience team that we can leverage for our engagement. So we are all in on wanting to be as close to the customer as possible, the user of the system to really understand how they’re thinking about it, how they want to use it and give a better experience than initially might have been thought possible. There are times when the client will say, we already know what we need for our customers, we don’t need to go to them. And that can be a problem because they’re stopping us from talking directly with the users of the apps. We’re giving demos to people who themselves aren’t getting the feedback that we would want from the right people. It’s a tough challenge because we have to maintain the relationship with our clients and they are, I’m not gonna say that they’re always right. But we have to make sure that they don’t feel like we’re going around them or undermining them or anything like that.

Mark Balbes: So we will try to work with them, suggesting, hey, how about if we go into the field and test this with real users or some mechanism to get that feedback, because invariably, when you do that, you find out that those people who think they know and are representing the customer don’t really know. And I’ve learned that from experience enough times.

Mark Balbes: So Mobile Field Kit coming back to that, my baby. One of my roles was basically acting as product owner on it, coming up with the features, driving the team to, build those features. And we were lucky that we got to go into the field, and actually train them on the system and see them using it in exercises. And it was amazing how many times little features that we threw in became like the star of the show and to us it was like, oh, this is just some small thing, we’re putting it in. And it becomes like, oh, this is the breakout thing that they want more of and more of. And if we had been left to our own devices, we would’ve thrown it in and never thought about it again, instead of it becoming now a big feature that we started building on. But once the users interact with the system it changes how they think about their role. So you can’t just take a snapshot in time and say, I know what my users want, because once you start giving them new tools, they start thinking about new ways of doing their job and wanting different features around that.

Bill Raymond: That’s a great story. It’s amazing. The little things that you find out that are so important like for example, I think accessibility is another one. Sometimes people have a hard time seeing the size of the font, but the people on the team, they didn’t have any problem with that. I know that’s becoming more and more of a problem for me.

Mark Balbes: With mobile devices you develop in the office, everything looks great. You walk outside, the sun is, shining down on the screen and you can’t see anything because it’s not a high contrast screen. And if you don’t ever walk outside and actually look at, where are your users actually using the application and see it in that environment, there’s things that you don’t realize you do an app for a, a manufacturing company and everything is great.

Mark Balbes: And then you go and you see it in the field and you realize that everybody’s got noise cancellation on their, headphones on their head and because it’s, so everything is so loud. And so all these great dings and beeps that you built into the system to let them know what’s going on. Nobody can hear those things.

Bill Raymond: Do you run into situations where you have the teams on your side developing the product. And then you also have another agile team on the other side that are also doing work on the same effort?

Mark Balbes: We have different models of engagement. The one that we’ve been talking about really are our internal teams, right? That’s the kind of perfect thing. We have our own processes, our own people. We can control a lot of things to be as effective as possible for our customers.

Mark Balbes: But there are other models of engagement where it may be that, we’re building a mobile app for our customer, but the customer has their own backend team building the services that our mobile app is calling into. In which case you’re coordinating with that team. So that’s one model. There’s a a model where we’re actually co-developing with the customer.

Mark Balbes: So it’s not just our people on the team. It’s our people with the customer’s people. And that can take different flavors because if the customer is interested in learning, having their people learn from us. We’ll actually be able to more closely follow our processes and have their people learn our processes so they can bring them back.

Mark Balbes: But sometimes it’s the other way. Sometimes the customer is basically we have our processes. There’s reasons that we do it this way because of our industry. It’s regulated it, whatever. In which case we have to adapt to how they are working, and that takes flexibility on our people’s part, because at that point they’re going from a very comfortable situation where they have a lot of autonomy and control to one where they’re working more, maybe more traditionally than we like to work, but that’s what’s needed.

Mark Balbes: The desire is that you use that to build trust with the customer, and they start to understand how we work and how we think about things and they trust us so that we can move them closer to a more agile model. Now, sometimes we work with a customer, we learn from them, right? The best thing is, situations like that, you go into with an open mind because, golly gee wouldn’t it be great to go in and discover they’re doing things that we didn’t know about. And that happens too.

Bill Raymond: Those are great moments. I will say there’s so many times when you’re in a situation where, you have some process that you thought was ideal and then the customer comes back and says, oh no look, this is an easier, better way. And you say, yeah, it is!

Mark Balbes: Yeah, we know our processes are as ideal as we’ve learned to make them for us. We are adapted to our kind of work when we do our internal stuff and we’ve learned that we have to be adaptable to our customers and their situation.

Bill Raymond: Yeah. And also, with that experience, that’s why people like to bring you on board I’m sure because they know that you have this wealth of background in different areas. So you bring some best practices that they might be interested in and then they’re gonna bring you some best practices that not only can you use with them, but you can start sharing those as long as they’re not under NDA, it start sharing those with other customers and they get value out of it.

Mark Balbes: Oh, absolutely. I can point to certain things that we do and it’s this is from that customer. And this is from that customer. It’s yeah, those are awesome. When that happens.

Wrap up

Bill Raymond: Yeah, I love those little moments, Mark Balbes, this is a great conversation. I really appreciate your time today. If anyone wants to reach out to you, how might they do that?

Mark Balbes: Oh, that can reach me at uh, LinkedIn. I’m the only Mark Balbes in the world. So it’ll be me.

Mark Balbes: I write a, a column. I say it’s monthly. But there’s some gaps for application development trends magazine called the agile architect.

Bill Raymond: Great. Yeah. And that’s how we found you. And they’re great articles. I really suggest that you go and check those out as well. Of course, your LinkedIn profile and the agile architect link will be in the agileinaction.com website. And of course, if you’re using a podcast app right now, listening to this podcast, just scroll down to the show notes to the description and you’ll see the links there as well.

Bill Raymond: Mark Balbes, once again, thank you very much for your time today.

Mark Balbes: Oh, you’re welcome. This has been fun.