Can you really gain competitive advantage with Dynamics 365? with Martin Hinshelwood

Neil Benson [00:00:02]: Good day, and welcome to Amazing Apps. I'm your host, Neil Benson. Thanks for joining me. You know, every now and again, someone asks you a question that challenges one of your long-held beliefs. I used to believe it was possible to write a perfect requirement specification, and that was the secret to a successful software project. Then I was introduced to Scrum and realized my long-held belief was a fallacy. There's no such thing as a perfect requirement specification. And you can have a successful software project without any requirement specification at all. Today's guest on Amazing Apps challenges another of my long-held beliefs. You should never build your own business application. There are hundreds of apps to choose from in every category. The popular ones that we know, marketing, sales, service, HR, supply chain, commerce, finance, operations, project management, you name it. You'd be mad to suffer the cost and the maintenance nightmare of building your own business applications. Martin Hinshelwood from Naked Agility challenges my belief. He reckons, there are times when you can gain more competitive advantage by building your own business app than you can by buying one. It's not as if he doesn't know what he's talking about either. Martin was a developer for 13 years and has been training and coaching software development teams for the past 10 years. He's a professional Scrum trainer and a professional Kanban trainer. Martin also has been a Microsoft MVP in developer technologies for the past 15 years, specializing in GitHub and Azure DevOps. Fair to say then, he's got some credibility when it comes to custom dev on the Microsoft platform. Join me as he brings his insight into our world of Microsoft business applications. This is Amazing Apps 146. You'll find show notes, a transcript, and resources at amazingapps.show/146. Here's Martin. Martin Hinshelwood. Oh, man. Good to have you on Amazing Applications. Welcome to the show. 

Martin Hinshelwood [00:02:20]: It is great to be here.

Neil Benson [00:02:21]: Martin, I think you have a somewhat controversial idea. I'd love to dive into it. Most Microsoft customers would be better building their own business applications rather than buying something that's prepackaged like Dynamics 365, ERP or customer engagement apps. Tell us more. I'd love to dive into your point of view.

Martin Hinshelwood [00:02:41]: Well, I'm also gonna caveat that point of view and say, well, it depends. Right? And definitely, there's some depends in there. It's not always the wrong thing to do. But I have this fundamental idea, and the reason organizations were successful in the first place, the reason yours was the startup that was successful when others failed, and even that applies to organizations that have been around for a 100 years, they were at some point a startup. Right? The reason that they're successful is because they do something unique that no other company does. They're filling a niche in the market. They're filling it in a way that enables them to respond to that market better and therefore be more likely to be successful in other organizations. And the idea that you should suborn that to somebody else's business practices, that you're potentially risking your unique niche and your unique capability in that market because you're saying our business is procurement. Right? So we're going to buy Dynamics 365. And we're gonna use Dynamics to—I can't remember. There's a whole bunch of packages that Dynamics 365 has for different markets. Right? So let's say it's the trucking industry. Right? I'm sure they have a here's the package for you're a trucking company. Right? And you've gotta get packages into trucks and across the world. If every company buys it, what's the difference between these companies? What's the uniqueness that enables this company to be more successful than this company? Well, it's gone because you're all doing it exactly the same way. So then somebody else will come into the market, do it in a unique way, and take that business away and then eventually they'll get big enough to buy dynamics and then they're the same as everybody else. And then a new company will come in to take that market away because they do something unique, and then they'll buy Dynamics and they’re the same as everybody else. Right?

Neil Benson [00:04:35]:  So that's interesting. In Australia, here, there's a couple of big heavy equipment manufacturers, Komatsu, Hitachi, Caterpillar, you know, they make big bulldozers and excavators and those kinds of things. There's a lot of mining in Australia. There's lots of mining equipment. And there's an ANATA, which is a heavy equipment ISV, sits on top of Dynamics 365, really popular in Australia. All those manufacturers compete against each other and if they all use the same software, how can they stand out? How can they compete against each other with the same fundamental software? Interesting.

Martin Hinshelwood [00:05:05]: Don't think about it as software. Right? The software implements your business practices. That's what software is for. It enables and automates your business practices. So if you buy it, you're buying the business practices along with the software. 

Neil Benson [00:05:19]: True. Yep. 

Martin Hinshelwood [00:05:20]: That's the bit that loses your uniqueness. And I used to work with a company in Utah called Backcountry. They're a great, great company to work with. And when I worked with them, they're clothing company. They do sportswear. Your ski helmets and your goggles and your, I don't know what's other sports, but it was mainly ski focused. Where they were in Utah was right next to where the Olympics were held down there in—

Neil Benson [00:05:43]: Salt Lake City. 

Martin Hinshelwood [00:05:44]: Yes. But there's a place of a town up in the mountains, which is where the actual like, they have the ski ramp and stuff. Yeah. Yeah. Yeah. But they are a company of at the time, I think it was about between 96 98 people in the whole company, that’s CEO all the way down procurement worldwide, and 48 of them were software engineers.

Neil Benson [00:06:04]: So how how far do you take it?

Martin Hinshelwood [00:06:05]: 48 of them were Java Developers, but they built and supported their entire procurement pipeline. So they have software that helps them interact with the warehouses in China that enables them to book and pull in the goods. They have the software that manages all of their warehouses in the US. They have an iPad app that sits on the forklift, right. The guy driving around in the forklift trying to find the stuff in the warehouse. Where do I put it? What, how do I move stuff around? How do I find stuff? And they run all of their points of sale. They have multiple web-based properties. Right? I think that's the way they describe them. Right? They had multiple websites that look like different brands to you and I, but they're all part of their thing. And they, each of these actual different websites had a different unique proposition, the way they sold, the way the people buy that was something unique. So they kind of even competed against themselves. So they've got from consumer all the way through to manufacturer, is their systems. It's their own systems that they support and maintain. And anytime somebody says we'd like this to work differently, no problem. We'll do it. Right? Because it's we own the whole full stack. We're not relying on a third-party software vendor. We're not relying on the way Dynamics inherently works and we're stuck, we can rearchitect whatever it is we want in order to be able to successfully take advantage of that market opportunity.

Neil Benson [00:07:38]: So I can imagine companies who compete on supply chain excellence, right, the speed to market. They can go from manufacturer to product in store in weeks, you know, many times faster than their competition. It might be worthwhile investing in custom software to enable that competitive advantage. But, you know, I'm a small business owner. I'm not gonna hire a developer and build an accounting system. There's dozens of off-the-shelf accounting systems. I'm gonna buy it. I don't compete based on the quality of my accounting. So I don't care as long as it meets my minimum needs.

Martin Hinshelwood [00:08:11]: That was my caveat. said it would happen, right? If it's not your core business, don't build it, buy it. I don't build a document storage system. I have SharePoint, right? I don't buy a file-sharing system. I have OneDrive. I don't build any of those things because they're not part of my core business. But I do go build a bunch of stuff around Agile and student management, right? I have my own, I've looked at getting somebody else's course student management system. 

Neil Benson [00:08:47]: Well, there's only a couple of hundred LMSs out there to choose from. 

Martin Hinshelwood [00:08:50]: Oh, it's not really LMS. Learning management is something different to a training management. Right? So this is what courses do you have for the published people being able to find them and purchase the course, and I built my own system because that's part of my core business. And whenever I've gone, oh, this is so frustrating. It's so much effort. It's so hard to go do this. And I've gone and looked at third party systems out there, like, I don't know, the Arlo is probably the big one. 

Neil Benson [00:09:19]: That’s the one that springs to mind. Yeah. 

Martin Hinshelwood [00:08:50]: Yep, yep, industry. I've had a number of conversations with them about how can I use their system, and every single time, I run into the point very quickly where I need to change my business, my core business practices in order to be able to support it. So for example, I offer different prices worldwide depending on where you are in the world. Out of the box in my system, it detects, geo detects you, where you are. So if you're in Australia, I think Australia's full price, but if you're in Spain, right? There's a 25% discount because Spain's a nonprimary market. If you're in Africa, it's a 50% discount on any of my classes. Right? And that capability is not in any of the platforms that are out there. So I would have to remove that thing, that unique selling, that unique business proposition for my customers in order to then use that standard system. Arlo, when I spoke to Arlo, they did say there are ways you can do it, but it would require so much you'd have to create a different course for each country.

Neil Benson [00:10:29]: Yes. I've seen that done before.

Martin Hinshelwood [00:10:30]: I have one course that I published, and it's everything else is automatic. So from an admin standpoint, this is a much better way to do it. Right? 

Neil Benson [00:10:38]: Okay. So I can see what you're saying. So there are some companies in some industries where Dynamics 365 makes sense because it's a prepackaged application. They can configure it. It's not where they compete. They just want a pretty good customer service system. They just want a pretty good sales application or pretty good financial management application. They compete somewhere else. 

Martin Hinshelwood [00:10:59]: You're not selling me on Dynamics there with it only being pretty good.

Neil Benson [00:11:02]: I think if you just in— I was gonna say install it. It doesn't come on CDs anymore. But if you just, you know, subscribe to the basic application, it's pretty good. You can and should configure it and customize it to your business. 

Martin Hinshelwood [00:11:15]: I've looked at it for CRM. And it has a training management, a training management plug-in as well? 

Neil Benson [00:11:21]: Yeah. There are people who built industry applications on top of it for managing schools and courses and students online Yep. There are. So I remember taking a tour of the SpaceX factory in Torrance, California when I lived just down the road in Manhattan Beach. Wonderful, amazing, amazing place. And I was in software there. I was running up a Microsoft practice for Slalom Consulting. And when I asked the tour guide, he was one of the managers at SpaceX, you know, do you use any Microsoft software? Do you use anybody else's software? He's like, nope. It's wall-to-wall custom. There just aren't any software vendors who make software for the rocketship industry. So we have a couple of off-the-shelf applications, but it's mostly custom.

Martin Hinshelwood [00:12:02]: It's actually even worse. I was reading not just SpaceX, but I was reading an article about Ford. And Ford was saying or somebody in leadership in Ford was saying that they're having an absolute nightmare right now because they outsourced every component in the cars, all of the digital systems in the cars. And they've got 130 different vendors. I'm making up that number. It was some, it was in the 100 and something. Right? 130 different vendors that all build different parts of the car and all have to interact with each other. And now they're trying to compete with the likes of Tesla, and they need connected, coherent strategy systems in order to be able to do that. And they're like, we don't have any capability to do this. We don't have any capability in-house. We're starting from 0 in figuring out how do we compete with that idea of the unique niche. They outsource some of their core business which is always a bad idea. And that applies not just at the technology level, but it also applies at the business level. When you bring in the McKinseys or the BSGs or even to a certain extent, the Accentures, right, of the world, they are bringing skills that you don't have but you tend to inherently rely on those skills. And as soon as you rely on them, you stop building them internally. And then you need those skills in order to even be able to function. And that's outsourcing your core business practices. Right? It's different levels. 

Neil Benson [00:13:42]: That's right. And hello to all of our listeners at Accenture. We love you more.

Martin Hinshelwood [00:13:46]: I do, I do lots of training for folks at Accenture. There's lots of great folks at Accenture. I'm meaning holistically. Accenture's actually been around a very long time. I think it was started in the 30s? 30s or 40s. 

Neil Benson [00:13:58]: It was the consulting of the old Anderson consulting business. 

Martin Hinshelwood [00:14:02]: Yeah. Yeah. Yeah. That's what it was. I'm reading a book at the moment. Is it called The Great Con or the Big Con? think it's called The Big Con, and it's about the consulting companies in McKinsey and BSG and how they've taken core business practices away from businesses and governments. Yeah. It's really interesting. 

Neil Benson [00:14:21]: Somewhere in the middle between building all of your own custom software to support your unique competitive advantage and bagging off-the-shelf industry solution, Microsoft's got an offering called Power Platform, Powerapps, Power BI, Power Automate, where you can compose your own business application, and it's designed to fit unique needs. I build building or I manage buildings, big commercial office blocks and stuff. And I need an application to manage all of the machinery that's in there. When it was serviced and who looks after it, how strong the cable is, is it green certified, how much CO2 it uses,  all of those kinds of things. I could build an app on Power Platform, hopefully with I don't have to have half of my company being software developers. But, you know, is there a movement there that you're seeing with not just the Microsoft Power Platform, but other low code, no code, kind of build your own or compose your own applications?

Martin Hinshelwood [00:15:12]: I think there is, but I think it has stalled. And the reason it stalled is because very quickly folks that go to try and create things in Power Platform realize that they still need these uber techie people to be able to figure it out. Right? It's not actually, you have to be a fairly smart business person, a fairly, there’s a reason that some people become MVPs and other people don't. Right? It's because you've got that interest in learning and conversing and steering, and you actually need to be that person if you're in the business world to be able to do something well with Power Apps. It's not as easy as it sounds. Right? I've tried some stuff and failed. Right? And I have a technical background. Perhaps that's a limitation. Right? Perhaps that's a limitation. I'm like, how would I do it this way, but it won't let me. But I think with the new stuff coming down the line from Copilot, I mentioned that before, from Copilot, that will enable the request from the businessperson to be more easily turned into something that they can use right away will enable a much bigger explosion of lots of these smaller apps. I guess the developer in me is a little bit horrified that we're returning to the access database world.

Neil Benson [00:16:36]: Yes. Yes. The Lotus Notes monstrosities.

Martin Hinshelwood [00:16:37]: You'll go into a business, and you'll have this half-ass implementation that they're running. I used to work for a little company called Merrill Lynch. And at Merrill Lynch—

Neil Benson [00:16:48]: Whatever happened to them? 

Martin Hinshelwood [00:16:50]: Yeah, what happened to them. Funnily enough, the department I was working in was a subprime mortgage department pre-2008. Right? So but the entire decision-making process for whether you get a mortgage or not, the calculator, the analysis tool was built in Excel. 

Neil Benson [00:17:05]: Okay. Okay. 

Martin Hinshelwood [00:17:07]: The whole business ran on this. Well, the decision-making for the business didn't run on that too. Right? All of the call center people would have that copy of Excel, and they would plug in the numbers, and then it would tell them whether they can give them a mortgage and what rates they can give them. And following off, the person that made it had left the company, and they had the passwords to open up the crack open the Excel. I was tasked with making an app for it. Right? And it was just, it was all, it was absolutely not code based. It was formula based. Right? The entire thing was formula based. No. I just, like, It's looked like regex expressions to me. There's inherent business risk in that. Right? But I think the reality is without risk, there's no reward. And businesses, especially when you're starting up, you need to take a bit of risk and build some stuff and perhaps Power Apps is the best way to get some stuff that just solves little bits and pieces of your problem. I actually prefer the Toyota model than you know, the Toyota model is that they don't build one massive production line. Right? Because then you're stuck with this whole process. They build little bits of automation. So you've got all these points with a human in the mix where you can make adaptations and changes and catch problems. That was the end on chain. 

Neil Benson [00:18:26]: Yep. And you can stop the assembly line if you need to. Yep. 

Martin Hinshelwood [00:18:29]: Yeah. And it meant that they were able to more easily adapt their processes because it wasn't one big monolithic process. And that goes to something you mentioned earlier. You were talking about upgrading a system, right? You've got a project that you've been working on where we've got this existing system in place, and we can't go live until we built the whole new thing.

Neil Benson [00:18:51]: Yes. That's quite common.

Martin Hinshelwood [00:18:53]: Yeah. Yeah. Yeah. It's really common. I would definitely suggest that's the wrong way to approach that problem. I call them the mythical rewrite. And I've seen too many of them fail quite often because they're a cost center. They're not a value center. Right? They're not actually producing value until they get that first version of the product.

Neil Benson [00:19:11]: Oh, yeah. For sure. It's a long time before you extract that first dollar of return on investment. And I've often tried to find a way to breaking it up. How can we get this thing into production quicker? Can we go with a smaller team or a division over here, or they're just that department? And get them onto the new app with half the features of the entire app. There's lots of ways that we've tried to do it. I'm getting better at it, but we're not there yet.

Martin Hinshelwood [00:19:34]: I usually say whatever your sprint length is or whatever your shorter cadence, if you're not doing scrum, whatever your iteration length is. I usually say to teams, a highly skilled technical team that can figure this out, right? And just say to them, if you've only got a month, If you've only got 14 days, what can we ship in 14 days that will help make this system better and focus on that. And just do that every 14 days. So it's actually at the end of the 1st 14 days, you wanna be in production. You absolutely wanna be in production. You wanna have something in because that's the bit that tells you that you're on the right track, right, that you could actually do something in this space. And it might be that the COBOL system has to call out to your little service, and then your little service calls back into COBOL. Right? And you're just taking this algorithm or formula or whatever it is out, yes, we were able to do that. How many more of those can we do before the system starts operating well?

Neil Benson [00:20:32]: Yeah. So if you're gonna replace, I don't know, customer service and a contact center, you might just start with a caller verification app. And all it does is go, Mister Hinshelwood, what's your date of birth, what's your address, verified. That's all it does, and then it goes off to the legacy system and does the rest of the business transaction. Or you wanna update your address or you wanna initiate an insurance claim, whatever it is you called in for, we can help you with that in the old system, but we verified you in the new system that the IT team built first 2 weeks ago.

Martin Hinshelwood [00:20:59]: So the biggest fallacy with the mythical rewrite is that you need all of the things that the old system does. 

Neil Benson [00:21:05]: Yep. That's the argument I hear every day. 

Martin Hinshelwood [00:21:07]: Yep. The customer comes to you and says, I need it to do everything that this does. It's like, really? Do you really need it to do everything that it does? Because you know that the industry average is that 65 percent of the features that you built in your application are not used by your customers or not used at all. So how about we don't build that 65%, and we only build the 35% that's actually used right now? And then you can spend that other 65% of the time on other more valuable stuff that solve new business problems. But, yes, really hard to have that conversation because I find that the biggest barrier to any engineering project, I'm gonna be quite—we're all Australian here, we can be a bit blunt, right? The biggest barrier to this building of new stuff, of updating the existing stuff that we've got so that we keep it current so that we maintain we don't end up like British Airways, right, where our system's down half the time because it's calling into the mainframe that nobody knows how it works anymore. is the incompetence of business. That's ultimately what it is. It's business folks that don't understand that their business runs on the software. And if they don't understand the software, that's the biggest risk to their business is their lack of understanding of what it is they're buying, what it is they're paying for, what it is they're asking for, and how they're asking for it. I don't know about you, but have you ever bought a TV? 

Neil Benson [00:22:32]: Not recently, but yes. I bought a TV.

Martin Hinshelwood [00:22:34]

When you buy a TV, do you just walk into a store and say, “sell me a TV,” and take whatever TV the person that sells you in the store, whatever one they get the best commission on, right? 

Neil Benson [00:22:46]: Very rarely. No. I do my homework. I do my research. I compare all the reviews.

Martin Hinshelwood [00:22:50]

Yeah. You go find out what are the different TV capabilities that are out there? What's the cost benefit ratio? Maybe you look up some expert advice on what good TVs look like today. Do I need this or do I need that? And then you go into the store and you find that. But that's not how most businesses buy their software or commission software. They're like, here's a bunch of stuff I need. Go make it happen. Don't ask me any questions. Right? These are core business decisions that you're outsourcing. Again, we're back to the core business. Right? You're taking this, you're putting it in the hands of somebody else who is not in your business who doesn't really care that much whether you're successful as long as you pay the bill at the end of the day. And that's, for me, is all business risk.

Neil Benson [00:23:33]: So I love this idea of getting the business folks more involved in building the software. giving them a tool like Power Apps or whatever it is to compose business applications that they have far more interest and a stake in. But business folks, regardless of how nerdy or geeky they are want to be, they really don't have any experience collaborating, building software, planning, executing, releasing into production, testing stuff to make sure it doesn't break, migrating data production. How do we form teams composed of business folks with no software development experience and I sprinkle in a couple of software developers and give them a framework that they can use to collaborate and build a complex product. Is scrum the answer there? Or is it overkill for business folks to try and train them and bring them into a scrum team?

Martin Hinshelwood [00:24:26]: No. I mean, I bring lots of business folks into scrum teams as product owners. That product owner accountability in scrum is something that I would normally see maybe a product manager on the customer side or a program, maybe a program manager on the customer side, somebody that the customer sees as who's the head of this program, who's the person that's going to be making the decisions about this product and this that we're building? because your job title doesn't need to be product owner for you to be a product owner, right?

Neil Benson [00:24:50]: I've never worked with a product owner in all my business apps projects who have any experience with Dynamics before, with being a product owner before, we teach them all of that as we go along. They need domain expertise, they need authority, they need division.

Martin Hinshelwood [00:25:03]: I did work with ISV years ago, many years ago, whoever the customer said this is gonna be your product owner, they had in the contract, they had to provide somebody who was the product owner. they would say to that person, have you been on have you done products on a training? Do you understand what a product is? No. No. No. I don't understand that. There's a course on this date, of you go we’ll pay. The ISV page. Right? Because it benefits the ISV if the customer understands what the heck you're talking about. Right? That they understand, the product owner doesn't need to understand the technical nuance of the product. Right? They need to understand enough to trust the team. They do need a little bit of understanding of the complexities of building building products. Right? But what they do need to understand is value. They need to understand agile product management. They need to understand trade-offs. They need to understand the hypothesis-driven engineering. They need to understand the impact of making a particular change on not just the financial impact, but also the impact that it can have on the business. And how do you monitor that impact so that you can maximize the value and return on investment for the business of giving you the money and you're spending it well.

Neil Benson [00:26:17]: Do you think there's a political impact as well? Do you think there's a, you know, you're gonna please some stakeholders by making a decision in their favor, and you're gonna piss off another one because some stakeholders’ gonna have to defer their favorite requirement.

Martin Hinshelwood [00:26:29]: Yeah. Some stakeholders suck, don't they? So yeah. Absolutely. I actually wanted to because there were 2 things that we talked about. Right? You talked about the customer. Well, I talked about the customer being the product owner. And having somebody that actually understands what they're doing is totally awesome, that cares as well. Right? They have to care. But there's a little bit that’s on us as engineers, that we're not really engineers anymore. It's a great blog post by Barry from the liberators in the Netherlands. And he talked about, he did it as a generalization, but all developers and our product developers So there's a difference. There's certainly the place out there for the uber coder who doesn't care about anything else but the codes and is building APIs and building or we've got people on our team that, yeah, this is the person who does all of the cool, crazy stuff. Right? The really technical stuff.

Neil Benson [00:27:27]: I've met a few of those. Yes.

Martin Hinshelwood [00:27:28]: That's totally the place for those folks. But the bit that's missing on lots of teams is like you're saying politics, product developer. There's a difference between a coder and a product developer. A product developer is somebody who doesn't just understand the technical nature of the product, who doesn't just able to code or able to test are able to do the things that they're able to do, but they're also able to communicate with the customer. They understand marketing. as well. Right? So the way I definitely think about it is one of the hardest things that teams hit is getting people into their sprint review. Like, how do you get stakeholders to turn up at your sprint review? And it's actually a really simple answer. Build stuff they care about and talk about stuff they care about and don't talk about stuff that they don't care about. I go into so many sprint reviews and the teams like here's the cool database triggers that we made this sprint. And I'm like, the customer doesn't give a crap. In fact, look, that customer is about to drop off the call and isn't coming back next sprint. Right? 

Neil Benson [00:28:33]: Well, I've had a couple where we're just gonna show you a quick demo in postman that the API we built is working. 

Martin Hinshelwood [00:28:39]: It's like, what are you doing?

Neil Benson [00:28:41]: We could do better than that.

Martin Hinshelwood [00:28:42]:

There's a thing in scrum that's a solution to that problem. It's holistic. Right? But is medicine for that problem. We have something called the sprint goal, and the mistake that teams make is they think that the sprint goal needs to be the whole sprint. That's the mistake that teams make. But, no, it doesn't. The sprint goal could be 5% of the sprint. It could be 10% of the sprint. But the sprint goal is your marketing story with your stakeholders. What are we going to show you at the end of the sprint that's going to wow you and show you that we're working towards your goals and your success? And, yeah, we have to spend 90% of the rest of the time writing postman scripts and database triggers and building cool architectures and setting up servers, but your customer doesn't give a crap. Right? they want the cool thing, the value that they can see. So it's perfectly okay to have a sprint goal that's a subset of all of the other work that has to happen, and we don't show that other work at the sprint review because the customer doesn't care. If you do have a customer that some people care and some people don't, then front load the value and reload the technical and then have a point in the sprint review where you say we're gonna start talking about some technical stuff if you're not interested in that stuff, perhaps you can drop off, and here's what we're gonna talk about next sprint. Right? 

Neil Benson [00:30:20]: So sprint goals for me, one thing I'm trying to do more now is help my teams write a sprint goal that's nice and short and sexy so I could put it in the outlook invitation, subject line, send it to my stakeholders, and it's an irresistible outlook invitation. I have got to go to that review to see that feature in 2 weeks' time. Got to clear my calendar, I've gotta go to that meeting, that event, that workshop, whatever you wanna call it. But, yeah, it's like writing a great podcast episode title, it's gotta be the sexiest thing that Neal and Martin talked about in a 30-minute conversation distilled into 10 words.

Martin Hinshelwood [00:30:45]: Yeah. Or less. Right? But this is that marketing proposition. But in the dynamics of the scrum team, this is the product owner's, part of the product owner's accountability, which is compounded when you work in professional services, and your customer is the product owner. And if they're not engaged in that process, you then have this gap where you have this massive communication difference between what it is you're trying to say and what the business actually needs. So you can never solve that. I've been working with a number of professional services organizations. And I've come around to the idea that we need something called a consulting product owner on the technical site. Yeah. I'm gonna be, so I'm trading a fine line here between there's one product owner.

Neil Benson [00:31:33]: Yes. I'm wondering where this is going.

Martin Hinshelwood [00:31:36]: There's still one product owner but what do you as a team do if the person who has been assigned, and this is specifically for professional services? Right? Because you are in company A, your product owner is in company B, your customer. And you need to interact with that person, but they get no clue. They're just a BA, a lowly BA who's been assigned this thing that they don't really know what it is. I'm, you know, being dramatic, but does quite often happen. And they've got no idea what they're doing. How do we fill that gap because there's a gap now between what the team needs and what the product owner can provide. So the idea of the consulting product owner is somebody who our product owner coach, how you really wanna call it. Is somebody who can do the role of the product owner so they can fill that gap between the customer and the team, but their main purpose is to increase the capability of the product owner and the customer. Because if the customer understands agile better, understands the ramifications of the choices that they make, understands how important these, you know, we're talking about empiricism. We're talking about hypothesis-driven engineering. We're talking about data analysis and all those kind of things. They understand that, you're going to be more successful as the ISV as the professional services company, you're going to be more successful in your engagement with the customer. So it's on you to help train and coach and mentor your customer towards a greater degree of the agility that you want your teams to be able to do.

Neil Benson [00:33:24]: I 99% agree with the idea you're putting forward. I'd say the 1% reservation I have is isn't that the job of the scrum master? Isn't one of their responsibilities or accountability is to coach the product owner in the application of scrum and empiricism and hypothesis-driven development and all those things you just said?

Martin Hinshelwood [00:33:44]: So yes, but and I know you're supposed to say yes and but yes, but. The Scrum master is focused on the effectiveness of the team. And, yes, they're supposed to also focus on the effectiveness of the product owner and the effectiveness of the organization. And in the context of a team inside of a company delivering inside of company A, delivering to company A or delivering a show product inside of company A, I would 100% agree with you. It's the scrum master's job. But in the professional services world, I'm not going to expect my scrum master to also be an account manager, to also perhaps have to deal with, I don't know, invoicing and politics within the customer's company because the difficulty that we're running into here that I mentioned twice specific to professional services is you've got this awesome team. They were working with this customer. You've built up to be this awesome slick machine, right, that we're all doing awesome. Everything is awesome. We're part of a team. And then they move off this engagement, and they get a new customer that's a waterfall customer. Now we've got a problem. Right? And then this engagement is only 6 months, and then they move off that onto another customer. I feel like you need somebody in your ISV who is a professional organizational change agent. who is your ninja for fixing your customers so that they can better engage with you and you can build more value and they want more work from you rather than that endless cycle of disaster and pain that happens in every single engagement with the customer, where at the end of the day, you're getting out the contract and poking at it. If you're in any engagement and you're getting at the contract and you're poking at it, you're screwed. You don't have a happy customer.

Neil Benson [00:35:45]: So that's my life. I've spent 20 years as a Microsoft partner, working with Microsoft customers, trying to deliver great products, it's typically most of the developers work for my organization, the partner organization. Some of them will will co opt from the customer organization. That's great. The product owner is almost always, I've never worked with a product owner who wasn't part of the customer organization, and I don't really care who supplies the scrum master as long as the competent It can be an independent. They could be from an agile consultancy. They could be from the customer's organization or from ours. All of those work well. But it's the product owner. The customer needs to provide a really top quality person that we can coach into that product owner accountability. Fascinating, that's the challenge we work with every day. I'm sure the folks on the podcast are all either nodding their heads or they're crying with their head in between their legs right now.

Martin Hinshelwood [00:36:27]: Because they might very well be in that exact situation. Right? 

Neil Benson [00:36:31]: Yeah. Martin, it's been a fascinating discussion. Have you got a few minutes to stay behind? I'd love to do a quick retrospective with you and get to know you a little bit better for the folks who've really enjoyed this discussion. You and I were just sharing a story about our Microsoft MVP awards and how long we've been in that ecosystem as well. You've been at an MVP since 2008. Did you wanna share with folks back home, who might not recognize your name or your expertise lies in the Microsoft ecosystem because that's a fascinating story there, too.

Martin Hinshelwood [00:36:54]: Yeah. So back in probably 2005, 2006, I started working with a little product called Visual Studio Team System, and I started poking the APIs is what I started doing, and I and I built a whole bunch of things. I don't know if anybody remembers one of the first demo applications for WPF, where it had a family tree. There's, like, a family tree application that loaded in a bunch of XML data and showed a family tree, and you could save it out. I copied that, and I basically changed the code, so it loaded work items out of team foundation server and visualized them on the, with all the links and things that were going on. And I've just published it, and I got a bunch of kudos for that, and that's probably one of the things that,I built a bunch of other stuff around that idea of APIs, and I got my MVP in 2008 but that very quickly launched my career. Right? It's definitely a great accolade to help people see that you're doing something. Right? Microsoft says this person's doing something interesting, and I very quickly moved into becoming a DevOps Consultant. So a software engineer for probably 8, 9 years, software engineer being paid, being paid. I started writing when I was eight years old, but being paid to write software for 9 years, and then I became a DevOps Consultant. And I worked in Seattle. I moved to the US, I lived in Seattle for 3 years being a consultant there, and then moved back to the UK, started my own business at naked Agility. and have been doing that ever since. I saw on LinkedIn it's like, no, it's 10 years. I'm like, Oh my goodness. Yeah. I've been doing it for 10 years. 

Neil Benson [00:38:40]: And the journey from there into, you know, a Professional Scrum trainer?

Martin Hinshelwood [00:38:44]: I actually became a professional scrum trainer way back in 2010, but I didn't do a lot with it. I did the odd class. I did the odd training. But I really, I came in from the developer side. So the professional scrum developer class that scrum.org had back in the day. It's now the applying professional scrum for software developers that Richard Hunthausen built who's awesome. 

Neil Benson [00:39:08]: He was a guest on our podcast a few weeks ago, a few months ago. Yeah.

Martin Hinshelwood [00:39:13]: Awesome. So he got me into this scrum thing, and then it's just kind of, I guess, it's festered and taken over since then. And these days, almost all of the engagements that I do are scrum and Kanban and process based. But quite often, people find me because of my Azure DevOps expertise. Right? So most of my customers are definitely on the Microsoft stack.

Neil Benson [00:39:37]: Fenny is listening, and they're a Microsoft customer or partner, and they think I could do with some of Martin's expertise. What kind of engagements do you love doing, enjoy doing, and how can folks get in touch with you?

Martin Hinshelwood [00:39:51]: Yeah. Quite often, short ones, I like to help people. And I find that I'm not usually above on a seat for 6 months with an organization. I don't think that helps. Organizations have the right people. They just don't make maybe have the, I don't know, the get-up and go to go make change and do things differently. So I like to come into organizations and help them out in a shorter period of time, maybe probably max 90 days. and make meaningful change in the organization in 90 days. So talking to people, sitting with teams, deep dive with teams, sitting in on their events, giving them advice, helping them out, helping them look at their data, and understand what's going on. Build Kanban boards. Right? because that's that's a lot of work. Build their workflows. But, also, I work with leadership teams as well, helping them understand how they can engage with teams push responsibility down the organization and democratize and decentralize their organizational structures.

Neil Benson [00:40:43]: Well, we'll make sure we include links to your campaign, your LinkedIn profile, and the show notes of folks to reach out and get in touch. Thank you so much for joining us on Amazing Applications today. It's been great to meet you, and I've been following a lot of your content on LinkedIn for such a long time. A wonderful conversation today. Martin Hinshelwood, thanks so much for joining us. 

Martin Hinshelwood [00:40:58]: Thanks, Neil.

Neil Benson [00:41:04]: I hope you enjoyed that episode of Amazing Apps with Martin Hinshelwood from naked Agility. Did Martin challenge any of your long-held beliefs? If you did, head on over to the custom ry company page on LinkedIn, follow the page, and comment on this episode's posts. If more people like you and our community discover and listen to this podcast, we'll be able to attract more and more awesome guests like Martin to share their knowledge and experience with us. In the next episode, I've got a guest that holds the opposite belief to Martin. He's the director for Dynamics 365 in the manufacturing industry for 1 of Microsoft's most successful partners. He's built his entire career on helping Microsoft customers, especially manufacturers gain competitive advantage by building on Dynamics 365 instead of custom dot net apps. Make sure you follow or subscribe to Amazing Apps in your podcast player or on YouTube so you don't miss it. Until then, keep experimenting.