Innovation and efficiency have reached new heights and their combination 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?
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 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 cyberphysical 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. 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 a governance to steer such endeavors.
In the recently published study ‘State of Agile’ by Version One in April 2017, we find that the Scaled Agile Framework (SAFe) has overtaken all other scaling agile methods and remains at the top for existing frameworks in practice.
With regard to agile maturity, the report states that only 18% think that they have reached ahigh competency with agile practices across the organization. The remaining 80% of the companies are aware that they have to improve.
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. We need more responsive development method to address 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. The better we understanding how things work, the more easily we can apply them to our unique context. SAFe principles apply on each level of the framework to realize complex cyberphysical 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.
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 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.
On the other hand, the foundation of Agile, the Agile Manifesto, identifies four fundamental value propositions:
- Individuals and interactions over Processes and tools.
- Working software over Comprehensive documentation.
- Customer collaboration over Contract negotiation.
- 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 will 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 through the experience of our product, Applied SAFe, to use agile in large scale and to fulfill 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 management. 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 with regard to solution to be built
- Perform processes and procedures in accordance with their intended use
- Build quality practices into 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 subsequent blogs, we will lay out how these issues can be addressed. Based on our experience derived from Applied SAFe and together with our valued partners, we present the following lessons learned with scaled agile applications or mappings to various reference models.
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 addressed: 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 fulfill 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 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.
The goal should be be to find real issues rather than to just achieve approval; i.e. 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 have 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 signiicantly.
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 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!
Most 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 fulfill those requirements. A 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. live time & 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 absolutely 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 to define 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, please visit www.appliedSAFe.com. In subsequent blogs, the author will discuss in depth how to address the specific topics discussed above.
The author, Peter Pedross, can be reached at firstname.lastname@example.org. Twitter: @AppliedSAFE