PI Planning in Regulated Environments 2/6 – Compliance & Agile

Transcript with pictures:

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 disaster. 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 on the left side and let’s put them along with some bullets from the Agile Manifesto on the right side. 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:

• You have somehow described how you want to work, it’s described and known by all practitioners.
• you have transparency in execution and continuous compliance and you can prove that
• you have effective tailored processes. That you don’t have only one size which fits all and each endeavor has its own variation of the defined process.
• You can also ensure and prove that you have compliance for process and product
• and this has been verified with engineering based on principles and practices to fulfill verification and validation needs.
• If you work with agile suppliers, you have also defined how you want to work together with them…

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 and milestones as we used in the past. But this time we do the very same in a lean-agile manner. 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 are 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 you to talk about PI Planning, so let’s take it from here with the next episode: Compliance is easy 3/6.

All episodes:

1. Trailer – What you will get in this series –
2. Compliance & Agile – Most regulatory requirements have a common base.
3. Forget compliance, just follow the process – Relieve practitioners from the burden of compliance
4. Regulatory requirements are our friends – Treat regulatory requirements as our friends and use them, to improve the processes.
5. How to enhance SAFe for regulated environments –  We showcase a concept and some examples.
6. Lessons Learned – How to avoid bear traps and learn from each other.