Back to Shows
Where are regulatory requirements coming from? What kind of questions need to be addressed in order to successfully develop solutions in a lean-agile manner within a regulated environment?
If you think about compliance, we should think about what does that really mean. One possibility is to talk about some examples.
I guess you're all aware of Boeing 737. People died because some of those planes crashed. Sometimes it's just about things where people don't die directly but a lot of people are affected by such manner and probably the impact on society in a big and we have tons of examples. Financial crashes, Diesel-Scandal. So, let’s have a look at what is so typically wanted in regulated environments.
Let’s take some bullets from quality and let’s put them along with some bullets from the Agile Manifesto. At a 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.
The world on the left works 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 (on the right side) 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
But what do this two sides have in common? They both want to make sure, that we build good systems!
In a world of ASPICE and ISO 26262, the V-Model is strongly associated with development.
In the traditional V model understanding we see that there is everything is written down first. Then we build it up from the basis until we see the final result. What we try now is to narrow ideation/specification very close to verification so that we can have fast feedback. Fast flow depends on building quality into our development system through testing at multiple levels. So we generate tests for everything—Features, Stories, and code—ideally before the item is created. There are several patterns and methods for that. Test-Driven Development and so forth.
Most large scale complex environments are dealing with varying levels of criticality, from safety-critical to security-critical. Such areas are mostly regulated and it is necessary to comply with formal standards, regulations, directives and guidance. There is a plethora of regulations and standards which apply across different regulated domains. FDA, ASPICE, ISO 26262 etc.
Luckily, most of these regulations ask for some common things. And if you go o a Meta-Level.
They want to see that…
If you have good answers to all these bullet points, you will get through with all assessments.
I believe that the basic need is ‘Trust’.
And one thing we do to answer these questions is that we build a quality management system.
Something like you know from the past with different lifecycles. We see phases, milestones as we used in the past. But this time we do the very same in a lean agile manner we. We build a solution and the compliance incrementally. We organize for value and compliance. We continuously verify and validates and so forth. We do more or less the same things but organized in a very different manner. People don’t get smarter over night just because they work in an agile manner, it’s how you organize your work.
I promised to you to talk about PI Planning, so let’s take it from here with the next episode!
In this series Peter Pedross will showcase why and how compliance and scaled agility can really help each other. On the example of PI Planning, he will show you real world examples, concepts and experiences based on industries such as Automotive, Aerospace, Medical Device, Defense and Finance.
Beginner / Intermediate
March 3, 2022
CEO & Founder PEDCO AG, Chief Methodologist Applied SAFe
Creator of the product Applied SAFe. Started to program for money at the age of 14. Ex-professional sportsman with a passion for software and a knack in engineering. 30+ years working experience with 50+ publications. SAFe SPC since 2011, Agile (XP) since 1999. Happy father and married to a wonderful woman.
Head of Product, SPC5
Silvio is a certified SAFe® Program Consultant and as Head of Product at Rentouch responsible for the innovation of piplanning.io.
Business and Agile Leadership Coach
Shane is a business focused change agent, specialising in enterprise level digital Lean/Agile transformations. More than 17 years consulting experience across a variety of industries from pharma to banking Shane is a specialist when it comes to context and culture-specific transformations.
Ian J Franks
SAFe® 5 Program Consultant & RTE
Ian has a deep knowledge of Scrum, Kanban and Scaled Agile, and 30 years’ experience in international IT Transformation Programs. He is a successful PO, SM & RTE and as a Consultant/Trainer he coaches his clients develop a strong Agile Mindset that delivers real change and measurable improvements.