In this episode of the Agile Embedded Podcast, hosts Jeff Gable and Luca Ingianni interview Weronika Michaluk, the software-as-a-medical-device practice lead at HTD Health. The discussion centers on the collaboration between software and firmware teams in medical device projects. Key points include the importance of open communication, aligned technical understanding, and clear user requirements. Weronika also highlights the significance of version control, regular and integrated team meetings, and maintaining up-to-date documentation. The conversation also touches upon client interactions, agile processes in the medical device industry, and the evolving understanding and attitudes towards these methodologies.
Navigating Firmware and Software Collaboration in Medical Devices: Insights with Weronika Michaluk
In this episode of the Agile Embedded Podcast, hosts Jeff Gable and Luca Ingianni are joined by Weronika Michaluk, Software as a Medical Device Practice Lead at HTD Health. Weronika shares her experiences and lessons learned from working with firmware teams, bridging cross-functional collaboration, and discussing the importance of version control, aligning technical aspects, and clear communication. The conversation delves into agile methodologies, customer interactions, and strategies for efficient requirement management in the medical device industry. Tune in to gain valuable insights from Weronika's extensive expertise.
00:00 Introduction and Guest Introduction
00:38 Veronica's Background and Experience
01:54 Understanding Software as a Medical Device (SAMD)
04:14 Lessons Learned in Cross-Functional Teams
05:42 Importance of Version Control
08:58 Team Collaboration and Communication
21:17 Managing Requirements in Agile Development
25:49 Effective Team Collaboration and Documentation
26:24 Tools and Processes for Project Management
26:42 Client and Team Meetings
27:13 Refinement and Feedback Loops
29:38 Change Order Process
36:11 Client Perspectives on Agile
38:09 Challenges with Agile in Medical Device Development
40:18 Differences in Client Types
45:47 Final Thoughts and Conclusion
Hello and welcome to the Agile Embedded Podcast. I'm Jeff Gable. and I'm Luca Ingianni. And today we are joined by Veronica Bichaluk. She is the software as a medical device practice lead at HTD Health, and she is here to talk to us about lessons learned as a software lead working with firmware teams.
So she is not a firmware engineer herself, but is highly technical and runs the software group at HTD Health and has worked with firmware teams and has seen some of the good and bad of that interaction. So Veronica, welcome to the show.
Thank you so much, Jeff, Luca, for having me. Welcome everybody. Very excited to be here.
Of course. Give the listeners a flavor of who you are and what you do.
Definitely. So my name is Weronika. As you can tell by my accent, I am Polish. I am biomedical engineer by training, have been in medical device industry for around a decade right now. And actually started the work as a biomedical engineer doing the coding, soldering, all the fun stuff.
And then had also part of my life working as a neuroscientist, a researcher in optogenetic field in Gwangju, South Korea. And after that time I moved to United States to Miami, where I did my master's and MBA at the University of Miami. And I joined a big medical device company, Boston Scientific, where I worked for many years.
Actually, I was in charge of digital health and software space within big organization like Boston Scientific. And after that time I got transferred to Barcelona, beautiful, sunny Barcelona, Spain, where I met Zach, CEO of HDD Health, where I'm leading software as medical device department practice, where we actually design and develop SAMD.
Nice. So for, so our listeners, some of them are in medical devices, some of them are not. So maybe give a brief summary of what, okay. So S. A. M. D. stands for software as a medical device. Maybe give people a brief definition of what that means.
Correct. Yes. So software as a medical device is actually a software, a standalone software that can run on any devices.
For example, can run on a smartphone, a tablet, a laptop, or even a smartwatch. My smartwatch that I'm having in here Apple not promotion it's not advertisement, but, Apple is actually class two medical device and the software is a medical device. is, as I mentioned, stand alone software that can either diagnose, treat, or have some impact on the treatment of the patient.
So for example, if you would have the mobile application that would diagnose you with some kind of heart arrhythmia, then it would be class two medical device. because it diagnoses you. Then if you would have I would give maybe more on the firmware side, example, because if you would develop firmware for a pacemaker is a medical device class 3 because it's actually very high risk.
But then you could develop software that would be a component for this pacemaker that would be, for example, either accessory or a class 2 device That would, for example, show for the patient their data, their patient data, and just help them throughout their journey.
Got it. People who've been listening a while know, so I work on embedded software in medical devices.
I often work on the SIMD software in a medical device, as opposed to what Veronica's talking about, SAMD, but often there is, there's a link between the two. Often you will have an SAMD component. communicating with one or more, you don't have to do this, but it can communicate with one or more embedded devices.
And so that interaction is what we're going to explore today. So yeah, maybe give us some of the high level bullet points of some of the lessons you've learned. And then I think we're going to want to dive into details.
Yes. Actually working there's a cross functional teams make it very interesting, but sometimes challenging, right?
As you all know, Jeff, for sure, so definitely in every single project right now, after doing many of them, I would say that Very important is to pay attention to open and clear communication between both teams since the very beginning. Also have this alignment on the technical aspects and understanding.
Also user requirements so that both firmware and software teams. They understand in the same way the requirements and also just the roles and responsibilities, aligning who is responsible for what, when, etc. So I would say that these are very high level, important things. Apart from all the one more, I would say that very technical one, even like aligning on the version control and how are we gonna really develop this software.
is also very important. So that's on the, in the nutshell, I would say the most important.
Luca, you got some questions? I know you do.
Let's start at the end then. You said that there was importance to version control. Tell us what you found.
Oh yeah, so Each teams they have their own, let's say, ways of of managing changes, right?
And version control is a system that manages changes to documents, programs and other information. I would say that aligning how do we even, develop software in GitHub. So our teams, work on GitHub and we have the configuration management document. And how do we manage any changes?
How do we work on the branches? What kind of nomenclature should we use? What we actually do is we have a meeting between the two teams and we agree, okay we will track changes in this and that way, right? We will do the branching and merging system in, in specific way.
And actually, it's not that one software team would say that we're gonna do it in this way, and then a few more team must align, but we want this to have a mutual agreement, let's say, to then create this configuration, which I call configuration management plan is also the term from software as medical device space, where we will actually agree on the terms, including also version history, the history of all the changes that allows, later on to easily roll back as the version history is also very important in the medical device space.
And even conflict resolution, when actually, multiple people could make like changes to the same file. So then a version control system can help you, to actually control this this space.
Sure. Are you familiar either with GitFlow or trunk based development specific practices that your teams have adopted?
Oh yeah, I'm not so much into it, but I know, they were they were going into specific different ones depending on the complexity of the project, also whether the, you will, we will foresee that the project will have many changes or not. How many teams, team members do we have?
I know that we work like on feature branches, development branches, you have the release branches but I'm not so much familiar with the community of the ones. I could bring on my technical leads to you, Jeff. No, it's okay. I
was just curious, but even what you were saying about feature and development and release branches, that kind of makes sense.
That's a get flowy type of workflow.
What I can say just once is that what I learned from the team is the version tags. The version tags are actually like the control system. that mark specific points in the history. And they always say that it's very important to also align, how are we going to tag them so that both teams are on the same page.
Got it. Okay. Let's be concrete here. What have you seen work versus what have you seen not work?
In the collaboration, what I've seen work
really well. Since you just said tagging is very important let's keep it very specific. What? Works. What's been useful for your teams?
Yeah, so what's been useful? They, again, they created a document and they agreed. Okay, we're gonna have a shared versioning scheme, right? So we're gonna say, for example, that it's gonna be v1. 0. 0. 0 V1. 0 firmware, and then V1. 0. 0 software. So that's what I've seen, and this kind of agreement, how are we going to do the versioning?
That really worked. And having a shared document like repository, when we work in different teams, we use confluence space. As a kind of one, as a true truth source of truth. We use Confluence where we have their RACI metrics, and then we have also this information and details like the version tags.
Etc. And then we have to ensure that they stick to it, because one thing is just write down, but then you gotta stick to it. So we actually, what we do, we also assign tech leads. Assign. We have a tech lead, and each tech lead is responsible for their teams. to actually stick to the rules and and work as should be.
This is fascinating because Luca and I are switching roles in this podcast. Luca's grilling you on concrete details on version control, versioning schemes. And I'm about to bump up and ask you a cultural question which our listeners know is these are, this is not our normal roles. Maybe not a cultural question but I want to bump back up to, you've mentioned several times the firmware team and the software team.
And that makes perfect sense. I am curious if you, and you mentioned cross training, I'm curious essentially if you ever embed a person with say firmware expertise, but they are actually part of the software team or vice versa to, I don't know, have that perspective always on hand. as they're developing.
Or if, yeah, so I'm, that's an idea and I'm curious if you've ever done that or anything similar or how concretely maybe you've managed those, that collaboration between those two different teams when they need to be working together. So you
know, even though we say like software team, firmware team, it's actually one team, right?
Because we have to, then at the end, we create one product that must work well and must be well, let's say, integrated. So yes, I do say like firmware and software team but normally they work very closely, they work very closely. And sometimes we even had one firmware engineer or two working on the firmware and then we had like full software.
Software team. So what I have to tell you is that even though they are, let's say separated, they're together. We have even daily mutual daily calls. So like normally we follow Scrum practices. And when we work on a daily basis, we have this daily standups, right? This, these are like short meetings for the team.
And we don't separate them like from software to firmware. We have the whole team together. And why? Because if software engineer would have an issue but maybe the issue would would be important for the firmware person. Why not to already communicate that during the meeting where everybody is?
So definitely having like mutual meetings also we have the team we set up Slack channels that we share between teams and all of the team members are there. We also have sometimes, smaller ones for example, backend versus frontend. So if they want to really discuss, only creating some kind of components versus what kind of architecture we're going to build.
So then this kind of very nitty gritty are set up. let's say separated discussions. But again the cultural thing, I think to help the team work efficiently, I always pay attention for the open communication and just being up to the date as much as possible. I don't know if that answered your question, Jeff, actually.
I think so. But how big are the Maybe specifically for HGD Health, how big are these teams typically? I know you do lots of different projects so it can grow and shrink.
It really depends.
What's the typical size?
Really depends. So for example we just finished a project pretty simple one, but very interesting one where we actually had to connect, create mobile application.
that was connecting with RISD Band and the RISD Band had a firmware. So on the firmware side there was a very small team, but on the mobile app, also not big, we had three engineers, a designer, a tester, a quality person, and a product owner. So that was not a big team, but to give you also an idea, we when we developed the full platform and then you had a sophisticated backend, admin panel, sometimes a mobile application, then we can even have 15 people in one team, then it's a lot, then it's a lot.
Sure. But by the sounds of it, you still have a boundary between the firmware people, And the the not firmware people, the pure software people, is that right?
Yeah, correct.
They are not in one cross functional team. They just they are adjacent, let's say.
They are, yes, they are like together.
I don't want to tell them say, tell, that's your, two separate teams. But as you have a software team, you have back end engineers, you have front end engineers, they are responsible for different stuff, right? But they combined the same team at the end. So that's what I would say for the firmware and the software team.
Of course they have different responsibilities and different objectives as like coding, programming wristband would be definitely different than creating a mobile application. But again, then making sure that it works together and we, for example, control in the correct way firmware and firmware, reply, response to to control from a mobile app, then we have to have this alignment.
Yeah, but it's still an interesting question. Are they? Do they consider themselves separate teams that just happen to work together or do they consider themselves one team made up of different specialists? Oh, that's a great question! Are they working from the same backlog or are they working from different backlogs?
The same backlog. The same backlog, different the same backlog the same daily standards. That is the same, but do they consider themselves as a, as the whole one team? I hope so. I do hope that we imply this kind of culture that they do consider that. I'm going to ask them tomorrow.
Not tomorrow. Tomorrow.
I would make that explicit.
I'm going to ask them, guys considering yourself one team, I do hope, but we use the same background.
Okay, there is another question that I've been wanting to ask since you said that as those teams are starting out. And now that I'm wondering how to phrase this, because it sounds like the teams are really one, one team made up of different specialists.
You said you made them. Sit down together and come up with a common approach for example for versioning etc. Yeah, I'm really curious What are the typical disagreements
are the typical disagreements? So sometimes we had the typical so again because I'm not doing the coding Myself, I would not tell you about the branching whether we should do this or that branching Strategy, but the typical disagreement that may be, funny like the time of the daily stand up, because one person prefers the one person prefers to stand to get up earlier, the other later on, or this is this makes this is funny, but this is like the most common thing.
The other part is that who should be responsible for documenting it? As Developers, they don't like documentation, they don't like documenting stuff. So we had this also no, the tech leads should be documenting that. And the tech lead says, why? If you're coding something, you should be documenting that.
So now what we have, we also developed the we have the definition of done, which is So in order the story to be done, the documentation must be updated. So if some if there is a developer that is responsible for specific user story, then that person must do the documentation. So that was also the company wide agreement.
And now, we just we just stick to it. And then at the, in the very beginning, of the project also Maybe some kind of just ways of doing code reviews. So in the beginning we were have, we were having this kind of discussions, who should be doing code reviews. for specific requests.
And now we just say that the the person, again, it depends on the project, but very often the person that just is available right now, or is the most, the closest, let's say to the specific tasks, but normally who is available just does this code review.
So it's not as important, maybe the specific person that does it, it's more important, the.
Like to do it quickly and get work merged in. But of course also correctly,
right? In a correct way, yes. But there is
a trade off there because if I don't know if I can see a situation developing where one person has domain expertise. And it's a bit of a self reinforcing thing where everyone always goes to that particular person for this particular area.
And so they become a bottleneck and
we had that, we had that. So we have actually we have amazing tech lead that actually everybody wants to have him on the project. And everybody wants to have him doing the code reviews. And that was the thing that he was like, Guys, I don't have time to code.
I'm just doing code reviews. Because he's really, experienced and has great experience. So then we agreed that, okay, give him some time, to do the thing that he actually loves. Thanks. So coding, and then others were just doing the code reviews. But we found it working well actually, so I hope that code reviews are being done well.
As again, I'm not coding myself, so it's hard for me to say, but I trust my team, so they provide high quality work.
Nice. Okay, so let's talk about requirements for a bit. So you said, up front, you like to align on requirements and I guess there's a couple of issues I want to unpack.
Okay. Tell me about the difference that, that upfront specification of requirements, and then as those requirements necessarily evolve over the course of the project, other than just, I, like you can say, yes, open communication, but I guess I want to dig into more specifics of, have you changed your approach to managing requirements and being able to update them quickly, efficiently has that approach changed over the last.
or a certain number of projects, that kind of thing. Does that question make sense? Yeah.
So the, I think what I could say is In the traditional way of developing medical devices, we would follow this waterfall approach, which is actually understanding the requirements from the very beginning and then just sticking to them and that's it.
But what we do at HTD is actually follow compliant Agile process, which is, which enables you to be Agile, but also compliant in the same way. So we work in sprints, right? We follow different sprints. We do reviews of the requirements, of course, those alignments on the requirements with the client.
and between the teams and if there is a change of the requirement, this compliant agile process enables us to do and how? We just follow our Standard Operating Procedure, which is about actually, a document change. And we do just change order, right? That follows the specific process.
And then we can implement the new, let's say, requirements. I don't know if Jeff, that was what you were asking about.
Yeah, I guess so. I guess I'm wondering, has your approach evolved over time? I knew you didn't do waterfall and you followed this agile approach that, that was also compliant in the medical device industry, but are, can you think of ways you were doing that in the past that introduced a lot of friction that, that you changed that standard, maybe focusing on the SOP on the standard operating procedure.
How much has that changed over time as you've discovered better ways of doing things? Or has that did you the team came up with that a while ago and it's worked well for you and you basically haven't gone back and modify that.
Yeah. So in the very let's say long time ago that also links to maybe even the, our discussion previously we didn't have the mutual meetings between firmware, we firmware and software engineers, we had them separately.
And then that brought into some friction even between just talking about these requirements. aligning on them, agreeing, and changing. Inconsistent documentation, I would say. Inconsistent or not so much up to date. You could say that now what we do, again, the finishing of done, you gotta always complete the documentation before the story is done.
So that is something that we implemented like a year and a half ago. Cool. Two years ago where we wrote our, compliant ISO 1345 certified quality management system. So now we implement the specific rules, which is, for example, this keeping documentation up to date, this definition of done and specific specific procedure for the compliant agile.
And I would say that keeping documentation up to date. is definitely a game changer because we don't have to now like just think about what I was doing a month or two months ago and what kind of requirement was it then and how it, how is it gonna change right now. But if you just keep your documentation up to date and have regular meetings with a client to review the requirements it will help.
I would not say that it's, let's say that we were doing things in not correct way as but I would say that just keeping these two teams very close together and keeping the documentation up to date, ensuring that it's up to date this helps from my experience.
Speaking of how you elicit requirements or how you document them, how is that typically done?
What does customer interaction look like? What does the interaction with the teams look like? How do feedback loops look like? That sort of thing.
Very great question. What we do, we follow, we use Jira for our, this project management system. Then we use GitHub for testing. We use X Ray. and then for quality management system, electronic management system, we use Greenlight Guru.
So then everything is actually integrated together. And what we do we also hold very, not very, but often meetings with clients. We follow this scrum. So we have these daily stand ups, once we agree on the time for the two teams, firmware and the software team. And then we also hold refinement, refinements internal ones, just between the teams, really technical ones, but also refinements with the with the client.
And this is the meeting where we want to align on the requirements and document them as well. So during the meeting, the product owner takes on some tasks. Some nodes. Then after the meeting, we agree on specific, let's say, requirements for specific sprint. And then we document them in
Who's meeting?
Sorry?
The product owner and who else?
Refinement, a refinement meeting between our teams and the client.
Okay, so the entire software team or firmware team and the client.
Correct. Yes.
Okay, so
Not always entire, we don't want to just burn their down. Actually, very often we just have representatives let's say, tech lead or representative from a firmware, representative from a front end, back end, product owner and the client.
Okay. Testing as well, by the way? Okay.
Depends. Not always. Depends. Sometimes we do have a testing where tester is they want to understand, how are they gonna test it. But very often this the tester is always present during the internal refinements. this is always because they ask very good questions.
They,
they
ask great questions, like, how are we going to actually do this? Are you sure? Or how are we going to test that it's actually, it's going to work? I love just listening this kind of part just like the questions they ask. So this during refinement meetings the product owner then writes down the requirements.
We then give the written requirements again for the review for the client. Then once approved we we can proceed and just develop that. And then after that, we also hold sprint reviews or design reviews. And during this meeting, we present the increment for the client and then we get the feedback.
And, hopefully the feedback is good and there is no change needed. If there is change needed, we follow the change order process. and then we show the increment we change during the following sprint review.
Is there, for you, is there a difference pre release and post release?
So I imagine some of these projects, you're building them up for the first time and then you come out and you do the big first release, but then there's ongoing development. And so when you say like the change order process, in my experience that's often instituted after the first release and you don't really have that during the initial development of the first release of a product.
Is that true for you as well? Or do you do you follow that change order release during the entire initial development phase of a new product?
Great question. So we actually have two processes and it's one says before release and the other says after release. And the first one is definitely much easier because it's just, about actually updating the requirements, the notion, of course, following the process.
So when we have Jira, we actually also in Jira, we have like it's very now detailed, but you have the tickets that are in sprint backlog, in development, ready for review, in QA, then let's say acceptance criteria not met. So if the acceptance criteria are not met, then we have to follow the whole process from the beginning to ensure that then the verification is done and everything is passed.
So then, if you do the post release, of course, it's It's more complex and but we have, there's still separated ones.
Tell me more about this change order process because it sounds very scarily waterfall ish.
Man, and you got me where I'm not so much involved in in the change order process.
We have the teams there to do this job. And why? Because it's sophisticated. No, yeah, I won't be able to tell you so much about the change order but if you would like to do this let's say follow up discussion about it, I can bring on some votes from my organization.
Actually, maybe that would be interesting.
Great question,
yeah, it's that's one of those things of I In my experience in the industry, most of my experience is in the initial product development, like up to first release. And so I often don't have to interact with those scary change order processes, but I just know that they can be done well and they can be done not well in the sense of the fundamentally, the purpose is to evaluate and mitigate any risks.
That's the thing that separates medical devices and other safety critical industries from non safety cartel industries. And so I've just found that a lot of change order processes that I've seen in the wild there's just elements to them that don't actually contribute to safety. They're just, It's just friction.
It's just doc, it's just heavyweight. And I dunno I would be curious how your team if I were to pull one of the members of your team aside and say, okay, tell me about this change order process. Is it like, is it Does it have too much extra baggage or is it pretty lean at this point?
I hope.
I
don't know. Like you, you may not know the answer, but obviously but that's something that I would want to ask individual team members is essentially if they are frustrated with that process, aside from the fact that software developers don't do documentation. Okay. You're a professional buck up and do it, but if there's aspects to that process that are.
actually wasteful and don't contribute to the goal, or if really everything in that process is absolutely necessary and is the way, as, as refined as it could be.
So you know what we also do with with teams because in the very beginning, so many different things I will share. So first of all At HTD, we have medical device practice, and then we have non medical device practice.
Every person that actually joins medical device practice is being asked before they joined whether they are ready for like additional documentation and sticking to the rules, etc. So they are mentally prepared that there will be more work and more documentation to be done.
But also we have this continuous improvement, right? So it's not that the procedure is being written and it's done but we update them and we do really update them. So we have also management reviews, which ISO 13485 certification and audit process. So you have to stick to specific rules and we have to just review the procedures and we did have the the situation where actually our tester when we prepared one tester prepared.
the software verification, design verification template. And then the other came, and they were like, it doesn't make sense, I don't want to do this. So then we were like, okay, so let's find the optimal way. So we actually had some workshops, and then, aligned on that. So I hope my team would say that now it's the process is good.
Whether it's perfect, not sure. We are,
it never is, but that's okay. Exactly.
Whether we are continuously improving and we are getting the feedback from the teams. Because it's actually, I also want to tell them that, this processes and procedures, and not just like for us to get the certificate or for us to be compliant, but also for you to know how to work and to make the work just easier.
And, just, understandable for everyone. So if somebody will tell me, Veronica, this doesn't make sense, I'm more than happy to sit down and, an update to, to make sense.
I have another question on customers. That is if you're looking back over time, have you noticed that clients have changed their views on agile processes, that they've become more interested in them or more knowledgeable about them or?
What has been your experience?
Yes, I think more aware. I think more and more aware and just they understand Agile because a long time ago let's say when I was starting in the medical device space 10 years ago not so many people were like talking about Agile. At least when I was like talking maybe because I was mainly working with really engineers, not software, but more firmware then.
But I do see from the client's perspective right now that they more and more just talk about agile and they even understand, what's cram, what is the daily standup? We're going to refine that. Okay. Let's refine the tickets, so that is wow. But also depends on the client background, because if we work with like VP of product or tech, we have a person with technical background, it's much easier to chat than with a person that, just have has a big business background because then they maybe don't have to know about it.
But in general, yes, I do see improvement. More and more people understand agile, maybe because everyone. Now, just the pretty that I see in my kind of environment, that more and more people talk about Agilent. So maybe that's why also the customers hear more and more about it, but curious also here, what is your kind of experience?
And and feeling. Is it all the same?
It's difficult to say because I have a bit of a selection bias. I'm one of the hosts of the Agile Embedded Podcasts. The people that approach me are people who care about Agile in some way, right? That said I think the industry as a whole is still not where it ought to be.
And I think it's also lagging behind many other industries in that regard. And there are, many reasons for that. Some of the reasons are Reasonable. And some just aren't, some are just excuses, but I feel like a lot of teams are still getting the hang of Agile for themselves. And they are not yet quite at the point where they feel comfortable enough in those practices to really educate the customers and guide them in as a customer, this is what I expect from you during a refinement.
This is what I expect from you during a sprint review. Don't just sit there and say, Oh, this looks nice. That's not helping. How is it nice? How is it not nice? Give me something useful. So I, I think I suppose I, I echo your sentiment that customers are getting better, but I still think that, there's still a long way to go.
Yeah, especially, great point about the medical device space, right? Medical device space is a pretty, unique one, we can say I love it, right? But it's so regulated also. And maybe because in the past there was not so much of a software in the medical device space. When you think about medical device, you think about the pacemaker, you think about this big bulky stuff, right?
But now more and more are just like the software. Software is a medical device. So maybe that's why also so in 10, 20 years, I hope if you say medical device, you will think about software as a medical device. And not only because I work, on this.
Yeah. For I'll jump in and give my perspective the types of clients that I interact with if they're development houses.
So if they're like HG health is a a development firm that will do projects for clients. If I'm working with them often, they're very they come in with the terminology and wanting to pick my brain on how to do it effectively. If I'm working directly with startups.
It's a mixed bag. Sometimes it's essentially a non technical founder that has assembled this team of experts. And at that point, I'm the software team or at least the firmware team. And so I get to run the firmware side, however I want, but I I constantly have to educate them on the two big things like a, that, the whole.
Scope and time and budget. If you fix all three, you're going to have a bad time. And so really being ruthless about prioritizing those things. No, all of these things must get done by this date. I'm like, okay, we'll try but no, really if something had to drop, if you had to choose something, let's put it at the end and focus on the most important things first, right?
And just drilling that mindset in them. Okay, we're going to do the most valuable things and at least we'll have something valuable at the end of every development iteration if you want to call it a sprint. And the other thing is just good quality feedback. Just like Luca said, don't say, educating them not to sit back and be nice and know if it looks good or like to really use it as their customers would use it.
And usually that goes over pretty well. That's, people don't often fight that. I don't know. I'm, I feel like I'm rambling a little bit, but I would say there's, from my perspective, there's a big difference between working for a development house and working for highly technical startup, and then maybe working for non technical startup founders.
I see big differences there.
I couldn't agree more, Jeff couldn't agree more. Yes, because combining what you said and what Luca said, about also the feedback, because it's not just the feedback. Oh, beautiful. I love the UI. I love the button, but give me the quality feedback.
To, to your point, it's so crucial and also just aligning on terms. When you speak with a technical funder, at least for for me, it's much easier to discuss the development than if I would speak with, non technical person, right? But again, you have to, as a, not you, I mean myself, like as a service provider, as a service provider, we have to communicate in a way that our client will understand it.
It's our kind of job, right? We also ask the clients in the beginning, how familiar are they with the development and with all the terms. And sometimes we also educate them. We show them the Scrum process. We show them how we work. what are different terminologies, and you also say what is important for us to receive from them.
Because if there is a business kind of minded client, they will not tell you that they want to build nice mobile patient application that will integrate with a hardware solution and something, via Bluetooth low energy 5. 0, whatever. But they will say that they want to achieve XYZ business goal.
And then we would just have to discuss it in a way that both parties will understand.
The thing about qualified feedback reminds me of my grandmother who is the author of a sort of moderately famous cookbook. And so when my, yeah, and my when we were invited to Sunday roast or something at her house, and she'd be like how do you like it?
And of course you'd want to be polite to your grandma and say, Oh, it tastes very nice. Thank you very much, grandma. Which to be fair, it did. And she was like, this is not helpful. What's good about it? Tell me. What's the
name of the cookbook? I will double check.
It's in German, kochen.
I don't know. I don't understand.
I don't speak German.
Yeah, it's been going since the 1950s. So yeah.
Wow. What's your favorite recipe from there?
I couldn't tell you.
I
couldn't tell you every family has their own taste. Isn't that right? And this cookbook is full of what my family enjoys. So they're really all good recipes as far as I'm concerned.
Wow. Nice. That's awesome.
All right. We're starting to run a little long. Any other points either of you want to cover before we wrap up?
I would just say, that they really enjoyed the conversation as you really picked my brain and man, I got to learn more about the version control
now, read some version control and do some some reading about the Git branching.
No it's really not important. I was just curious. It was something you brought up. And so we dug on it a little bit, but
that's right. You don't really need to dig deeper into it, but it is interesting because it allows us to, to look behind how the team is working and what they're valuing.
So that's where the question really came from.
Yeah. And of course, and it's important, because actually to ensure that we meet the deadline, it's. all these little pieces from this version control branching to communication, then daily standups, how the team actually works so that then we can ensure that we meet the deadline and we deliver the project on time and we get the good feedback, good quality feedback.
Exactly. So Veronica, is there anything you'd like to tell our listeners about or let them know?
If they would like to just reach out to me, I would love to, to talk whether it's about, Firmware development, software development, they can reach out to me on LinkedIn, and I would be more than happy to chat.
Not about
version control strategies though, right?
You know how you learn a bit, and maybe, or if they want to teach me, then reach out.
Perfect. And we'll be sure to have your LinkedIn profile in the show notes. And yeah, this has been great having you on the show. Thank you, Veronica.
Thank you so much.
It was a pleasure to speak with you. And, as I didn't mention maybe before so much we were talking about the firmware and software. so because we actually do that at HTD Health. So if you want to talk about version control or developing software as a medical device, reach out to me and we'll be happy to chat.
Thank you so much, Jeff and Luca for having me today.
Thanks for joining us.
Thank you.
Of course. All Podcast. I'm Jeff Gable.
And I'm Luca Ingianni.
And we will see you next time. Thank you.
Thank you.