“Compliance does not foster innovation, trust does. You can’t sustain long-term innovation, for example, in a climate of distrust.” – Stephen Covey
According to Cambridge dictionary, Compliance is “the act of obeying an order, rule, or request.” Most people don’t like to be told what to do. As Daniel Pink said: “Control leads to compliance; autonomy leads to engagement.” Perhaps even worse, people tend to stop thinking when they’re presented with a set of rules. So why compliance? First of all, for a big part, as is with industrial standards and government legislation, you don’t have a choice. Others may be “self-inflicted” like company policies and rules. And, some are part of contractual agreements with a customer based upon. In all cases, these rules can be strict or more lenient. Also, there can be a difference in consequences for no compliance varying from a reprimand to legal persecution or reputation damage. All these factors contribute to determine how to deal with compliance.
Is compliance then all bad? No. A lot of rules are there for a reason. They are in fact lessons learned (ever watched air crash investigation?). Also, even with a lot of care, attention, and good intention, we may forget, underestimate, or just didn’t realize something. Compliance can help prevent this from slipping through and causing serious damage. Better of course is to prevent it from occurring in the first place by building quality in. Another good use is industry standards. It makes it easier to (re)use and integrate parts of others knowing they comply to a standard. Standards can also help drive cost down because of economies of scale, and make it safer and easier to use because of prescribed colors, etc.
Compliance in agile hardware development?
Traditional compliance management is usually not fit for agile. It is based on demonstrating compliance via comprehensive documentation with a traceable link between proof of compliance and the requirement. There’s usually a lot of overhead so making changes is time and resource consuming leading to a resistance to change. Even more so, because the rest of the organization is often not able to handle these small changes, they also resist them. But, because failing compliance late in development can have serious impact (financial, schedule, people), we need to get verification early and often. And lets remember, compliance (e.g. as risk reduction) is value. This means we have to make the compliance system (people/departments, process, tooling) suited for that.
Often, not just the product, but also the development process itself has to comply with certain standards and regulations (like ISO 9000). In this case, it is about making use of interpretation of the regulations. What exactly do we have to comply to? And what freedom do we have in defining how to do that? For anything that you have to do that doesn’t fit your agile way of working, you may consider it an additional delivery. For instance, you can work with stories as the main bearer of requirements for the team and update the official requirements document when finishing the story as part of the Definition of Done.
Below you find several good practices to deal with compliance in agile hardware development.
- First of all, get top level commitment and support for a change of strategy. If they see the need (purpose/mission) for agile hardware and understand what is needed for that (vision, strategy, objectives), it is much more likely to get support for it.
- Decide what to comply to and what not. There are usually a lot of legacy regulations that can be purged. A simple tool to use for this is MoSCoW. Just look at any given rule or directive and determine if it’s a Must have (no arguing, just do it), Should have (let’s see what exactly we need, what’s the risk), Could have (let’s trust our people) or Wont have (good riddance). For this you may need to consult external experts and/or the involved institutions.
- Determine how and how often something needs to be checked. Should it be very strict or is there some room? Should we do it every time something changes or only when certain parts of the system change? Should we check every single instance or may we sample? What is the minimum we can do to satisfy the requirement?
For hardware there is another decision to make. Can we confirm virtually? For instance, using a static model or document (e.g. 3D CAD, or FMEA-document, calculation), or a dynamic model (simulation)? Or, do we actually need to build something? For instance using a mock-up, scaled model, a part of the system or even the whole system? For more information, please read the article Integration & Testing. - Make sure all understand what to comply to and how. Train people. Provide easy accessible information. Have expert help/coaching available when needed. At the same time we should invest in the quality mindset of people (build trust, intrinsic motivation).
- Built quality in. For instance: design verification, automate testing, continuous integration, Model based design, Test Driven Development, refactoring, set-based design).
- Organize people involved in compliance understand the need for agile compliance and are willing and enabled to work in close contact (e.g. via a virtual organization).
- Have a QMS tool suited for agile. It should be easy to make small incremental changes. Think about automated reporting for audits, splitting rules, different levels of compliance.
- Execute compliance in small increments and update the QMS as part of the Definition of Done
- ‘Potentially compliable increment’ – Get features ready for final (official, releasable to market) compliance, but wait until enough has been collected to make it worth the effort.