Agile Risk Management
By Rebecca Davis, SAFe Fellow, Director of Lean-Agile Practices
Agile and lean principles, values, and mindset apply to every area of a business, with all being better off for applying them.
As I reflect on my varied career path, I’m thankful to have participated as a team leader, team member, and senior leader across an unusually diverse set of teams. This includes legal teams, HR teams, risk management teams, hardware teams, experience design teams, software and electrical engineering teams, healthcare provider teams, compliance teams, executive teams, and a few more. I am excited to share here some of my experiences implementing agile practices and mindset within Medical Device Risk Management. Hopefully, these experiences will help others in the community consider some techniques and attributes to bring about their change, perhaps in an area that is not the norm.
Medical device risk managers enable an organization building regulated devices to do so in such a way that ensures their products cause no harm. Risk management practices involve identifying, understanding, controlling, and preventing failures that can result in hazards when people use medical devices. Manufacturers are expected to identify possible hazards associated with design in both normal and fault conditions. Such devices include ICU monitors and software that tracks vitals back to a central nursing station.
At this organization, risk managers resided within the regulatory department. When I joined the company cross-functional Agile teams were in existence and included product management, nursing, engineering (software and hardware), and quality as members. The regulatory area, which included regulatory, compliance, end-to-end testing, usability engineering, and risk management specialists, existed as a department that was removed in collaboration as well as in organizational structure from the agile teams. This had created a rift between what was being built and the safety and efficacy of the products, seen in frustration within the employees as well as in the amount of rework needed before the organization could release a quality product.
Leadership was ready for a solution.
Establishing a new role
After discussing the situation with the VPs of Regulatory, Engineering, and HR, we created a new role in the organization of Risk Master, with me as the first. The intent was to use my Scrum Master skills of facilitation, my passion for safe products, and outcome-driven discussions back into the process. I had a fascination for learning more about the regulatory space and had built a reputation for helping agile teams overcome strong differences amongst themselves and others. This was my chance to create true connectivity, supported by an already strong executive team.
We started with shadowing. Regulatory members including risk management, compliance leads, regulatory leads, and quality engineering began shadowing Scrum Masters. This created empathy among them, as well as highlighted varying styles to bring energy to conversations, and techniques for creating equal talk time. Allowing them to observe many personalities in action enabled the discovery of techniques that worked for each person. This created a pull to behave in more healthy ways rather than a push.
We created workshops, bringing nurses together with regulatory and engineering to talk through known dangers of historic medical devices like electronic toothbrushes that broke off and choked people. Storytelling from the field created the culture that everyone who worked here was first and foremost focused on the safety of the lives our products affected. This was very different from a previous culture of excellence focused at the role level, which was not necessarily connected to outcomes. Additionally, I began watching relevant movies with the team. There are some amazing examples of quality interactive risk management in movies and shows like From the Earth to the Moon, Ford vs Ferrari, and Apollo 13. The key is to get creative and not to be afraid of having a little fun. People want to be amazing together. Give them the environment.
Organizing Around Value
We began organizing further around end-to-end value delivery and accountability. We already had nurses directly in our agile teams which was a great start. We added to each solution a dedicated role from regulatory, compliance, security, and end-to-end testing. This created deeper knowledge of each medical device being built, moving away from reviewing documentation and towards collective ownership. To not break the connection that the regulatory department required to keep up with changing laws around the world, we launched action-focused Communities of Practice (COPs). We were living the details within https://www.scaledagileframework.com/agile-teams/.
Team members also stayed current, stable, and connected through innovative Gemba. As one example, the organization worked with nurses and hospitals to rotate through agile teams for 6 months and then regional health centers for 6 months. This benefited the local hospitals as well as our organization, and teams could still normalize due to having 2 total nurses trading out over time. Teams also were able to fly to customer sites as a team throughout the year to observe solutions in action and hear directly from users, thereafter having enjoyable, connected meals to discuss what was observed.
Involved, focused lean-agile leadership is one of the key needs in any organization. My first taste of amazingly engaged agile thinking leadership was at this same Medical Device company. The senior leadership of this organization met every new hire to the organization on their first day, with the same concerted message. “Everyone here on your first day and every day hereafter will be faced with decisions. Make them. Communicate with those around you, choose a path, and go forth. We will be here if and when you need it, we all have years of experience, and our doors are open. You are empowered.” Every employee truly could ask any leader for help any time and receive it, yet never feel micromanaged in any way. My two closest leaders, the VP of Engineering and the VP of Regulatory worked in tandem to help me lead and grow.
This growth took multiple forms. I worked with both VPs to review current team-level metrics, which at first were extremely output-focused with no storyline within them towards outcomes. We drafted a new trial, working alongside Scrum Masters to create metric storylines discussed as part of each iteration demo. Metrics included were cumulative flows, recent defects or complaints, and the current number of patients/hospitals utilizing the products. This also included satisfaction rates iteration over iteration. Upon demoing the current iteration of the product, the Scrum Master would tell a story of the metrics. This created such engagement that the sales team started on occasion flying hospital staff in to watch and provide feedback.
Leaders gave air cover throughout all this growth and change, allowing me to try almost anything I desired as long as I was able to articulate to them what outcome I hoped to achieve, and was willing to pivot with humility when things didn’t work out. This holds with me to this day. Be bold in what you would like to trial, know your why, and be ready to change and support the greater organization.
I have rarely since been in any environment that felt so connected, produced so many life-saving products, or been so motivated by my work. Having VPs and a CEO who acted together as a team, helping anyone in the full organization as much as they could, treating an individual employee’s desire to move from being a nurse to a future medical device engineer as seriously and with as much care as the first release of a Class 3 Device in the EU. To me, lean-agile leadership is as much about the knowledge of lean practices and agile methodologies, which this team had in spades, as it is about giving every human in the organization the respect, trust, and environment to grow, trial, and communicate.
Collaborative Risk Mitigation
“If the Death Star had been built by agile teams with an agile thinking risk manager, it wouldn’t have blown up.”
— VP of Engineering
Risk management, done in an agile way with agile teams, is one of the most engaging roles out there. In a non-agile environment, I’ve observed risk managers alone at a desk, reviewing requirements documents and filling out pages of reports, row by row of excel cells, rushed to meet the next deadline. Agile risk management, in contrast, is collaborating consistently with the full team to design, build, test, deploy, and support a solution together. We held risk management sessions with the full solution team, usually around 20 total people, once per week. No cyber-physical device is completely bug-free, so the responsibility of the team is to, alongside the risk manager, creatively and methodically think through every possibility in which a potential future solution could cause harm. They then build in functionality to resolve the potential before it can occur. Sound familiar to any TDD/BDD fans out there?
Risk mitigations are converted ultimately into agile stories and managed within the backlog. These safety requirements are decomposed into user stories and demonstrated on cadence. It is key to continue iterating and re-assessing, as a key component of risk is to evaluate if a set of mitigations alongside other new functionality may result in a new risk based on the new combined system In more project or phase gated environments, the system isn’t iterated upon, which results not only in frustration and rework but can result in key missed moments and serious future defects. Usability studies for medical products required by the FDA and ISO are other formal opportunities to iterate towards valuable outcomes.
Back to the quote about the Death Star. If the agile organizations I have participated within had built it, a risk management session may have gone like this:
Risk Leader – We’re here today to chat through a few key risk questions that you were able to consider a bit ahead of arriving. As a reminder of the agenda for today, we’re covering the risk questions related to Fail-Safe and Recovery. Let’s get started.
First question for the team – Is the Death Star susceptible to failure of critical functionality?
Lead Architect – No…well…not really, there’s this one spot where if you shot at it the whole darn thing would blow up, but that won’t happen.
Risk Leader – Ha-ha yea probably not, but let’s run the risk probability matrix against it, as it sounds like if it ever did it would be a big failure.
The team runs a risk probability matrix together, discovering that though the probability is deemed remote, the severity of being blown up does lead to loss of life, data, and goods. The team integrates a mitigating solution immediately.
As articulated here, organizations wishing to increase the engagement of their employees while increasing the value of the products they create can utilize Scaled Agile values and competencies to meet their blend of business goals.
The base values and principles of agility and lean apply to almost any situation. When many brains and experiences are needed to accomplish an outcome, connected iterative collaboration proves most successful. Start with principles, values, and proven team practices, then iterate towards greatness.
If you’re ready to try to move your regulatory and risk area towards agility, here are some final suggestions.
- Invite others in. Everybody. Keep inviting.
- Scrum Masters and RTEs are always excited to help a new or unique-to-them area grow their agile chops. Give them a great opportunity for building more skills and breadth.
- Senior leaders already know it’s key to connect the organization closer. A new idea with some first steps behind it probably won’t get a hard no, unless you can’t state your why and what you are willing to commit to the change. This leads to my last bit.
- Be accountable! Be part of the solution, willing to dig deeper for a bit to make things easier in the future. Change takes effort and energy, be ready and willing to give both.