- For most practitioners, compliance is easy because they don’t have to care about it. This burden is taken over by the process, because compliance is already built in. Practitioners just have to adhere to a defined process.
- Processes can be beautiful and really support and accelerate an agile transformation.
- Processes will be adjusted on an instance level, so programs without hardware or functional safety, may have very different flavors of the very same process.
Meet your Expert
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 of working experience with 50+ publications.
- SAFe SPC since 2011, Agile (XP) since 1999.
- Happy father and married to a wonderful woman.
What does PI Planning look like in a regulated environment? How can such a complex task be performed in order to be compliant and still being agile? Find out while we are showcasing some examples of ASPICE compliant PI Planning.
Episode length: 6:36
Transcript with pictures:
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 in most 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 RASCI 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, it’s 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 see in this picture is, that for each major step of Pi planning we have activity and we know who is the responsible person for it’s 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 we resolve 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 what ASPICE 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 good will 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!
In the next episode you should get more infos about regulatory requirements: Regulatory requirements are our friends 4/6.
- Trailer – What you will get in this series –
- Compliance & Agile – Most regulatory requirements have a common base.
- Forget compliance, just follow the process – Relieve practitioners from the burden of compliance
- Regulatory requirements are our friends – Treat regulatory requirements as our friends and use them, to improve the processes.
- How to enhance SAFe for regulated environments – We showcase a concept and some examples.
- Lessons Learned – How to avoid bear traps and learn from each other.