How Agile Quality Practices Improve Outcomes for Healthcare Products

Written by
Date published
February 10, 2021
a patient holds a mobile phone

At Rangle, we do quality differently. Our practice is built on the notion of shifting quality to the left—that is, moving quality from it’s traditional place as the last-step-in-product-development- before-release, to the beginning of the delivery pipeline, being a part of all steps in the process. This has major benefits for digital products of all kinds, but it can really move the needle for healthcare companies.

diagram showing the phases of the delivery pipeline

I sat down with Melike Candemir, a Senior Agile Quality Engineer at Rangle, to get an in-depth look at how our quality methods have had big impacts for healthcare clients. As a healthcare expert, Mel has a deep understanding of how quality and agility improves business outcomes in this vertical.

Question: How is quality different at Rangle?

Mel: As a biomedical engineer, I have experience working in a number of different medical device companies. The first thing that comes to my mind is that Rangle is more agile. This allows our quality team to have eyes everywhere in the product development pipeline, which improves product outcomes significantly. Shifting quality left means that there’s quality assessment at every step of the process. For healthcare clients specifically, when quality has visibility in all places, and at all stages, it ensures traceability for regulatory requirements. This is incredibly significant in the regulatory process.

I would also say that our quality team adds something different than others because we ask what’s missing at every stage of the process. Because we have this unparalleled visibility into the whole workflow, we can do everything possible to save time in the development phase. Before design is implemented, we look at acceptance criteria from a different point of view. What’s missing from these criteria? Are there any vague requirements? Anything that’s not testable? Asking these questions—and making sure to get adequate answers—saves so much time in the later stages of product development.

Q: How do we co-create a quality process with our clients?

Mel: When I started working with one of our current healthcare clients, they were primarily focused on regression testing as the main function of their quality team. The whole Rangle team focused on making their processes more agile–We included the Agile Quality Analyst (AQA) role in the two week sprints, confirmed what the client needed from a quality aspect, and then ensured the quality process was well-defined in each sprint. Then we supported their quality team in setting up automations to make testing run more smoothly, and shared our test cases with them.

The most important thing was creating traceability for compliance. Establishing a relationship with the Requirements Engineering team, we ensured that we knew as much as possible about their compliance and regulatory requirements, so we could deliver the documentation and support they needed–without scrambling to put this all together at the end of the product development process. With Rangle’s agile processes, we can deliver these documents simultaneously and efficiently as these changes or updates of the requirements are being implemented.

With all our contributions, the quality process, development, and the product were changed for the better.

Q: How do good quality processes support better experiences for patients and healthcare providers using our clients’ products?

Mel: The most obvious answer is that they keep the digital products functioning properly. After we started working with our healthcare client, our quality processes made it so that there were no app crashes for a long time. There were no deal breakers or obvious bugs that made it to the app and therefore, to the user.

One thing that I am proud of is our improvements to data safety. We were able to make a lot of upgrades to how user data is handled in the app. There were also major performance improvements, and we can confidently say that the performance of the app is the best it’s ever been with the developments that were done in the past year and a half.

And unlike a lot of other quality practices, we also do design QA. As our design team creates user flows and goes through the process of user acceptance testing, we’re there, too—checking to ensure the flow works, suggesting enhancements, and facilitating the handoff between design and development.

When developers are building features, though they have their own unit and integration testing that allows them to check their work, it’s easy to miss how they can change the user flow and impact the end user experience. But quality looks at testing from the user’s point of view, so that the original intention of the design team is preserved.

I like to say that quality is the glue between the developers, designers and the client. Shifting quality to the left allows this glue to be meaningful.

Q: Trust is so essential in this process. Can you talk about how quality builds the trust that makes that glue?

Mel: Because quality can be a checkbox at the end of the process in a lot of organizations, it’s difficult for the QA team to build trust with their cross-functional colleagues. Before we became a trusted partner with the client I currently consult for, when I or another AQA would propose a change or addition, the Scrum Master or Product Owner would check the suggestion and possibly add it to the backlog, or to the stories that we were working on at the time. Now, AQA can add directly to requirements. We’ve established the trust so that they know our judgment is always sound.

One way I worked on this trust was by keeping track of the backlog. I knew our client was trying to reduce the number of bugs in their backlog, but I also knew that some bugs were already fixed, often through making other feature improvements or fixes. I started bringing this up in daily meetings, and making time to review the bugs and backlog often. Not only did this help meet the goal of reducing the number of backlogged bugs, but my proactivity allowed me to become the owner of the backlog and bug fixes. I started going to the biweekly review meetings to report on the progress, which helped improve our partnership. I also got access to the program implementation meetings for the first time. This gave me increased visibility so that I wasn’t just writing and closing bugs, but could plan for the future to address issues.

Q: I’ve heard you say before that QA can be a black box in some organizations. Can you explain what you mean by that?

Mel: When an organization is siloed, the broken communication means that teams don’t know how to get what they need from each other. Part of our commitment to agility as Ranglers is looking for ways to break down those silos.

For example, after a few sprints and product iterations, I knew the Requirements Engineering team previously had trouble securing documentation from product teams. Knowing that screenshots of the user interface were required for Software Interface Specifications (SIS) documentation, I started to take these screenshots and share them with that department any time new UIs were made, or anytime there was an update to the screens or user flow. I included the relevant description of all screens and user flow for each. This saved a lot of time and rework for the Requirements Engineering department, and took almost no extra time for me, since I had to review and test all those screens anyway.

If I didn't have these insights into what the Requirements Engineering team needed, and didn’t have access to them, I wouldn’t have been able to do this time-saving work and share it with them. I also found out that the marketing department needed similar material for their promotion, including screenshots of the application in each of the different languages it supports. I removed the barriers for both teams to access this documentation, so that they could get their work done faster.

Agility isn’t just for the product or development team—it should improve everyone’s workflow in the whole organization. This is what quality means.

Q: That’s really impactful. Any other big wins for this client?

I would say the overall improvements to their quality process. We regularly update the quality strategy with changes to test approaches. There’s our smoke tests, for example. Whenever we notice a big bug, or there’s a new feature that affects code on a large scale, I immediately update the smoke test procedure to account for these changes, and include relevant testing for it. The process is very dynamic in comparison to traditional quality processes. I would say it’s a mature process.

Also, if I find that during a test, what I’m testing for impacts something else, I’ll address it in the current sprint instead of adding it to the backlog. This is part of being agile, and it removes a ton of rework—not to mention improving the product quality for our client.

Q: What do you think would be different about the products our client teams produce if our quality team wasn’t involved?

Mel: We assure quality with the processes that the quality team implemented as mentioned above. At Rangle, quality enables agility. This means more feedback, more often, with shorter feedback loops. Moving quality to the left in the product process improves outcomes for everyone: It improves work of design and development, reduces rework significantly, improves client understanding, supports regulatory compliance, and provides a reliable and high quality product to the end user. Everybody wins.


See what Ranglers are writing about on our blog