Innovation and efficiency have reached new heights and the combination of such things into cyber physical systems has led to more complex and interdependent systems. How can we sustain such a pace for the future and continually evolve systems in the shortest possible lead time, especially in the context of regulated environments?

By Peter Pedross, CEO – PEDCO


 The last 10 years have seen the disappearance of well-known products and the arrival of new competitors in the marketplace. Who would have thought in 2007 that Nokia would disappear as one of the great brands in the mobile phone and that Apple would take over the Smart Phone Market almost overnight? With the rise of new competitors such as Uber, Tesla, Airbnb, Netflix, Google, Facebook and others, we witness the rise of competitive pressure in all industries and new levels of innovation and efficiency are required. As we combine such systems into cyber-physical systems with the Internet of Things (IoT), Industrie 4.0, Lean Start-Up, and Agile we move into an increasingly complex and interdependent realm.

Creating agile teams has helped to get where we are today, but we also face limitations as small teams cannot build such complex systems in a timely manner. With this in mind, we also have to face regulatory and organizational environments, which are becoming increasingly demanding. A study by Scott Ambler from Disciplined Agile Delivery (DAD) shows that most agile delivery teams (>65%) are facing compliance requirements, either regulatory and/or organizational. Given this situation, it is clear that we need a strategy and governance to steer such endeavors.

In the recently published study ‘State of Agile’ by Version One in April 2019, we see that with regard to scaling methods and approaches,  the Scaled Agile Framework (SAFe) has overtaken all other scaling agile methods and remains as the number one for existing frameworks in practice. Talking about agile maturity, the report states that only 18% think that they have reached a high competency with agile practices across the organization. The remaining 80% of the companies are aware that they have to improve.

For us, this is a strong indicator that scaling agile is really accelerating. It’s ‘Where the rubber hits the road’, and it’s getting serious because we are building complex and high assurance systems.



Example of a #1 Framework for Scaled Agility – SAFe

The assumptive, one pass, stage-gated, waterfall methods of the past have not scaled to the new challenge. A more responsive development method is needed to take on the demands of the modern technological and cultural landscape. Agile is a major step in that direction. However, Agile was developed for small teams, and by itself, does not scale to the needs of the larger enterprises and the systems they create. That’s where SAFe comes in. It applies the power of Agile, but takes it to the next level by leveraging the more extensive knowledge pools of systems thinking and Lean product development. SAFe provides comprehensive guidance for achieving the benefits of Lean-Agile development at enterprise scale.

When you start with the Framework, it is important to understand the reasons why these approaches work, not just what they are. That’s why SAFe is based on Lean-Agile principles. If you understand why things work, you can more easily apply them to your unique context.  SAFe principles apply on each level of the framework to realize complex cyber-physical systems. The SAFe big picture shows the four levels of SAFe, starting with the team level on the bottom, which is a representation of an agile team, the rest is scaled agility including cadence, alignment, feedback and transparency. Several teams are aligned in a program, which are themselves aligned together with value stream up to portfolio and finally with the strategic themes of an enterprise.

The framework adopts principles like:

  • Take an economic view
  • Apply systems thinking
  • Assume variability; preserve options
  • Build incrementally with fast, integrated learning cycles
  • Base milestones on an objective evaluation of working systems
  • Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  • Decentralize decision-making
  • Apply cadence, synchronize with cross-domain planning
  • Unlock the intrinsic motivation of knowledge workers

Compliance meets Agile Development

In regulated environments, we usually talk about quality, safety, security, efficacy, specifications, milestones, verification and validation, inspections, audits, sign-offs, documented quality management systems, established processes, full traceability, Metrics – defects, requirements coverage, code coverage and more.
The foundation of Agile, the Agile Manifesto, identifies four fundamental value propositions:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over Following a plan.

Agile methods and regulated environments are often seen as fundamentally incompatible. One observed reason is a misinterpretation of the Agile Manifesto. Agile processes follow a logic in a plan-do-check-act (PDCA) cycle, whereby some development is planned and done, the results are inspected, and adaptations are made to improve the process to solve any problems that have arisen. In regulated environments, a defined logic is needed. Thus, the granularity at which development processes are expressed and adapted requires careful tailoring to the specific regulated environment. For example, some will require full traceability, some not.

Regulated domains exhibit varying levels of criticality, from safety-critical to security-critical. A core characteristic of regulated environments is the necessity to comply with formal standards, regulations, directives and guidance. There is a high number of regulations and standards which apply across different regulated domains. These are issued by a number of bodies or associations and/or region specifics (e.g., ISO, FDA CPT11, IEC62304, ISO 26262 …)

Software plays an increasingly important role in regulated environments. The principles of the agile manifesto were identified earlier, and although an overarching set of principles for regulated environments does not exist, a number of core issues for software development in regulated environments may be inferred. These issues include quality assurance, safety and security, effectiveness, traceability, and verification and validation. Taking this into consideration, we see that the various reference models used may differ a lot, but in the end, have a lot of similarities. In our opinion and with the experience of our product Applied SAFe, to use agile in large scale and to fulfil regulatory requirements, companies have to address the following topics:

Quality: Have a managed process

  • Systematic and responsive quality management to enable a controlled professional process; in fact, establish an agile quality management system.
  • Establish Organizational Process Focus: Learn, innovate and improve
  • Reliability and correctness of product; e.g. with emergent design

Safety and Security: Transparency in Execution & Continuous Compliance

  • Responsive planning and risk mgmt. to mitigate safety risks for users
  • Securely protect users from unintentional and malicious misuse

Effectiveness: Manage Process & Solution variations, reduce waste and do exactly what is needed

  • Satisfy user needs, and deliver high value to users with high usability
  • Do exactly what is needed; in regard to the solution to be built
  • Perform processes and procedures in accordance with its intended use
  • Build quality practices into the process as part of the flow

Traceability: Ensure process & product compliance

  • Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems
  • Separation of process requirements and product requirements.

Verification and Validation: Engineering based on Principles & Practices

  • Embedded throughout the software development process (user requirements specification, functional specification, design specification, code review, unit tests, integration tests, requirements tests)
  • Product is specified, designed, built and tested in accordance with regulations

In the following months, we will lay out the details in this blog on how you can address each of the issues listed above. Based on our experience, with our product Applied SAFe and together with our valued partners we present the following lessons learned with scaled agile applications or mappings to various reference models.

Lessons learned

Compliance and Reference Models_5.0Based on experience from several applications of scaled agility in regulated environments, we can say that most regulated requirements have a common background. A mapping of scaled agility to reference model is surprisingly straightforward, once the lean-agile mindset is understood. But there is also a catch which needs to be dealt with: Mapping of compliance elements to value add deliverables! We have seen several times where requirements haven’t been interpreted but taken as simple facts, leading to a demand of unused, unnecessarily created artifacts. For example, in SAFe you are using a PI Planning board were dependencies and features are visualized, teams commit themselves to their own plans; it now would be a waste just to create additionally a Project WBS out of the prioritized items, just to fulfil the requirement of having a project schedule. Because compliance is often a ‘negotiation game’ between stakeholders & appraisers, it is natural that you have to deal with different mindsets and expectations based on past experience. We have also seen, that some reference models ask for a process- and product-specific requirements.  Such requirements must be scoped for purpose and concepts and practices like Solution Intent and Agile Design Control needs to be established.

Compliance is best demonstrated in small iterations. It is a common mistake to ‘build in’ compliance at the end of development; this increases the ‘quality depth’ of a solution. It is far better to treat audits as a normal part of a system demo, e.g. defined as part of a ‘Definition of Done’ of a solution. Rather, the goal should be to find real issues than to just achieve just approval; therefore, to focus on the outcomes of an audit. Automated mechanisms to prove a mapping to a reference model greatly help to reduce discussion time and interpretation games between practitioners and assessors. Commercial frameworks such as SAFe are an excellent starting point to be applied in the development of high assurance systems.

In our experience, a mapping of the Scaled Agile Framework to various requirements of regulated environments and reference models is achievable within a lower number of weeks; once lean-agile principles and reference model has been understood. Depending on the attributes of a solution to be build or on existing documentation of a solution the form of ‘DoD’s can vary significantly.

The quality of a process model is of extreme importance. Only necessary steps should be modelled in the process and the processes need to build and rely on usage heuristics. A success pattern for us is the separation of ‘What shall be done’ from ‘How something is done’. The how something is done is described in practices and it needs to be ensured that practices can easily be changed/selected by performers.

An easily accessible and easy to use Quality Management System (QMS) greatly helps to get people on track with SAFe. A static representation of the process in the form of a wiki might work as a beginning; but for the long run, teams should be enabled to instantiate and customize their process for their endeavor specific requirements in order to reduce waste. A ‘One size fits all’-Process will almost certainly be too heavy and it is not a wise thing to impose unnecessary work on knowledge workers. The organization needed to maintain the QMS (e.g. a ‘Lean-Agile Center of Excellence) also needs to work in an agile manner and enable fast process changes and piloting in the appropriate SAFe-levels. We have learned that it is far better to let the responsible person (e.g. the Release Train Engineer for a program) perform the tailoring of their endeavor specific process in a controlled and easy way. Just trust that they will do it well!


Scaled Agility can be successfully applied in regulated environments!
Available frameworks, especially SAFe, have most of the hooks needed for compliance with high assurance systems.

As regulated requirements have a common background, it becomes possible to build a process model which already has most of the content necessary to fulfil those requirements. Tailoring of processes is a must to reflect applicable regulations as not all regulations are as stringent as others. Usually, the regulations do not imply how something shall be done. Companies should use this given freedom and map agile practices to regulations; agile practices like for example: ‘Build the solution incrementally’, ‘Apply fast learning cycles’, ‘Apply objectives milestones’, ‘Demo frequently; routinely deliver objective progress, product, and process metrics’, ‘Organize around value’, ‘Build quality in’, ‘Apply continuous verification and validation’, ‘Include compliance concerns in Definition of Done’, ‘Solution intent as concept for requirements’,  ‘Inspect & Adapt’, etc.

Build your own internal team of Lean-Agile Center of Excellence (LACE) and establish a managed process and Quality Management System (QMS). Don’t forget to address live cycle concerns of solutions (e.g. lifetime & criticality). It is necessary to read and understand the regulations! Strive to map existing agile behavior and don’t impose unnecessary work in your processes.

Last but not least: It is the absolute key to include the executive level in the cultural change. They are ultimately those responsible and need to lead the change; and it won’t be an easy job. To achieve this, we strongly recommend defining governance and responsibilities, also on an Enterprise level and of course: to exchange your experiences with others!

If you want to learn more about an application of scaled agility in regulated environments, contact us at In the following months, we will detail in this blog how to address the topics discussed above. You can also register for our newsletter here.

Yours sincerely,

​Peter Pedross, CEO & Founder