Lean Quality Management and SAFe

About this webinar:

At first glance, the practices associated with Lean-Agile and those associated with traditional quality management 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. Those systems demonstrate adherence to specifications through verification and validation (V&V) activities, 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.

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?

For example 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 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? In 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.