PI Planning in Regulated Environments 4/6 – Regulatory requirements are our friends

Transcript with pictures:

One thing that we should never forget is that where regulated requirements are coming from.

It’s mostly something that has gone very bad in the past. People died in airplanes crashes. Unsinkable ships sunk. Ever seen a horror movie where the elevator crashes down and people get smashed at the bottom of the of the tunnel? In reality, this never happens because there are some regulations, which forces you to built for the situation that the rope breaks. Nowadays, every elevator is built like that the break themselves as soon as there is no tension on the rope, since decades! But of course, we still see in the movies.

So therefore our concept is that, we see regulatory requirements not something that we just have to full fill, because somebody asked us to do something that we see that they are our natural friends. They are just here to ensure that we didn’t forget about something important which went very bad in the past that’s all.

So let’s take a usual situation we see a lot of times in companies, where they have to comply with some specific requirements so you see many spies what you take whatever reference model you can imagine. If you wanted to it just to fulfill the regulatory requirements and your goal is to get through an assessment you can take the easy path. You make it easy for yourself and you just take the reference model and replicate more or less what is written in the reference model for your process, so you take the process areas with its generic practices base practices and replicate them even the work products all the same. With such a process, you will usually get easy through an assessment. The problem is that you produce something that is more or less produced for the shelf and not for what people really need.

What we think is much better to do is that the company says hey this is the way we want to work. And if you want to work in a scaled agile manner with say for example, you gonna have your epic comeback you see that’s what I want to do. If your work products defined software architecture document configuration management plan do, you have your roles business owner developer testers safety manager whatever you need.

What we do now is we take again those regulatory requirements ISO 26262, AS9100, a spice, or your own reference model.

We take them now as our book of knowledge just to ensure that we didn’t forget something important, we do that in a manner that we map those things again for example this generic practices total of ISO 2626 two, but this time we don’t map it directly, we map it where it may belong to so we called it a referential mapping. So we say just reflected in these two activities what I do, is better for us and some other work products form from a spice is reflected in the software architecture document or the configuration management plan we can go on and on with that, until we think it is good enough. Of course this is harder for the assessment and the department but at the end what we are getting is a process which is still optimized for usage in your company and it’s still agile just enhanced with those things which are really needed for regulated requirements.

And by doing that we are getting compliant processes. Unfortunately this is usually not good enough what most sensors want to see is that you have a defined process which is fulfilling your requirements, but they really want to know if you stick to it we call that process adherence.

Process adherence in our understanding can be proven in many ways one thing which is the most natural for us, is that you just have measures in place measures for example simple metrics where you count the number of artifacts defined in the process are counted. So for example the number of user stories and the number of test cases and if you bring that into a relation you have some derived metrics. Derived metrics are a very good measure of getting an understanding of how things are done. You could say it smells or it doesn’t smell it’s just that it gives you a good indication. For example if you know that in the past, your successful products had in average 5.8 test cases per story and now you have 6.2 then you most likely can expect that it’s well tested.

Remember we are talking about Pi planning. So what are the measures we use in Pi planning predictability. The program predictability measure, which is coming out of the business values achieved at the end these are real measures number of stories implemented burn down charts we have a lot of measures numbers we can point at and that is exactly what do you need in the regulated environments. When you can say, hey we start every three months every Pi. We all plan together we have committed plan to a capacity to stories task in the team backlogs we even commit ourselves to those measures we measure constantly how we did in the last 3 months.

Forever imagined, that somebody wants to see your work breakdown structure, and you can tell them yes everybody knows about it, it’s in our team on program backlog and we have an innovation and planning iteration every three months, where we look back what went good what went bad and where we can improve. How good is that, and I can assure you. If you have made that explicit and you can show that to an assessor, then they will almost kiss your feet!

Without going too much into the details, I would like to show you that a systematic approach is needed and it must be tool supported as well. This is something that is built into Applied SAFe as well and we see here just one screenshot where we map the Pi planning process to ASPICE requirements. Here the ‘Define the scope of work’, as one of the standard requirement is reflected in this process at this, and this activity and with this work product.

And if we don’t find a place where we can map that to, then we have identified a gap, and there is something that we may have to improve, add or to do different. For documentation, we rate every single requirement.

What you usually do, we give access to the assessor to this information as well transparency is your best friend Internet related environments. Don’t hide anything give him all the information you have and use assessors as well to make your things better.

In the next episode we talk about: How to enhancement SAFe for regulated environments 5/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.