Products get more complex, more disciplines are involved and the release cycles get shorter and shorter. Where in the past, projects were started in order to develop the products, this is not the case anymore. In a heavily project-oriented organisation, people are spread out to different projects, leaving only a fraction of their time per project. This causes a lot of overhead due to task switching. Additionally, every project has its own interpretation of the development process and how to stay compliant to the quality management system (QMS). This implies additional overhead, as everyone needs to figure out how the project is organised. Not only is work capacity wasted but emotional capacity is drained as well, which leads to frustrated employees and less output.
A standard, flow-based framework like SAFe, Flight Level Kanban, LeSS or any combination thereof can help to ease the pain. With this, first of all the focus can be shifted – from project-oriented to product-oriented long-lasting teams. Furthermore, if introduced correctly, QMS compliance is secured from the beginning. Not only is the product developed incrementally but also the necessary documentation.
Challenges with agile transformation in MedTech
The main challenge in today’s VUCA world is the fast development and release cycle. Products need to be updated constantly, not only to keep pace with the market but also to be able to update with the latest bug fixes. The challenges here are manifold. To name but a few: the market request needs to be aligned, which then needs to be implemented and re-verified or maybe even re-validated with all the necessary documentation, risk managers need to do their assessments, QA/RA needs to keep up with the needed reviews and last but not least the notified body needs to be able to give the clearance for the product.
With these many challenges, it seems to be nearly impossible here to gain some speed, increase the flow, offer this to the customer sooner and reduce the time to market. Nevertheless, all these challenges also imply some chances.
First and foremost, if all acknowledge a common goal, namely to provide a first-class, high-quality, safe and effective product, then we can work on the different views and focal points and figure out how to reach this common goal.
All of the various disciplines should work closely together. Product management should be able to provide the vision and the roadmap for the products, in order to have a proper frontloading of the pipeline. In return, they need to get the transparency of the current state of development, need to be involved in defining and figuring out the right functionality and be there to find the right scope to release. Development needs to commit to the delivery in their increments/iterations/due dates, show transparently what they are working on and regularly demo their achievements. Risk needs to be involved constantly, to assess the risks, define the right countermeasures and update the accordant documentation. And QA/RA shall be there to support and coach the teams on how to stay compliant and figure out together with the teams how to not only secure the safety and effectiveness of the product but also how the collaboration model can be enriched in order to have compliance built in. And all of this in a state of flow. At every step, everybody knows exactly whom to involve in order to minimise the risk of proceeding.
Ideally also the notified body is involved in defining the collaboration process with the manufacturer (the current pandemic showed that if the manufacturers and the notified body collaborate closely, the approval process can be dramatically shortened) to ease the review process and through this reduce the time to market.
By defining the right transition stages on the various flight levels, compliance can be secured with a proper set of DoRs and DoDs.
Why should a company in MedTech (or any other domain) solicit the support of a consultancy firm?
As the saying goes, “a prophet has no honour in his own country”; a view from the outside is far more accepted than from the inside. Surely internal change agents are needed right from the start to further promote and anchor this in the organization, but an external Expert can provide guidance in the right direction and may be able to solve ambiguities within the company. Also, based on the broad experience of these Experts gained from various customers and domains, a best-of-breed approach can be found.
All our coaches, before becoming Agile Coaches, had been working in agile teams in various roles, so they are acting out of real case experience (“eat your own dog food”), not only based on written knowledge. They know the problems of developers and their working space, have gained experience as classical project leaders, or have given support in the elicitation of requirements.
Additionally we have a long track record in developing according to MedTech standards. We know what it is like to work in a regulated area. Also here a mind shift is needed to accept that documentation needs to be delivered along the process. Despite this, we see the added value.
Our track record of introducing a flow-based collaboration model for various companies in various sizes is an added plus, where we have demonstrated our broad knowledge in the domain as well as on agile methodologies, principles and values!
 VUCA stands for volatility, uncertainty, complexity and ambiguity
 DoR: Definition of Ready
 DoD: Definition of Done