Compliance Eats Agile for Lunch

Strategy and culture are among the primary focuses of leaders in their never-ending quest to maintain organizational viability and effectiveness. In short, strategy offers a formal logic for the company’s goals and orients people around them, while culture expresses goals through values and beliefs and guides activity through shared assumptions and group norms.

“Culture eats strategy for breakfast” is a famous quote from legendary management consultant and writer Peter Drucker. As we look into the meaning of this phrase another comes to mind when it comes to agile and compliance. 

Regulated domains exhibit varying levels of criticality, from safety-critical to security-critical. A core characteristic of regulated environments is the necessity to comply with formal standards, regulations, directives and guidance. There is a plethora of regulations and standards which apply across different regulated domains. These are issued by a number of bodies or associations and or region specifics (e.g., ISO, FDA CPT11, IEC62304, ISO 26262 … )

Sadly, because of this. A lot of companies understand it in a way that ‘they’ can’t do agile, because they are in a regulated environement.  So to speak: Compliance eats agile for lunch. 

With this post, we want to stretch some thougts and lay out, why this is in our view, not true at all.
Agile is the natural friend of regulated environments.

Before we dive into this phase and why we think it’s one to remember, let us first explain our thoughts on culture eats strategy for breakfast.

Culture Eats Strategy for Breakfast

Peter Drucker’s quote is often misinterpreted. Strategy – especially in the area of ​​innovation – is important. But if a company’s culture stands in the way of strategy, implementation becomes difficult or impossible. It really implies that you can set whatever course you want for your business, however, it will be your culture, what your people believe and how they behave, that will ultimitely determine what will get lived out in the work. 

Naturally, culture isn’t in about having ‘cool’ workspaces and perks, such as comfy chairs and ping pong tables; it’s about the habits people have formed, how they make decisions, how they respond to challenges, pressure and discomfort, and what they believe is good or bad for success based on what’s been incentivized, rewarded, and reinforced in their workplace. The strategy sets the course, but projects cannot be implemented without the right culture. Conversely, innovation projects influence culture and even strategy: If projects develop in unexpected directions, the strategy is sometimes changed. 

If your company aims to survive in today’s fast-changing business environment, you need to answer these questions:

• Who are you?
• What do you believe in?
• What’s your purpose? Why are you doing what you are doing?

The best innovation strategy is of little use if it is not based on an innovation culture in which goals are committed and uncompromisingly implemented, especially in the age of digitization and digital disruption.

The digital change is demanding and complex and it affects every department in the company. Processes have to be digitized and in some cases completely rethought. Digital services and digital business models have to be developed. Without a culture of innovation , the digital transformation in the company promotes this change is difficult to deal with. Companies need employees who continuously question the existing, develop new ideas , test them and implement them step by step.

This all gets ever more demanding when looking at regulated environments and the regulations that companies need to comply with as they produce the worlds largest and toughest systems.

Compliance Eats Agile for Lunch

A lot of companies think that they can’t do or be Agile because of compliance regulations. But this is absolutely not the case. In our experience, there are good measures that can absolutely make this happen. 

Continually addressing compliance concerns is one of the nine practices of SAFe’s Enterprise Solution Delivery competency. This is explained in detail in the Achieving Regulatory and Industry Standards Compliance with SAFe.

“Enterprises use SAFe to build some of the world’s largest and most important systems, many of which have unacceptable social or economic costs of failure. Some of these high-assurance systems include medical devices, automobiles, avionics, banking and financial services, and aerospace and defense. To protect public safety, these systems are often subject to extensive regulatory or customer oversight and rigorous compliance requirements. 

In addition, many enterprises are subject to other government regulations (examples: Sarbanes-Oxley, HIPAA, ACA, state insurance regulations) that require similar attention and audits to ensure compliance. Historically, organizations operating under such regulations have relied on comprehensive quality management systems (QMS).”

A publication we focus on that is very reputable and true and co-written by Johen Jager, one of our Advisory Board Members, is the ‘Guidance on the use of AGILE practices in the development of medical device software [AAMI TIR45:2012]. It describes that agile principles and development have become an accepted method for developing complex systems and software products. This publicly available Technical Information Report (TIR) by the ‘Association of Advancement of Medical Instrumentation’ (AAMI) lays out the agile manifesto, several practices (e.g. Definition of Done), its application and tailoring in relation to reference models like IEC 62304, ISO 13485, ISO 14971 and ‘FDA CFR, Title 21, Part 820.30’. With this recommendation, I would like to spread the word about scaled agility and agile practices in the development of medical device software.

As PEDCO, we have done countless amounts of webinars and speeches on this topic for you to view. One of our most recent ones was in collaboration with our Partner, CPrime.

At first glance, the practices associated with Lean-Agile and those associated with traditional compliance processes appear to be diametrically opposed, with conflicting goals and disparate communities. Through rigorous, stage-gated activities, the compliance world emphasizes quality, safety, and security to ensure that systems perform their intended purpose without causing harm. Those systems demonstrate adherence to specifications through verification and validation (V&V) activities, and often must provide evidence of adherence to standards through reviews, audits, and sign-offs. To this community, change and variability equal added risk and uncertainty. By contrast, Lean-Agile development strives to discover the ultimate and optimal system iteratively, by creating an environment for learning. Building a working system in frequent, small batches confirms or rejects design hypotheses. Continuous customer/stakeholder collaboration provides fast feedback on decisions and the ability to adapt to new knowledge. Validated learning explores alternatives and helps ensure development creates products that meet the needs of customers. To this community, change and variability provide the ability to create products that excite customers and generate better economic results for the business

Software plays an increasingly important role in regulated environments. The principles of the agile manifesto are known to all Agilist, and although an overarching set of principles for regulated environments does not exist, a number of core issues for software development in regulated environments may be inferred. These issues include quality assurance, safety and security, effectiveness, traceability, and verification and validation.

Quality: Have a managed process

• Systematic and responsive quality management to enable a controlled professional process; in fact establish an agile quality management system.
• Establish Organizational Process Focus: Learn, innovate and improve
• Reliability and correctness of product; e.g. with emergent design

Safety and Security: Transparency in Execution & Continuous Compliance

• Responsive planning and risk mgmt. to mitigate safety risks for users
• Securely protect users from unintentional and malicious misuse

Effectiveness: Manage Process & Solution variations, reduce waste and do exactly what is needed

• Satisfy user needs, and deliver high value to users with high usability
• Do exactly what is needed; in regards to solution to be built
• Perform processes and procedures in accordance with in intended use
• Build quality practices into process as part of flow

Traceability: Ensure process & product compliance

• Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems

Verification and Validation: Engineering based on Principles & Practices

• Embedded throughout the software development process (user requirements specification, functional specification, design specification, code review, unit tests, integration tests, requirements tests)
• Product is specified, designed, built and tested in accordance with regulations

The picture on the right from SAFe® states that also the QMS needs to be Agile as well and in our case, need to take different life cycles into consideration. So, you can expect that the QMS itself will undergo much more changes than in the past. Fortunately, most lifecycles models describe more the organizational aspect of work (how to plan, improve, build, document etc.) but not as much about how something is done. So, you need to show how to synchronize milestones and different cadence of deliveries. A lot of companies have even milestones with numbers! Just imaging, what means milestone #7 if you are new to the company.?

• So you need some design patterns like ‘Interfaces’ to use.

You need to be able to answer what happens with existing documentation. What kind of documentation is expected in regards of solution to be built/changed/maintained?

Regardless of the chosen lifecycle model and the sequence of activities, it is important to ensure that inputs and outputs maintain a consistent state. For example in in FDA terms this is called ‘Design control’. In our view regulatory perspectives align well on the value and importance of DESIGN INPUTs as the basis for the design of systems. Both align on the value and importance of DESIGN OUTPUTs that define the result of the design process in ways that allow the design to be validated. And, finally, both align on the value of VERIFICATION and VALIDATION showing that requirements, and ultimately the user’s expectations, have been satisfied.

This leads to follow-up questions like: What can be different with different Lifecycles? What will be the same? At the end, the documentation might be produced differently using agile principles and practices, but the finished product might not look any different than it did before Agile was introduced. For that, we are using something which we call the ‘Solution Centric Development Approach’.

Lessons Learned

of Scaled Agile applications/mappings to various reference models

Be very clear on what is compliance and what is not.

• Mapping of scaled agility to reference model is surprisingly straight forward, once the lean-agile mindset is understood
• Avoid the bear trap: Compliance elements shall always be mapped to value adding deliverables; instead of work products just produced to fulfill a requirement
• Define clearly the deliverables (min one, and value adding) to each activity
• Having good, automated mechanisms to prove mappings to reference models are needed to reduce discussion time and interpretation games
• Some reference models ask for process- and product-specific requirements -> Scope those requirements for purpose

Compliance is often a ‘negotiation game’

• Don’t forget the human element of stakeholders and appraisers;
  Understanding of ‘How we do compliance’ is often based on a long legacy of deeply engrained expectations and patterns.
• Solution Intent and agile Design control (e.g. Emergent design, skeleton approach) requires that participants really understand what they are doing

Demonstrate compliance in small iterations based on flow’

• Avoid ‘quality depth’ where compliance is ‘built in’ at the end of development.
• Treat audits like a normal system demo
• Focus on outcomes

Separate ‘What shall be done’ from ‘How something is done’

• Model only necessary steps in the process
• Build and rely on heuristics to model the process for usage, e.g.:
  • Each activity has only one responsible role
  • Each activity has always an output
  • Activities with no inputs are very suspect
  • Deliverables (I/O) are usually used more than just once
  • Activities can be performed with different practices
• Ensure that practices can be changed/selected easily by performers

Quality Management System

• Let the QMS be easily accessible and easy to use.
• Promote transparency for each endeavor, Process instantiations need to be specialized in order to reduce waste.
• Allow fast process changes and pilot in appropriate levels.
• Allow process users to perform tailoring themselves in a controlled and easy way. Trust that they will do it good!

Some experience:

• A first mapping of Scaled Agile Frameworks, given the experience on the specific frameworks and the process requirements stated in reference models, are achievable within a lower number of weeks.
• Depending on the attributes of a solution (long term sustainability) or existing documentation the form of ‘DoD’ can vary very much.

Commercial frameworks such as SAFe® or others are an excellent starting point to be applied in the development of high assurance systems.

Scaled Agility can be successfully applied in regulated environments!

Most available frameworks, especially SAFe® have most of the hooks needed for compliance with high assurance systems.

As for a conlusion:

• Regulated requirements have common background!
• Not all regulations are as stringent as others. Tailoring of processes is a must to reflect applicable regulations.
• Regulations do not imply how some thing shall be done. Use given freedom and map agile practices to regulations ->
• Read and understand the regulations! Strive to map existing agile behavior and don’t impose unnecessary work.
• Establish a managed process and Quality Management System (QMS)
• Include executive level in the cultural change.
• Build your own internal team of Lean Agile Center of Excellence (LACE)
• Address live cycle concerns of solutions (e.g. live time)
• Lead the change, it won’t be easy.
• Define governance and responsibilities, also on an Enterprise level
• Exchange your experience with others!

You are not alone!

Read/use available sources; e.g:

• Software Engineering Institute: ‘Scaling Agile Methods for Departments of Defense Program
• CMMI Institute: ‘A Guide to Scrum and CMMI’
  
• TIR45 from AAMI: ‘Agile practices in the development of medical device software’