To satisfy compliance standards, organizations must demonstrate that their systems meet their intended purpose without causing harm. They must also have the objective evidence required to prove conformance to those standards. An organization’s Quality Management System defines policies, processes, and procedures that ensure development activities and outcomes comply with all relevant regulations, and provide the artifacts required to prove it. One of the not so obvious things is that SAFe has already built inmost of the ‘hooks’ needed for compliance with such high assurance systems.

One of the big misconceptions in agile and regulated environments is that it so hard to understand, that it basically is almost impossible to describe.  But what we find a lot of times is that people are going for a treasure hunt!

They're looking for their information in various web pages, documents, standard operating procedures and so forth. But what you really want is to have one common place where you kind can find your relevant information at the very right point in time. What are the specific artifacts to be produced, with, guidelines, practices, tools and even a RASIC of defined roles.

If you have such a Lean QMS in place, compliance gets much easier. What we almost can say to to most practitioners in the endeavors of SAFe is: Forget about compliance! What we really want is that you follow the  defined process, and by doing so you will be automatically compliant…
Common, how does such a thing look like?

You need to have define processes, its responsible roles, clear activities with outcomes and deliverables. Possible practices indicated, tools, guidelines at your finger tip.
So let me show you here one picture of Pi planning in Applied SAFe:

What we seeing this picture is, that for each major step of Pi planning we have activity and we know who is the responsible person for its deliverables and outcomes.
What we are doing in PI planning is to gather all involved people together we are doing all the best to think about what the problem is and how can were solve it.

What are the top ten features to be built? What’s the business context, the vision and the intentional architecture? What are the important cornerstones we have to deal with? What are the dependencies to other systems.

If we take now some of the requirements of a ASPICE we will immediately see that these are already a lot of things, what ASPICE ask us to do as well!

ASPICE wants to see that we establish a common understanding and that we ‘define the scope of work’. That's exactly what we are doing! Let’s have look at whatASPICE wants us to have. A feasible plan. Remember, in PI Planning we are all together and plan together, we even commit ourselves to such a plan. How goodwill such a plan be? I guess, I've never seen such a feasible plan as a plan out of PI Planning. And if you do that with a good tool, even better. We have some optional mentions of tools such as the PI Planning App also built-in.

Anther good example is the team breakouts: ASPCIE wants work has been estimated and that there is a feasible plan according to capacity.Sounds familiar? What are you doing in the team breakouts? You are estimating your stories, you put them together and you have a very good understanding of what you will do and what your feasibility looks like. If you can prove that you have followed this process by having a commitment, by having PI Objectives as a base for a predictability measure and you know which features you want to implement in the next PI phase for this, based on real Business Value? With these things in place, we have a very good standing, and if you have made it explicit, it will fulfill almost all the requirements of regulated environments. Because SAFe has the hooks for it already built in and we just made it explicit!

‍