There are Lean budget guardrails within SAFe’s Lean Portfolio Management modes, but what about guardrails for regulatory compliance? Taking a Lean Governance approach will not only speed up your delivery processes, but will keep you compliant in a regulated environment while ensuring a quality product is delivered to your customers.
Examples of Risks and Controls
Taking examples from the banking and insurance industries, the table below illustrates the types of risks that companies are trying to manage and some controls they have put in place to manage those risks.
SAFe Components For Lean Governance
1. LPM
Lean Portfolio Management addresses the concern that regulatory or compliance risks are not addressed by maintaining a Portfolio Vision and realizing that Vision through Epics. The Epics must travel through the Portfolio Kanban and through the use of Nonfunctional Requirements (NFRs). NFR’s can function as a constraint on the backlog as well as providing guidance on Compliance aspects that must be built into the system. In order to ensure the NFR’s are met, SAFe recommends quality tests, ideally automated, but some regulatory constraints require some to be done manually.
2. Business Owners
Business owners are responsible for several things, one of which is compliance. They help achieve compliance at several points in the process, starting with PI Planning, along with management reviews, participating in System Demos, and participating in Release Management meetings that include testing production releases to ensure quality.
3. System Architects/Engineering
The System Architects/Engineers are critical for ensuring the NFR’s are designed in such a way that they meet regulatory and compliance requirements.
4. Product Management
Product Management is critical in understanding the compliance and regulatory environment in which a company is working. One example is that US FDA 21 CFR 820 regulations state that a “documented software requirements specification (SRS) provides a baseline for both validation and verification.” As a Product Management team, it is critical to know and understand applicable Federal, State, and local requirements as well as those where you may be doing business such as GDPR requirements for data privacy in Europe.
5. Product Owner
The Product owner is responsible for defining Stories and prioritizing the Team Backlog, and so is another person responsible for ensuring that compliance requirements are met. I have seen situations where PO approval of a user story has been accepted by a compliance department because the Jira workflow and Jira permissions only allowed someone in a PO role to approve a user story.
6. System Demos also Ensure Compliance
Because the system demo occurs following every iteration, the system demo gives business owners, system architects, and product managers a chance to see an integrated view of the features under development and gives them an opportunity to provide feedback on development. This feedback is critical to ensure the solutions under development meet the business and compliance requirements.
By utilizing a fast feedback cycle, testing is done much sooner, allowing for defects, incorrect business needs, and compliance concerns to be addressed quickly before they delay the project or are introduced into production. We ensure adherence to compliance requirements through paired programming, code reviews, and coding standards.
7. DevOps
Utilizing DevOps processes for Continuous Integration/Continuous Delivery allows small pieces of code to be tested and delivered quickly, thus minimizing the opportunity that defects get introduced into production.
DevSecOps has sprung out of the DevOps process to emphasize the importance of security in the overall design and to prevent it from being an afterthought. Building security into the system is just as important as building quality in. I would argue that without security, you don’t have quality because you open yourself up to cyber attacks, which put your business and customers at risk.
Compliance Rooted in SAFe
Much of the process overhead introduced into the software development process at large corporations comes from the fear of compliance. Operating out of a place of fear is never a good way to be. In several conversations with Compliance departments across multiple organizations, it has become clear that the process overhead is not a direct result of direction from them, rather from assumptions made within the IT department about what they think compliance wants.
It turns out that what compliance wants is available through SAFe, and it can be done in a much more efficient way with significantly lower overhead simply by following the framework.
SAFe provides guidance that allows us to do the following:
- Verification: We built the solution right
- Validation: We built the right solution
- Compliance: We have evidence that we have done so
It’s that simple. Be flexible in how we meet regulatory requirements. Who better than the team to build quality in, therefore who better than the team to determine how we build compliance in?