Are you incredibly wary when a software team mentions working in an Agile or Lean-Agile way when you’re looking for medical device software development companies?
Maybe with Lean-Agile, the “Lean” part of that name doesn’t leave you untrusting or concerned. It’s the “Agile” part that does.
It’s understandable. Poorly executed Agile or fake Agile hasn’t exactly helped with its reputation.
But when you bring your medical device software project to Bluefruit Software, we will work on it using our Lean-Agile principles and practices. Every single medical device or equipment client project we’ve worked on has involved Lean-Agile processes.
So, if you’re on the fence about Lean-Agile for embedded software development in medical, let us take you through some of the most common myths and fears we hear from people when they talk with us.
First up, here’s what Bluefruit Software means by Lean-Agile.
What is Lean-Agile software development?
Lean-Agile software development takes Lean software development principles, which are adapted from the widely used Lean principles of manufacturing, to underpin Agile practices. We like to think of this mix as:
The three layers of Lean-Agile.
What do these layers involve?
Principles from Lean software development, as proposed by Mary and Tom Poppendieck, that borrow from Lean manufacturing. In software, there are seven core principles:
- Eliminating waste
- Amplifying learning
- Empowering the team
- Deciding as late as possible
- Delivering as fast as possible
- Building integrity in
- Seeing the whole.
That’s the top layer. The middle layer involves:
Project management practices from Agile that help to fulfil the needs of Lean-Agile’s principles. The kind of practices that help with this include:
- Working in sprints
- Holding retrospectives and reviews
- Using effort points on tasks
- Having user stories
- And more.
Then there’s the bottom layer. Here you’ll find:
Technical practices used during coding and testing. Practices like:
- Test-Driven Development (TDD) using unit tests
- Behaviour-Driven Development (BDD) using Gherkin
- Frequent/continuous integration
- Living documentation and more.
All these technical practices focus on aiding the creation of high-quality and safe software while stopping waste and enabling adaptation that supports continuous improvement.
You can read more about the ins and outs of Lean-Agile in our in-depth article that explains what Lean-Agile is and how it can help you avoid project waste.
Fears and myths of Lean-Agile software development for medical devices
Have you ever heard or thought of any of these myths or fears about Agile? If you have, you’re not alone.
These are ones we’ve encountered from people working on projects within the medical space who have reached out to Bluefruit for support with outsourced software development and testing.
Myth: “Agile doesn’t work with compliance for medical device software.”
You’ve likely thought this if you’re reading this post. And while maybe in Agile’s early days, this might have been true, in the past 20 years, Agile has come a long way.
One way that Agile and Lean-Agile software teams can ensure they work in a way that meshes with compliance? Following AAMI TIR45, which offers guidance on how to work in an Agile way on medical device software projects. Using the guidelines in TIR45, it’s possible to develop and test medical equipment software in a way that meets the IEC62304 standard.
In our post on the use of Lean-Agile in medical device software development, we explained that Lean-Agile paired with TIR45 aids with:
- Documenting test evidence
How? Paul Massey, Bluefruit Founder and Director, looks at how Lean-Agile, TIR45, automated testing and living documentation work together in this webinar:
Fear: “This other company said, ‘Oh yeah, we’re Agile,’ but I’m not sure.”
Some people believe they’ve encountered an Agile software development team before, only to experience a mirage of Agile in their project or be let off lightly with an unconvincing sales spiel. Sound familiar?
Three signs that you’re not dealing with an actual Agile (or Lean-Agile) software team include:
- Reassurances that the team is Agile followed by saying, “But some of our customers aren’t Agile, so we work in a Waterfall way for them.”
- Why this is bad: For a genuinely Agile or Lean-Agile team, it’s impossible for the team to not work in that way. For instance, Bluefruit’s whole way of working falls apart if we try to go Waterfall (as in work in a way that follows software maturity models like Capability Maturity Model Integration).
- If you speak to individuals within the team, and some say, “We claim we’re Agile, but I don’t understand what Agile is and what we mean by calling ourselves Agile.”
- Why this is bad: A crucial part of being Agile or Lean-Agile is that the whole team (if not the whole business) know and understand working in this way.
- During a project, the first step a team takes is to capture all of the requirements and finalise the requirements document.
- Why this is bad: That involves predicting things and making those requirements near sacrosanct so that handling new information (learning) and adapting over the course of a project becomes impossible, increasing the risk of waste and loss of quality.
Should you encounter these warning signs and are specifically interested in working with an Agile or Lean-Agile team: look elsewhere.
Myth: “Agile just lets developers do whatever they want!”
Hold up. Agile ways of working don’t create a free-for-all. Added with Lean principles, as you find in Lean-Agile, there is a massive emphasis on ensuring software sprints always deliver business value to the customer. So, you and your software team work together to make sure the user stories being worked on meet your priorities each sprint.
In fact, effective project planning is a critical way to ensure high-quality software development happens.
Agile also emphasises justifying what is happening and doing so from the start.
It’s necessary to make sure there’s consensus for:
- The creation of documentation
- Changes to processes
- Changes to documentation
- Using learning from the project during the project.
It is common on non-medical projects to have lots of fluidity around processes, but like with documentation, Agile says have just enough. And it’s the same with barriers to change: have just enough, and in the case of medical, just enough to be compliant.
What does this look like? The client and software team discuss changes, the processes involved during discussion automatically allowing for the creation of traceable documentation (retrospectives, for instance) on why something is happening.
Myth: “It doesn’t fit with our processes. And we can’t change our processes.”
A software development plan is a cornerstone document in any medical equipment software project. Describing how you:
- And more.
It’s also integrated with many other documents.
The software development plan might make it feel like change is impossible.
But it all depends on how you write it.
If you’re already working in a Waterfall way, as in using a software maturity model like Capability Maturity Model Integration (CMMI), you might be saying right now: we can’t make changes to our processes!
Yet the fifth level of CMMI asks teams to “focus on process improvement”:
Your software development plan should enable optimising if you’re truly working at level five. How the plan is written needs to supports this.
The wording in a Lean-Agile based software development plan enables this continual focus on process improvement because Lean-Agile needs us to have continuous improvement and to do it from the start. It’s not something that happens after everything else, as explained in TIR45:
“Stimulate ownership of continuous process improvement through RETROSPECTIVEs and reflections.”
Source: AAMI TIR45:2012, p. 46.
Processes can and should adapt and change.
Fear: “We’ve outsourced to an Agile company before, and it went badly.”
We’re sorry to hear you’ve previously experienced what was likely “Agile done badly”.
Were there any of the warning signs we described earlier in this post? Those would certainly indicate a team that isn’t working in an Agile way, let alone Lean-Agile.
Reflecting on that experience, you might want to ask yourself:
“Were there gaps in their Agile processes?”
What might these gaps look like? If your experience didn’t include activities and processes that support:
- Continuous improvement
- Open and frequent communication
- Prioritisation of user stories
- Changing requirements
- Frequent software delivery
- Reflection at regular intervals
Then what you experienced was Agile done poorly. The above points reflect the principles outlined in The Agile Manifesto.
But the most significant sign that it was Agile done badly is whether challenges and issues with development were easily identified and quickly resolved, or not.
The processes and practices you can use with an Agile or Lean-Agile approach to software and product development give you and your software team the methods and tools to identify, assess and handle problems in projects as soon as they arise.
Still, Agile and Lean-Agile can’t work miracles if there is poor communication between stakeholders and software teams. Everyone needs to openly communicate and work together to solve problems as they arise.
Lean-Agile and Agile can work with software development for medical devices
We hope that you’ve learned how being Agile and Lean-Agile can benefit you and your projects in reading through this blog post.
If you’d like to learn more about how working in a Lean-Agile way can benefit your software and product development—helping you innovate and cut waste while improving quality and reducing risk—take a read through our Lean-Agile Series of blogs.
And if you’re interested in working with us on your product, why not arrange a call with our team?
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more