Don’t Go Chasin’ Waterfalls – Why the Agile Method is Preferred for Software Development
Weronika Michaluk is Digital Health Principal and SaMD Lead at HTD Health, a company dedicated to planning, designing and developing custom healthcare software. Weronika is an experienced professional with a diverse background in the fields of biomedical engineering, international business, and public health. In this episode she shares the differences between the waterfall and agile methodologies, what sprints and scrums are, controlling scope creep, working with a company that does not have agile experience, assuring regulatory compliance, and the tools and tech stack that are used in today’s software development environment.
Links from this episode:
Weronika Michaluk LinkedIn https://www.linkedin.com/in/weronika-michaluk-mba-43811698
HTD Health https://htdhealth.com
Connect with Mastering Medical Device:
LinkedIn: https://www.linkedin.com/company/mastering-medical-device
Patrick Kothe LinkedIn: https://www.linkedin.com/in/patrick-kothe
Patrick Kothe Twitter: https://twitter.com/patrickkothe
Support the show for as little as $3/month: https://www.buzzsprout.com/1286645/support
Thanks for listening!
Episode Transcript
This transcript was generated using an automated transcription service and is minimally edited. Please forgive the mistakes contained within it.
[00:00:31] Pat Kothe: Welcome! Every March people get obsessed with college basketball. March madness, for many involves studying the field and then filling out a bracket. Picking every winner from the opening weekend to the championship game. A lot of hours are spent analyzing match-ups several rounds ahead. With the assumption that those teams will still be in the tourney. The reality is your odds of picking a perfect bracket are one in 147 quintillion. Now imagine if, instead of picking all the winners before the tourney begins, you pick the winners before every round. Your odds of success would go up considerably. And you would spend a lot less time analyzing match-ups that would never occur. Well, this is essentially the difference between waterfall and agile development. Instead of detailed planning at the beginning, everything. The project is broken down into phases with emphasis on continuous collaboration and improvement.
Our guest today is Veronica Michaluk, digital health principle and software as a medical device lead at HTD health, a company dedicated to planning, designing, and developing custom healthcare software. Veronica is an experienced professional with a diverse background in the fields of biomedical engineering, international business and public health. In our conversation, we discussed the differences between the waterfall and agile methods, what sprints and scrums are, controlling scope creep, working with a company that does not have agile experience, assuring regulatory compliance, and the tools and tech stack that are used in today's software development environments. Here's our conversation.
We're going to have a really nice conversation on software development, different methodologies and how that's done. But I want to start off with something that you've recently done that a lot of us aspire to do, but not a lot of us have done.
You've, uh, climbed Mount Kilimanjaro. tell me a little bit about that. Is it something that, on your bucket list, something you always wanted to do? Tell me about the experience.
[00:02:58] Weronika Michaluk: Oh yeah, so I have to tell you that the experience was simply amazing. It's been always on my bucket list and the fun fact is actually, you know, during one of my vacations in Croatia, actually, I told it to my friend, like to my best friend, I said, like, Hey, I would love to climb Kilimanjaro and he said like, let's make the dream come true.
So he said that he will go with me. and he actually went. So the boat, two of us, uh, we went to Kilimanjaro and we actually didn't prepare well. We did a little bit of running, um, some, you know, uh, gym, et cetera, but we've never been higher than like 5, 000 feet uh, you know the mountain high so the Kilimanjaro is like 6 000 meters, which is like 18 000 feet, I believe for you know, it's a big difference. so I do have to tell you that I really felt that I had a huge I mean like height disease, you know, I felt terrible but that you know Actually allowed me to fight with myself and to overcome my weaknesses, I can tell.
And during the, during the whole journey, as I can tell you that the whole journey was amazing. Like from the preparation, you know, actually reading about Kilimanjaro, what should we take when it comes to medications? What should we take when it comes to, clothing? And then, you know, all the, like, packing and going there, all the way through meeting the people, on the way to Kilimanjaro, and then, day by day, you know, just like, step by step, just, getting closer and closer.
And also, it took us seven days, to go up and down, go up four and a half days, and then, the rest was down. We also decided to disconnect totally, so we didn't use any phones, we didn't use anything. So it was just ourselves and the mountain. And I would like to really recommend that for everybody, because it really lets you to, I mean, to clean up your brain and to be with yourself.
To, um, just think about, uh, your life, think about yourself. And, uh, I loved the whole experience, and actually when I was there on the top, I was like, wow, Weronika, you did it. So now if you climbed Kilimanjaro, you can overcome everything. Uh, so I really recommend that. It was simply amazing.
[00:05:19] Pat Kothe: So those of us in the U S have spent any time in Colorado, Rocky or the Rocky mountains, those peaks are 13, 14, 000 feet. So Kilimanjaro is 18, 000. Um, Tell me a little bit about the terrain. Are there paths? Are you, um, you know, going up steep terrain? What, what's the terrain like?
[00:05:44] Weronika Michaluk: Also, you know, it differs. It depends a day. Every day is different. So you start, the first day is like the best because you walk in shorts, in like a T shirt, you just walk in in the jungle and It's really warm. It's really nice. Then the second day it starts getting, cold. Then, you know, you start walking on the on the rocks and sometimes, you know, we had to really like climb and I was even sometimes scared to look down because the, it was like huge valley below us, you know, like huge really.
So we were like just like climbing on the, on the rocks and, and going like, you know, just going forward. And, so that was, that was also difficult. And the thing is that, you know, every day it was getting colder. So we were also sleeping in a tent, in a sleeping bags and in a, in a tent, so it was like minus 15 and 20, Celsius, which I believe minus 20 Celsius is equal to minus 20 Fahrenheit as well.
So it was like below freezing a lot. Which also was for me, it was really big deal because I love being in a warm weather. As you can tell, I live in Barcelona, so it's really warm. And there, I really had to also fight with myself to sleep, in a very cold weather and then to walk in a very cold weather.
Every day was different when it comes to terrain. But only the first day was, like, really easy, but then, it was getting harder and harder. And the last day, actually, we can say that it was the night, because we decided to actually climb on the top of the Kilimanjaro, for the sunrise.
So, in order to get there for the sunrise, you have to start at midnight. So that was the very last, you know, phase, I can tell. So, we actually woke up at 11 p. m. Yes, we went to bed like at 6 p. m., I guess. We woke up at 11 p. m., we got ready, and we started, the climb at midnight. It was then, negative 30 Celsius, and it was super windy.
Was like pitch dark. We had only like little things to, um, to see, where can we walk, and we could only see like really maybe three, four feet in front of us, nothing else. So it was like really pitch dark. And that climb was super steep. Like, really, sometimes we had to really grab, you know, the rocks and try to get there.
Sometimes the terrain was, like, better, so we were just, like, walking flat. So it really differed at the very end. But the thing that it was, you know, from midnight till 6 a. m., was very cold, very dark, and not so comfortable for you. Uh, that was like the hardest, the really the hardest part. And the other thing that was not helping was when you were climbing up, we saw people going down, uh, with, um, uh, oxygen masks.
We saw people that were like, um, we can say, um, vegetables, because, you know, there is like... So, there's really little oxygen there and you have to walk very slowly when you are walking really slowly. My heart was pumping like crazy and sometimes people just walk too fast and then they, their body just, you know, cannot, uh, stand it anymore.
So then they have to put on the oxygen mask. And when they do. So. They, they, they are carried down, by the other people and they go to the hospital. So we've seen that as well and that didn't help us, but we made it, we made it and we celebrated on the top, so it was, was really nice.
[00:09:23] Pat Kothe: So you were not part of a group. It was just the two of you going.
[00:09:27] Weronika Michaluk: Just the two of us, yes, just the two of us and the guide, of course,
[00:09:30] Pat Kothe: Oh, you did have a guide. Okay.
[00:09:31] Weronika Michaluk: Yeah, you have to have a guide now, yes, you have to.
[00:09:34] Pat Kothe: and, is there permitting, you'd have to have a permit to do it as well, they limit the amount of people on the trails.
[00:09:40] Weronika Michaluk: Yes, because, you sleep in the camps and, and then in the camps you have like specific, you know, you have limited space. So every person that goes into Kilimanjaro climbs Kilimanjaro must get, the pass. A specific permit. Yes.
[00:09:55] Pat Kothe: So a life, life changing, life altering experience.
[00:10:02] Weronika Michaluk: Yes. I mean, definitely. And the next actually, on the list is, uh, just Machu Pichu, the little one. But after that we want to do Annapurna, which is, uh, very high. So, let's see when we do this.
[00:10:16] Pat Kothe: So looking back on your first major, major journey there, what would you have done differently?
[00:10:24] Weronika Michaluk: Oh, what would I have done differently? I would have prepared better when it comes to heights Because I got you know, as I mentioned I got really sick on the last stage Because my body was not used to heights. So what I would do definitely is just to go for hikes, you know, for like 10, 000 feet, maybe 12, 000 feet.
Something not as high as Kilimanjaro, but something that would help my body to accommodate. Which I didn't do, so I paid my bill. Lesson.
[00:10:59] Pat Kothe: Altitude sickness is something that a lot of people go through. lack of oxygen, oxygen, headache, nausea. Is that kind of what you went through?
[00:11:07] Weronika Michaluk: Yeah. Terrible headache. Very high fever. I couldn't move. I was all, like, my body was so swelled, like, I was, like, did I gain, like, 10 pounds, you know, like, climbing up Kilimanjaro? Because I really, had a lot of, I had, like, the, I retained a lot of water, I had a terrible headache, and, and a fever, so it was terrible, but my, my guide, actually, he gave me some,warm water with ginger and then warm water with lime and then he told me to get some ibuprofen and that really helped. So I survived.
[00:11:41] Pat Kothe: So many peopleum, at the top, at the summit, they brought something with them. Did you bring anything with you, as you were climbing?
[00:11:52] Weronika Michaluk: Yes, actually we brought, like, we have, like a little, let's say, teddy bear with us that is just our, between, between a friend, uh, so this and, we, we said that we made it and we always bring it with us for, like, different trips. But I have to tell you there were people that brought champagne, for the top on Kilimanjaro and they opened this up and it just, like, you know, it exploded there, so yeah.
[00:12:16] Pat Kothe: Well, congratulations and good luck on your, uh, on your upcoming journeys. Sounds like it's, uh, it's going to be something else that's going to be an unreal experience too.
[00:12:27] Weronika Michaluk: Thank you so much. Thank you.
[00:12:29] Pat Kothe: Experiencing these highs, I'm sure that software development has some highs, might not be quite as high, but, similar journeys in that preparation, as you said, preparation is something that's really important in software development.
So let's go back for a second and. get into software development. But first, tell me a little bit about how you prepared professionally to get into, software development.
[00:13:00] Weronika Michaluk: Let's start from the beginning, you know, from like my, my journey. I, I actually, when I was little, I wanted to be a medical doctor. But you know, I was like, I was thinking about it and then I was like, I wouldn't be able to stand it like if my patients dies or, you know, if I am not able to help the patient, just from my, my own like personal, let's say, perspective.
And I always loved, physics, maths, computers, so I was like, I have to combine this. So I went to the university and I started studying biomedical engineering. I'm a biomedical engineer by training, and that, you know, allowed me to actually help doctors indirectly through technology so I can help doctors and patients to the technology.
So I graduated from Warsaw University of Technology, biomedical engineer by training and then, I was actually working there as a, as an engineer, hands on engineer, programming, I myself designed and built wireless EKG system, that allows you to, you know, check your EKG at your, at home and then send the data to your, to your doctor, to your physician.
After that, time as an engineer, I moved to South Korea, where I was working in neuroscience department in optogenetic field, that was in Quanzhou in very South of the, of South Korea. Was amazing. And we were actually there working on the research. on this optogenetic field, whether we could, through optogenetics, through the, the, the light, because optogenetics is the, the science about the lights, whether we could actually, improve or bank the sleep, of people.
The research is still ongoing, but, it's promising. So, fingers crossed, the professor and the team there will get some, some new... Good results. So that was, you know, kind of, I call it my nerdy, period of my life because like engineering and research. And after that time I decided to actually extend my knowledge when it comes to business.
So that's when I went to, uh, US and I, started, masters. I did master's in international business at the university of Miami and then an MBA, and I had an amazing experience there because we really could learn from, experts in the fields when it comes to business, healthcare, et cetera.
And that's also when I started my career, as the digital health consultant, um, In the big company called Boston Scientific, big medical device company. And I was there, in charge of Latin America and Caribbean region. So I was there actually in charge of, digitizing the medical device industry, working on software as medical device and other VR, AR applications.
And after that period of time, I moved back to, to Europe, to, to Barcelona, Spain. And that's also how I met, you know, Zach, the CEO of HTD company. And I started my journey here at HTD, Health, where I am currently a Digital Health Principal and a SAMD lead. So I'm in charge of the whole software's medical device department, ensuring that our software is the highest quality, that we have the culture of quality in our, in our company, and that, you know, our teams also know how to follow, the ISO 13485 processes and other regulatory, requirements.
So that's my main focus, right now. And I love what I do.
[00:16:29] Pat Kothe: I'm curious, um, You clearly have a very detailed side of your personality. Software and software development is a very detailed thing, but you also have a very free spirit about you, living in many different cultures, different countries, traveling. How do you view yourself? you've got the detailed side and the free side.
[00:16:54] Weronika Michaluk: Oh yeah, I mean, I, I, you know, I think that I am a bit sophisticated, I always say that, but I have this kind of nerdy, play, like, side of myself, which I really love technology and sometimes, like, even, you know, looking at the code and trying to fix, stuff, but then I'm very social and I love traveling and love learning languages.
Thanks to actually my work, I had to, not had to, but thanks to my work, I speak five and a half languages, which also helps me to when I travel. So even when you go to the conference, for example, kind of my nerdy, you know, side. And I go to, let's say, Brazil, I could speak Portuguese with Brazilian people, which then opens up so many different doors, I can say.
People just open up with you and they are just more willing to chat, to speak. Same in Spain. So I just, I just love it. So I don't know, kind of like a mix of different personalities.
[00:17:54] Pat Kothe: So software as a medical device, obviously there's a tremendous amount of activity around developing different software products and utilizing them, in the medical side. We want to talk, today a little bit about the, the methodologies for developing software. So you're a consultant, you work with companies who are the original equipment, manufacturer.
But let's dig into a little bit about the methodology on how people develop software. From what I understand, there's two main ways of doing it, a waterfall way and, waterfall methodology and agile methodology. Can you explain what waterfall is? A lot of us have heard the term before, but what is it?
[00:18:39] Weronika Michaluk: Definitely. So, you know, waterfall methodology follows like a linear sequential flow of steps. And actually you can think about it as a waterfall cascading down like one step to the next one. And that's actually, I think why it's called waterfall methodology, because you have to follow the sequential, you know, step by step process.
And you start at the top with like, let's say the conception of the project, you ideate, you create the whole complete plan. And then you, you go through, like conception, initiation, then the analysis, then you do the design, then you do like the whole development, testing, you implement, and then you, maintain the, the software, right?
So it's actually very linear and if you would like to make any changesuh, it costs a lot, because, you know, as if you have the whole project and the whole design, everything ready. And then during the development, you, you say like, well, we didn't think about something, then change, going back, to do the initiation and changing things, can cost a lot.
But of course, if you take into account, for example, building, A building, like construction, right? A waterfall is the way to go, because you should create the complete plan. And in order to build a building, you should, have a, you should follow a waterfall. So I could say that waterfall is good for some... parts of the, let's say for different projects, but maybe not always for the, for the software projects.
[00:20:13] Pat Kothe: Software, outside of medical devices, software started to become, a business 30, 40 years ago. People were still utilizing waterfall methodology. At some point in time, somebody said, Hey, there's, there's gotta be a better way. So let's talk a little bit about Agile and what that is and where it has advantages in software development.
[00:20:34] Weronika Michaluk: Yeah, definitely. So actually Agile, launched in, you know, 2001. So more than 22 years ago and this is the contrary methodology to Waterfall. As Agile actually is very flexible and adaptive and allows you to make changes quickly and, you know, also, react to change quickly.There are like four core values, to, to the Agile, and they are individuals and interactions over processes and tools. Then you have working software over a comprehensive documentation. But I would like to come back to this second point in a second, because like in SAMD, it's very crucial. So we might come back to this. And then the third one is customer collaboration over contract negotiation. In Agile, we always put customer first.
And you want to always understand the customer and provide the highest value. And then the fourth one is responding to change over following a plan. These are like the core values. And then this brings us to, to this Agile methodology, which, which actually, you know, starts, let's say, also in Agile, we have Scrum, right?
So, if you have a Scrum team, the Scrum team are following the Agile methodology starts with like the product vision.
So what we do at HTD, we start with actually discussing the project, the idea, the whole vision with our client. And we write down all the, let's say the requirements and the idea. We'll also, very often, have lots of brainstorming sessions back and forth, to actually, define some, let's say, first, first stages.
But to come back to the Scrum, you gather the requirements, and then you have something which is called Product Backlog. And the Product Backlog is actually, kind of a list of different features of tasks that should be done in order to create the product. So then also, the product owner, which is actually managing the whole, the whole, uh, Scrum team, he is in, he, she is in charge of prioritizing product backlog.
So actually ensuring that most important tasks are on the top of the product backlog and will be, you know, prioritized and will be managed first. So then, what Scrum teams, also follow is like they work in sprints. So sprints are kind of like iterations, and they can be two weeks long, four weeks long.
We normally follow at HTD two weeks long sprints, and, each sprint actually begins with a planning, planning meeting. And during this planning meeting, the whole team actually decides what to work on during this two weeks period, based on the priority and also estimated time for the completion. And, you know, also during the sprint, we have a refinement, which is a very important meeting because this is the meeting that is called for the whole team to align on tasks.
So during this meeting, like product owner, explains what is the task about, and then maybe backend or frontend engineers. would ask any questions or would align between each other. so that is during the, during the sprint. And also, during sprint, what we call is called like daily stand ups.
It's a short 15 minutes meeting, that aim is to actually align between the team to, to talk about what have you done yesterday? What are you going to do today? Do you have any, any issues, any obstacles, you know, to overcome? If not, let's, let's move forward. So this is also very good to, to align just between the team members.
And then at the end of the team, of the sprint, we have a meeting called a sprint review. And this meeting is held together actually with the client. And the fun fact is just, Pat, just before our meeting, we had the sprint review with the client that were, went just perfectly. So I just came back from the sprint, um, uh, review, uh, one of the, uh, Scrum meetings.
And, you know, during this meeting, the, the Scrum team presents the work. So we present the work that was done during the iteration. So we present increment. And then the client, gives you feedback. So they can tell you whether they are, happy with the work or not. Whether you should make any changes or not.
So this is very important, actually, meeting that should be held there. And actually, Agile,... because as I mentioned, the client gives you feedback, right? And if there are any, if there is a need to make any changes, thanks to Agile, you just take this feedback, add it, add the changes to the backlog, and then you work on these changes in the next print.
That allows you, you know, to, to actually, you know, react to change quickly. So that's how the agile and scrum, works.
[00:25:22] Pat Kothe: Do you have multiple scrum teams working on a project at the same time?
[00:25:26] Weronika Michaluk: So mainly, you know, we have one scrum team per project, but we do have one, huge, actually project internally at HTD where we have two different scrum teams that work on actually separate, let's say, functionalities, but then we would have to follow probably Nexus.
It's kind of part of the Scrum, but it's just Nexus. It's kind of a methodology that allows you to have just a bigger Scrum team. It's pretty complex. We normally don't do so, but if we have a really huge project that would normally have, let's say, 40 people in the Scrum team, that would not be, you know, let's say optimal as we should not have more that I believe like, you know, 15 people in the scrum team and 15 it's already, a lot to manage.
[00:26:15] Pat Kothe: Talked about waterfall being finish one step, move to the next step, move to the next step, move to the next step. Agile, you can move around in the different steps, you're not waiting for one to end before you go to the next one.
[00:26:32] Weronika Michaluk: Yes, because in agile, every sprint planning corresponds to one stage in waterfall, which is concept initiation, right? And planning. So in the waterfall, you do it once. And then you just go to designs and development. But in Agile, you plan every two weeks or every four weeks, depending, of course, on the, whether you follow two week sprints or four week sprints.
So you actually plan every single, sprint. In Waterfall, you review the whole work, after the completion of the, of the project. In Agile, you review the work after completion of each sprint, which also allows you to make, changes. The same with designs. What we do actually at HTD, we also have sprint designs.
Design team is always one sprint ahead of, at least one sprint ahead of, development team. And that will also allow us, you know, to adapt to changes. Because what we do is like the, the design team works on designs. Then we do the review with the client of the designs.
If we have approval of the designs, then we take it for the development. If the client doesn't approve designs, then, you know, we have to make changes. And after the changes and approval, then we start the, the development. So that's how it differs, the waterfall and the Agile.
[00:27:51] Pat Kothe: So when a project starts, people have an idea what the project is going to be. They also have an idea on the functionality and the timeline and the cost and managing the timeline and the cost. And one of the issues that's always happened with any project is scope creep. And when you do a waterfall, you've got, you've got a plan and you're going to execute against that plan.
Agile, as you said, you're Asking for feedback, making changes, and you have to manage that scope creep as well. From your experience, Agile versus Waterfall, how does, how do they differ in terms of scope creep, in terms of timelines, and also feature development or best product coming out at the end?
[00:28:41] Weronika Michaluk: I love Agile because it gives you lots of flexibility. So when it comes to timeline, you know, for example, if we have a timeline set with the client, But for example, within four months, we have to develop MVP. And in the beginning, we have high level features. During the project, let's say the mid, mid part of the project, we see that we will not be able to deliver all of the features or all of the detailed features within this time frame.
So then it's about managing expectations and discussion with the, with the client. So then we can either extend the timeline or we can cut down on the scope. So it really depends on the client. Sometimes it's also possible to add one or two team members and then the cost will be higher because you know, you have this triangle with the time, the quality and the cost.
And. Always one, uh, you know,
[00:29:36] Pat Kothe: Pick two of the three.
[00:29:38] Weronika Michaluk: yes, exactly. Pick two of the three. Exactly. So then it's really the conversation with the client. What is the priority? And we, based on the experience also, what we do is we always, start with the highest priority features and we always have the lowest priority features at the end of the backlog.
So for example,if you would like to create a patient portal application that, you know, must have registration, must have login, must have, for example, video conferencing tool. So these are the features that we'll work on in the very beginning. But then if, for example, like gamification or additional notification is just kind of nice to have feature, then we add it, to the bottom of the backlog.
And then it's, you know, we will not, let's say, lose a lot if you will not develop that for the MVP, but we can develop that for post MVP. And we actually follow, you know, before starting development, what we do is we do the discovery phase, which is actually, meant for us to really understand the whole concept and idea of the project to the client.
And then to also... map, we fo you can follow like Moscow, methodology, which is like must have, could have, nice to have, features. And then we map these. And then based on that, we then prioritize, the backlog.
[00:30:57] Pat Kothe: So medical device software is underneath regulatory, bodies, and regulation. is there any difference between waterfall and, and agile methodologies when it comes to regulation?
[00:31:11] Weronika Michaluk: Oh, definitely. Yes. And this is a very big topic,Pat because lots of people, think like... When you speak, when you talk regulatory, you know, when you talk about regulatory, it's like you have to follow Waterfall. You cannot do Agile as Agile, you know, says that the documentation is not important, right?
What I, what I mentioned that they say it's like working software over comprehensive documentation, but actually, Agile doesn't say without any documentation, but Agile just says, let's create documentation that is necessary for us. So what we've also done, with HTD, we developed our internal, we call it compliant Agile process, and it's actually compliant with ISO 13485, with IEC 62304, with ISO 14971.
So these are the standards for medical devices, for the software lifecycle, and for the risk management. So to give you the example, for IEC 62304, Clause 5. They say they, they kind of follow the linear process. They say that, during software design and development, you have to have development planning, requirement analysis, architectural design, detailed design.
You have to implement units. You have to test the units. You have to integrate the system and then test it. And then release. So it's kind of, it's like very, waterfall. But the standard doesn't say you have to do them once and done. The standard just says you have to have them. you know, you have to kind of fulfill all of the requirements.
So, what we do actually in, in HTD, we break it down. What we do is, like, if you start with the, like, the big pro the project, right? You have the whole project, and then you create a high level plan for the whole project. So you fulfill the first requirement. Then you have to create very high level architectural design.
To know what are you gonna do? Are you gonna use AWS? Maybe you're gonna do different cloud, you know, providers. Are you gonna do, you know, specific, you know, data isolation, etc? So this is of course important for us. So this is the big project. Then we break it down into releases, into software, release.
And then also we plan for every release. And then we also create more specific architectural design, a unit implementation plan for each release, which then breaks down into our sprints. So our sprint, you know, one, different sprints, multiple sprints create one release, and multiple releases create project.
So if you, if you think about, you know, now, The sprint planning, and then if you think about, for example, if you, if you work, if you have the whole team during sprint planning, you then can plan during, writing down, down acceptance criteria for the user story. That is just part of the feature in the backlog.
You can write down the development planning, which is the, the requirement from IEC 62304. So actually, it's all about thinking how can you take all of these requirements that is, that are in the linear process, kind of way and break it down into smaller parts and ensure that you can just implement in your, Agile. process. To give you another example, the standard requires you to do unit test integration test and system test. So what we do, we create design verification plan, which is like the test plan for the whole project. And then before every sprint our tester creates specific design verification plan for specific, sprint during the sprint, they create a testing protocol and after the sprint, they create a sprint, like design verification report. And we do that before, during, and after every single sprint. And after the whole project, we do regression testing, which is like the overall design verification test.
And we then, you know, summarize all of the, design verification reports that were done during every single sprint. I know there's a lot, that I was like kind of talking about because it's pretty complex. But I would recommend for our, listeners to maybe take a look at TIR45, which is done by Ami.
It's a very nice book I can say about how to actually Implement Agile in the regulatory world.
[00:35:58] Pat Kothe: So, you've got different, different companies that you're providing services for. And it may be a medical device company, and their methodology is, is a waterfall methodology for their hardware products, for catheters or whatever type of hardware product and now they're coming in and bringing in a software product and you're using a different methodology in that development, but that company, you're not, you as a consultant are not, bringing that product to the FDA.
The company is bringing the product to the FDA. So meshing your work, your quality system, your, your methodology with that company's methodology, has to be clear. Tell me a little bit about, how you manage, as a consultant, how you manage, your development methodology inside, the OEM's, uh, methodology.
[00:36:53] Weronika Michaluk: Great question. Great question, Pat. So actually it depends on the client because we had the clients that wanted us to work within their quality management system. So then actually we had to, you know, first, understand their quality management system and discuss it. Sometimes also we had a situation where, after discussions, they actually agreed that, our approach is correct.
So, they even agreed to make, to make changes. Sometimes we have clients, for example, startups, they come to us, they don't even know what is quality management system, so they really need help with even setting up the quality management system. So what we can offer is we can even help them to set up quality management system from scratch.
And, we can also, you know, provide them with like the complete, design history file and complete, device master record for them so that then they will be able just to take it with their QMS as well, like we create and then, you know, a file for the whether clearance or the approval. But we also partner with some regulatory consultants and then we can just guide, you know, the company from like really Zero to hero, I always say, like from the very beginning, like setting up the QMS design development all the way to regulatory approval.
[00:38:18] Pat Kothe: You do have your own QMS, you work, you work within it, and it is compliant with regulation.
[00:38:26] Weronika Michaluk: Yes, it is. We do have our own QMS and we also use. EQMS, you know, the electronic management system, as we want to, as a software company, we want to also automate the processes and also make sure that, we don't forget anything. So, through the EQMS, we have very nice kind of like set, guidances, that, you know, if you have a new... team member, for example, that comes to SAMD project, even when after the training in the eQMS, they will just follow the process in the QMS that is set by us. They will be compliant because this QMS, eQMS that we, you know, set up accordingly to our QMS, we'll have specific dates and limitations that will just, you know, ensure that we are, we are compliant.
[00:39:14] Pat Kothe: What else is in your tech stack? What other tools are you utilizing in software development?
[00:39:20] Weronika Michaluk: Yeah. So we are, you know, we are utilizing as we are the software development company and we provide, we are only healthcare focused, which is also very, very important. And we are not only SAMD focused as we are only also developing not regulated, healthcare software, right? So during the development, what we use, we use JIRA as the, you know, as the management and actually JIRA is, used mainly by, by the development team.
You know, to manage the backlog, manage the tasks. And then we also use this EQMS, which is Greenlight Guru. We, integrate JIRA with Greenlight Guru. Then for testing, we use X Ray, which really helps us to automate tests and to ensure full traceability. As you know, traceability is very important in, in the medical device, world.
So these are like, we can say our main tools and then we, of course, our developers use, you know, like Postman, Visual Studio, and some other tools that just help them, to, to develop the software. But this JIRA X Ray and the Greenlight Guru, I can say are the kind of like bread and butter for us.
[00:40:29] Pat Kothe: What are the languages used in software development now?
[00:40:33] Weronika Michaluk: Oh, the languages. So, you know, for example, like React, we, we work a lot of in React, in React Native, Flutter, in Python, as you know, also in Python, the AI is big right now and we have AI, practice and we are developing AI in, in Python. So, we have different, uh, capabilities within our company, but React, Flutter, React Native, Python, Next js, Node. js, um, uh, NET are the ones that we, we are mainly focusing on.
[00:41:08] Pat Kothe: So the company HTD, what types of customers do you have? You said some startups, some large companies. Tell me a little bit about the types of customers, the type of projects that you get involved with.
[00:41:20] Weronika Michaluk: Definitely. So, HTD, we are a technology services company, and we are around now 200 people, and we are 8 years old. Uh, we support different types of organizations from really startups to help them build the MVP build the first, let's say, even proof of concept, and to help them even build the, the, the, you know, QMS, what we just discussed.
All the way to. huge organizations like Johnson Johnson, Takeda Pharmaceuticals, Smith Nephew, a big medical device, company. We also support big, health systems and universities. We work very closely with Boston Children's Hospital. We work very closely, with Rockefeller University Institute, Michigan State University.
So these are like big, big also, universities. Also, we work with, Venture Studios. So Venture Studios is a very interesting, we can say client because through Venture Studios, we actually help startups. We actually help, to build startups from zero to one.
So from like the conception in the initiation all the way to, you know, to the MVP and then beyond.
[00:42:28] Pat Kothe: Interesting. The Venture Studio model, is an interesting model as well. Are you working as a vendor within the studio or a support to people within the studio?
[00:42:40] Weronika Michaluk: We always call each other partners. So we are development partner. So this is like, we are, the development partners. So if there is a venture studio that is, kind of thinking about creating, a startup, they come to us, uh, with the CEO of the, or let's say, of this, startup. And we discuss the idea and we, tell them about, our idea about this project, what would be the approach, what would be the timeline, et cetera, et cetera.
And then they, you know, kind of like, let's say make the decision, whether we, go together. So it's not like, they have to like the CEO of, let's say the startup must go with us, but it's just kind of the, the partnership. So we are the preferred, partner of some of the Venture Studios and, that's how we just, collaborate with, with the new startups.
[00:43:25] Pat Kothe: So the types of projects that you're involved with, are these long term, years long projects, or are these short term projects? I'm sure it's different, but in general, what type of projects are you involved with?
[00:43:38] Weronika Michaluk: Oh yeah. So, you answered the question. It depends. But, we have, for example, the client that we've been working with for the last five years and we've built, many, many different actually projects with them. it's a, it's a big, you know, actually health system. So we are then developing, uh, with them, uh, like we are supporting their accelerator program and innovation, hub.
Very often we, when the entrepreneurs and startups come to you, you work on a short term, projects, which is like building the MVP for two, six months, and then it depends. Very often we, then we build the MVP, then after launch, the, the founders come back to us and then we build post MVP, together with them, right?
So it really depends on the maturity and of the, and on the stage of the organization.
[00:44:31] Pat Kothe: If a company is considering going outside to do development, software development, what type of criteria should they be looking at when they're evaluating different potential partners to do that development with them?
[00:44:47] Weronika Michaluk: You know, great question. So I would definitely recommend just checking what is their experience, right? What are their past projects that they've been working on in the past? Do they have any subject matter experts when it comes to specific field? Because it's not about just like software development company.
It depends if you are looking for, for example, EHR integration, you should really focus on whether that specific company has experience in there and has any, developers that have done this. If you are looking for some, some deep software's medical device, definitely, check whether the company knows the process, knows what are the regulatory requirements, whether the company has any, again, subject matter experts within the field, right? I believe that every project and every client is different and you really have to focus on what is the most important for you and then look for that experience and that expertise in the specific, company. So I would not say look for the cheaper vendor, the cheapest one, because it's not the path to success, but look for the vendor, the partner, that would have the expertise that you don't have. And together you will, you know, compliment each other, let's say, and you will build a successful project.
[00:46:05] Pat Kothe: Veronica is such an interesting and accomplished person. I enjoyed learning from an expert in software development and also enjoyed hearing about her adventures. A few of my takeaways. First of all, the Agile method. And it's not just for software development. It's best known for software development, but it can actually be utilized in any area of the business.
So what I do is encourage you to learn more about it and see if it makes sense to adopt it for your area. Whether you're in marketing, sales, finance, or wherever you are.
Secondly, when she talked about working with companies who may not use the Agile method in other parts of their development cycle. So they work with their customers to figure out what works best for them.
Exposing them to this new method, oftentimes, this option is adopted by the company because it's overall better. So the takeaway is be open to listening to experts and embrace change if it's best, if it's something that you don't currently do, but it's better, adopt it.. Finally, Mount Kilimanjaro. I really enjoyed hearing that, uh, and spending the first, uh, 10 minutes or so of, of this conversation.
She was really being aggressive and, uh, willing to learn, uh, aggressive in, in what she was doing, but willing to learn. Uh, about how to do it and reflecting back and, and putting that learning to, to work, uh, in, in future things that she's going to do. So hearing that and hearing her story about adventure and challenging herself, doing something bold and developing those memories had me thinking about us and thinking about me and also you.
What's your Mount Kilimanjaro? What's my Mount Kilimanjaro? What memories am I making today, that I can look back on and say, boy, that was something big. That was something bold. That was something aggressive. That was something that I learned from. That's a memory that I'm making.
Thank you for listening. Make sure you get episodes downloaded to your device automatically by liking or subscribing to the Mastering Medical Device Podcast wherever you get your podcasts. Also, please spread the word and tell a friend or two to listen to the Mastering Medical Device Podcast as interviews like today's can help you become a more effective medical device leader.
Work hard, be kind.
