Key takeaways
- Although a lot of hooks are already built into Applied SAFe, there are still some enhancements to be expected.
- Special roles need to be made explicit.
- Milestones and special artefacts need to be built in.
- A lot of behavior is built into ‘Definitions of Done’ and ‘Definitions of Readiness’
- Three different types of enhancements for SAFe.
- We showcase some examples.
Meet your Expert
Peter Pedross 
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.
Teaser
Even though SAFe has almost all he looks needed for regulated environments some requirements ask you to have very special roles in place milestones in place and specific artifacts to be produced a lot of this behavior can be steered with definitions of done and definition of readiness but it’s also necessary to add think about how you can deal with specific roles needed explicitly and special milestones which people want to see built into into the process as well!
Episode length: 6:08
Transcript with pictures:
There are many different types off enhancement for safe and I could speak to you several days about what it’s all possible and maybe need it but what I would like to show you here today very briefly is three typical kind of enhancements for SAFe, first is for roles second is for phases and milestones, a third example is for tailoring different behavior.
We see here a portfolio safe configuration of safe and if we work in an ISL 2626 two relevant environment we have one requirement which says hey a project manager shall be appointed at the initiation of a product development concerning the item. Of course we don’t want to have that role and, you know we are coming from agile, so we may wanna give that responsibility in her environment to the product manager. This is very natural.
The product manager will have special skills in ISO 26262, so he knows that he needs to have a safety manager. And now the interpretation game starts we could say: OK this is a very special role we want to have that as a role in shared services for example. Another decision could be that, when we need that many times, that we split up those responsibilities of a safety manager to the triade of product manager, release train engineer and system architect.
Once this is done, the safety manager can delegate task to persons that possess the required skills, competences and qualifications. So, the agile teams! YEAH, back in agile business!
Another example I would like to talk to you about is faces and milestones. We see here the standard phases and milestones of applied SAFe, where we plan something, do something, learn and adapt. The classic ‘Plan, do, check, act’ circle, as already mentioned by our beloved Mr. Demming.
So let’s take some typical milestones as we know them from functional safety. For example technical safety concept, solution verification, solution validation, safety case updated, and so forth. We take now these milestones and think about what we want to do with them. Shall we add them to our circle? Do we want to do for example solution validation still as a part of solution demo as we have it defined in SAFe? If yes, then we would just alter or change that milestone. Or, we make the decision to make this milestone explicit and add it to our existing milestones. Again this is a design position for our processes and this needs to be done once and then it’s fine, you don’t have to decide that again and again in every single endeavor.
The third example I wanted to show you is that we talk about dynamic parts in processes. Just imagine again you’re under functional safety relevance and you want to make sure, that you only do the minimal necessary amount of work. So let’s imagine that you build a solution, where nobody can be injured, this kind of solution will be tested differently then a solution where in case of a fatal injury it’s life threatening. In the latter case you will make much much more in validation and verification it’s called the same but in a different manner. And if you can adjust to that you can reduce waste in your processes as well and that’s what you want: as a learning organization, as an employee, as an architect, and as a budget responsible person. And of course the customer!
So you build something into the process where each endeavor can answer for themselves by themselves easily and this is something, that is even foreseen in functional safety in the regulated requirements it already says death to life cycle may be tailored.
So let’s use this freedom let’s play with it!
The last episode of the series: Lessons Learned 6/6.
All episodes:
- 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.
