This week’s episode is the third in a three-part series about custom web applications for today. Justin Bantuelle, Chief Operating Officer & Web Technology Director at Health Connective, breaks down why Agile development matters. In this episode, you’ll learn the importance of not jumping in before you’re ready, what questions to ask before starting the dev process, and how being able to pivot, partner, or stop development can sometimes lead to better results.
Announcer: It’s time to think differently about healthcare, but how do we keep up? The days of yesterday’s medicine are long gone and we’re left trying to figure out where to go from here. With all the talk about politics and technology it can be easy to forget that healthcare is still all about humans, and many of those humans have unbelievable stories to tell. Here, we leave the policy debates to the other guys and focus instead on the people and ideas that are changing the way we address our health. It’s time to navigate the new landscape of healthcare together, and hear some amazing stories along the way. Ready for a breath of fresh air? It’s time for your paradigm shift.
Michael: Welcome to the Paradigm Shift of Healthcare, and thank you for listening. I’m Michael Roberts here today with my co-host Scott Zeitzer and Jared Johnson. Today’s episode is the third in a three-part series about custom web applications. We’ll be breaking it down into three key questions. In the first episode, we talked about when it makes sense to develop a custom application. We talked, secondly, about what the application should do. And today’s episode we’ll be talking about how that application should be developed, in the series, all the way through. Guiding us through all the different questions that we have is Justin Bantuelle, he’s our Chief Operating Officer and Web Technology Director here at Health Connective. Justin, thank you once again for joining us on the show.
Justin: It’s my pleasure.
Michael: Awesome, awesome. So, we’ve been talking about this concept recently because we’ve been going into some application development of our own and we’ve been looking at updates and progress to make on the P3 platform that we have for our customers. You know, we did an internal survey and we went through and we talked about all the pain points that we see on our side of managing a platform, and on the customer’s side of where they find pain points. We’re going through a voice-of-consumer project right now where we’re getting a bunch of feedback from our customers of like, “I like this about the platform. I don’t like this about the platform. I wish it did this. I wish it did that.”
All of that kind of information goes into feeding one of these plans when you talk about what you’re going to build for your company. These are all the data points that you can use. And then again, just to be completely transparent with this process, you can bring that data to your programmer. You can bring that to that development team and go like, “Okay, these are the things that we’re trying to do. Now let’s talk about how we can actually get there.” And, you know, Justin, I’d be interested in just using that experience, you know, like around some of what we’ve been talking about with P3. Like you and Katie from our team have been talking about what can we do next and where do we go next. And how do you approach that project in particular?
Justin: I find, as developers, what allows us to succeed, and, thus, allows the customers to succeed, is trying to be less I guess prescriptive. Our goal is to be the web-development expert. So, we should know best how to build an application that meets the needs of the customer. When the customer can come to us and articulate, “I have these very specific problems,” it’s our job to ingest that information, really comprehend it, and come back with proposals about how we would solve those problems and walk them through why these are best practices or why this is how it’s commonly done, all the technical considerations that go into it.
Because a lot of times, when you need an application, I’ve had a lot of customers who are very very engaged, which is awesome, but then they start to think about things in terms of the very visual final product and then say, “I really want this page that looks like this and I want these buttons.” And sometimes that’s jumped a little bit too far ahead. And giving some space for someone else to come back with ideas of how they’re gonna solve your problem…because, ultimately, when you say, “I need this button,” it’s not that you specifically need that button, it’s that you need your application to allow this a certain kind of interactivity. You want somebody to be able to come to your application and solve this problem. You want to be able to fill this information out, or search for this information, all the different kinds of use cases you come up with. Taking a step back and thinking about, “What do I need?” and not so much, “here’s what I want you to create for me,” “here’s what I want it to look like.”
And it’s not to say that input’s not valuable but I think creating space for some like wireframes or mockups, in some capacity, letting something take shape and letting the developer put a little bit of guidance into it…because, a lot of times, there are considerations that the customer doesn’t even know are a factor. You see this, a really easy one is anything around accessibility. So, specific colors and specific brandings may not translate well to the web the way that they do on print pieces. And, oftentimes, branding guidelines were assembled, the web wasn’t necessarily thought through all the way. And making sure that people with various kinds of color blindness can still see your site and navigate it, oftentimes that’s something that isn’t an occurrence. But people have very strong feelings about colors and branding. So, the need to find some kind of compromise there can be difficult if you don’t understand it and you don’t have somebody that walks you through why you may need to adapt a little bit from what your initial vision was.
The same comes into play with where elements sit on pages, the fact that web applications need to be responsive. Like the developers should be considering it at every possible screen width. Whereas, if somebody is predominantly interacting with it on their phone, like the customer thinks of it as a mobile device or as a desktop device, then they’re not gonna realize all the other things that feed into it. So that becoming prescriptive out the gate I think can really hold back the process or prevent a more robust solution at the end. So, I think, coming back at the end of it and saying, “Oh, okay, you built this for me and I wanna make these tweaks,” that’s very reasonable but you and somebody is just like, “take this picture that I have and turn it into a website,” is not always the win.
Michael: Well, you know, one of the things that we definitely look to and definitely implement is, you know, the whole concept of Agile development. And, so, could you kind of walk us through like a 101 version of Agile development? You know, what it is, the key aspects of it, and how it is different from traditional application development.
Justin: Sure. So, there’s a whole lot around Agile. There’s a lot of disagreement with various people around what exactly it entails. But, in a nutshell, it’s the idea that you don’t know what you need until you start building it. And to get a good outcome, you need to recognize that being responsive, hence Agile, in the development process and making that part of the whole process, not just, “Oh, the coder needs to go do this,” but the stakeholders, the project managers, everyone involved…it’s a team that’s all collaborating to produce some kind of final product that’s going to succeed. And you’re going to realize, “I didn’t think about this,” “oh, I didn’t realize that was gonna work this way,” “oh, I don’t actually need this. I need that,” like there’s so many emergent issues that occur very organically. And it’s a healthy part of a process when you’re building something complicated.
A more traditional waterfall approach spends a tremendous amount of upfront time trying to ensure that you account for every single thing. And a lot of people have found that, no matter how much time, money, effort you put into it, you miss something, you don’t think of something. And you don’t wanna be locked in once that happens. And you can do change orders with waterfall, you can adapt. But the process is more painful because the assumption everyone was operating under was that it wouldn’t happen. And then it inevitably does.
So, Agile sets shorter-term milestones and bakes check-ins into the process and doesn’t say, “Here’s this rigid requirements document we’re building to this, and I really hope it does what we need.” It says, “Here’s some goals. Here’s short term…we’re gonna deliver this and we’re gonna deliver this. Let’s keep checking in. Oh, okay, this isn’t working.” “Instead of doing the next thing that was on our priority list, let’s reorder the priorities, let’s move this thing in. If you don’t have the budget for it, that’s cool. You can pull something else out and we’ll continue operating under this same budget. If you needed to pick up this new work, then it’s all part of a natural workflow.”
I think something I saw that was useful around this was the concept of having sliders. So, you have a speed-of-delivery slider, you have a cost-of-delivery slider. And I wanna say maybe it was quality was the third one, it’s been a while since I’ve seen this comparison. And the idea is that adjusting any one slider saying, “I want more of this,” means you have to reduce on something else. So, maybe you want it to be just absolutely rock solid, like the highest quality product imaginable. Well, you’re gonna have to spend a lot more money as a result of that or you’re gonna have to let the project take a lot more time in order to achieve it. These three things are in constant tension with each other. So, recognizing that and not treating them like they’re static but, as things that you can adjust, you have control as the customer of it. The upfront communication around this allows a lot more control of the final product.
So, that’s I think kind of in a nutshell what Agile is. There’s a whole lot of things that go into it, like I said, how you achieve it. Scrum is its own like whole business process that it’s tied to Agile. But I think, from a customer standpoint, it’s about how you get control of where you end up.
Michael: Hi everybody. I always appreciate that you tune in, that you’re listening to the show here. I wanted to let you know that we have set up a new newsletter that you can get to at paradigmshift.health, that’s paradigmshift.health. You can go there and…the reason that we’ve got this newsletter is that we like to send out a few extra pieces of information with the show. We also have a full transcript for every single episode that we do and we can let you know that through email, we can let you know also, if we have like a good quote card, to be able to show for every episode. So, check that out if you’d like. paradigmshift.health. Thanks so much.
Scott: You mentioned the word Scrum and Agile. It’s like constant tweaking, constant conversation between all the parties to make sure that you are kind of in sync. Things change. You know, I can think of many times in our company’s history where just making sure we were all together, as a group, and making sure we were all on the same page before we made that next leap in application development, and anything that we did, has always been helpful. Do you have any examples of how Agile development has saved maybe our own company time and money or one of our key customer’s time and money?
Justin: I think, just going back to where we’re talking about with P3, is a very prime example where we knew the space, we knew there was a need but exactly how to best achieve that need for our customers wasn’t quite apparent. So, instead of investing a tremendous amount of time and a whole bunch of features that may not have even been helpful, building to that core set of needs and then getting information from our customers about how well we’re solving their problems, what problems they wished we were solving for them…I think some of this also goes into, I’m sure Michael remembers this, where we tried to support our own reputation marketing.
Michael: A very short-lived experience at that time.
Justin: You say that but like we put some significant effort into developing an initial product but we didn’t do everything we possibly could. We definitely took this phased approach to it and then, once we had something we thought was ready, we tried it out and it really fell on its face. We could’ve continued pumping more money into that really trying to make this work, but you found a way to sidestep this by integrating with companies that have already figured out these problems. Why reinvent the wheel?
Scott: That’s a really good example, Justin, of an Agile process and how continuing to keep everybody in the loop is really helpful, not just from a programming perspective but from a business perspective. So, we definitely wanted reputation marketing, we’re very good application developers, we basically said, “Hey, this is easy. We’ll just make our own.” And, you know, I say it with a smile right now but…and the positive side of it was we always had an open mind, we always kept communicating, you know, you put some time and effort into it but not enough to bring the whole company down, just enough to know, quite frankly, “Hey, this is a lot more than you think it is. And here’s why.”
And then, when we knew that, we went back out and found the partners that we knew could bring something to the table. But we were also able to find those partners with more knowledge because we took the time to investigate what we really needed. And for us, the custom application developers, we actually decided like, “Hey, we don’t need a bespoke system. There are people out there with stuff that we could adapt smaller parts and make it work better.” And I think that that’s actually a great example of being very open-minded and incremental because sometimes the custom map is the way to go and sometimes it’s not. And for us like having…we have a lot of trust built up within all of our different departments where this was the right decision to make was not moving forward with the application development. Right?
Justin: Yeah. And another part of it is that it was in a broader context of an application. That was a component of an application we were building. So, that pivot allowed us to also reuse other pieces of this and ending their new billing system and just dashboard, in general, stemmed from that. So, we were able to react properly and everything we learned led us to a very healthy place. So, a lot fewer things are wasted when you’re incremental like that, when you’re comfortable being agile. Whereas like, if we’ve been afraid to say, “This isn’t working, let’s change tech,” it would’ve been a disaster.
Scott: Yeah, I agree. And, instead, it turned out to be, you know, quite successful. To your point, we were able to find exactly what we needed, you know, from a checklist perspective, and then find the right partners for us. And then, on the back end, we were able to integrate better with the platform we created with what was already existing. And, so, instead of just having something as a me too, shall we say, for, in this particular case, reputation marketing, it’s like no. We took somebody’s very well developed reputation marketing system and then brought it and adapted it to what we had so that, frankly, it wasn’t an additional effect, it was a multiplicative effect. It’s like, not only do we have a reputation marketing system that’s working well, but, on the back end, we’re connecting a lot of dots that, you know, frankly, can be a little difficult to put together. And, so, when our marketing teams are talking with the practices out there, we’re able to have much better conversations where we could talk about reputation marketing, we could talk about Google Analytics, we could talk about what’s working, what needs to be improved. And it, overall, makes for a much more successful and better conversation for our customers.
Justin: Absolutely. We don’t have this open dialogue with your developer. When you try to stick to extremely rigid requirements documents and you don’t create that space for flexibility, there’s a very good chance that they’re going to develop exactly to that and neglect to surface those concerns. Because, if you’re not open to that on your side, they’re gonna meet their contract and then you’re gonna be unhappy at the end of it. So, being able to adapt allows them the space to bring up new ideas, identify potential pitfalls, and work with you. It helps you in the long run because you didn’t just pay for something that doesn’t help you but that you technically asked for.
Scott: Yeah. So, there’s a great example of, you know, “Oh, did we create a successful product?” Yes, we did but it just changed drastically about what our final product was.” And it’s not really a programming thing, it’s a communication conversation about, you know, don’t silo. Don’t hide from the IT team, don’t hide from the marketing team, don’t hide from the sales team. They’re all gonna work together. And it worked quite well for us internally. But, Justin, you and I have been at many at a Fortune 500, 150 company where that siloing occurred and we had to come in and try to bring everybody together. Because we are comfortable talking with everybody and kind of translate accordingly. And I do hope that anybody listening, like just, you know, be open-minded about grabbing these other teams to try to get some opinions. And be prepared for some tough questions.
Justin: Yeah, and be ready to walk away from an investment. Like sometimes you’re gonna get part way down a pathway and realize that that’s not where you needed to go. But view it as research, right? Like research is an essential component of building out anything successful. So, as long as you learned something from going down that pathway, it wasn’t wasted. And, if you feel like somebody was still being judicious with the work they were doing and were working to what you were asking for and it was all in good faith, then I think, long term, you get a very good partnership, you get a very good outcome.
And there’s some people who that may not be the case. Like sometimes you get the wrong developer and you do need to find someone who works better in that capacity. Because that trust is an essential component of Agile. Agile really does not function without trust. So, I think that’s an essential component of it. Not viewing it as being quite so transactional but being more a long-term partnership. And if somebody’s not there to support you long-term and you get the feeling that they really are looking for just that paycheck and then to bounce, that’s not what you’re going to need. So, it’s a very big red flag.
Michael: Hey, Justin, this has given us so much to think about. I think just helping everyone who’s listening realize what goes into the decisions that are involved in any kind of custom web-application development is useful for everybody to know. Because, at the end of the day, everyone’s involved, in one way or another. And, when we kind of tie this back to, you know, expectations of everybody, that’s just as important of a deliverable as the actual application itself. So, we all appreciate how much you’ve given us to think about there. As we kind of wrap up this whole three-part series, I’m wondering if there are any other insights that you have for us we haven’t really yet covered? You know, any final tips or thoughts for our listeners that have crossed your mind as we’ve been talking about all of this?
Justin: Kind of recapping it, I would say that it’s important not to jump in before you know you’re ready. So, really assess the field, the problem you’re trying to solve, and be certain that this is something unique enough that it’s worth investing in. And then, once it is, I can’t stress enough how important is to find the right partner to build it for you. And just being open-minded, understanding that the right process allows minor failures not to derail anything and are actually learning experiences and are helping to shape that final product. So, the more you engage with the product, the more you engage with the developer, the better the outcome is. Thinking that you pay, they go away and they come back with something is never gonna yield what you’re looking for.
Michael: Justin, thank you so much. That’s three episodes in a row. You carried the show for us, we just got to pepper you with all these questions, so, thank you so much. As always, this whole conversation around like how technology and healthcare intersect, I mean this is something that we’ve talked about quite a few times here on the show. But these are the things to think about as you’re going through these processes, as you’re running your company. So, we hope that this information has been helpful for you. Thanks so much for joining us on this journey. Have a great week, everybody.
Announcer: Thanks again for tuning in to the Paradigm Shift of Healthcare. This program is brought to you by Health Connective, custom marketing solutions for medtech and pharma. Subscribe on Apple Podcasts, Google Play, or anywhere you listen to podcasts.