Agile is about everywhere. You see it in start ups, larger companies, but also in government, financial or medical context. These are not exactly known for being able to cope with a non-fixed scope of things to be done. And there usually are laws that give regulations on how to do things “properly”.
Seems like the topic is suddenly showing up everywhere: is regulation and agile a contradiction in itself? The Ministry of Test had a “Ask me Anything” (AmA) session on testing in compliance and regulation with Milan Kuveljic when you google “agile regulatory”, you get 14 million hits. Some of them propose “agile disciplined frameworks”, others would add “regulatory service team”. In November, we also had a StugHH Meetup in Hamburg with Torsten Franz on the topic how regulations fit to agile. And agile testing especially.
Generally speaking one could distinguish regulatory requirements roughly into two groups:
- Regulations that need to become part of the product (like special security features)
- Regulations that affect the way how the product is implemented
While the first kind just ends up into the backlog with a potentially high priority, there is more to be discussed about the procedural implications. This discussion needs to be put into context on how the company to be considered is defining its own agile context. Depending on this, roles and responsibilities can be defined. As also pointed out in the AmA, it frequently turns out that the tester in the team or the QA community of practice as a whole gets the responsibility to make sure, that regulations are just considered as another quality standard to be held high.
A Model of Agile Context
Torsten made a suggestion for how to describe different agile contexts. Using of the 6 dimensions he gave I created a spider diagram that can be used to visualize a company’s context. Using the 6 dimensions (clockwise from top left): size of the company, architecture of software and hardware, agile way of working, certified test process, regulatory requirements and management style, I sketched the diagram for some of the companies where Torsten worked before. To understand the drawing, imagine that the further out on the axis you see the mark, the “less likely to be agile” the context is in this dimension.
Looking at the pink line, you see the context of a large bank, with a lot of regulatory requirements, but with an attempt to be as agile as possible. In such a context, the approach to include regulatory requirements into the HOW to do things will need a completely different approach than in a company that is not yet “that agile” (black line).
Extending the Agile Guardrails
Guardrails are basically non-negotiable agreements made across the organization. Guardrails are grounded both in the intention of realizing Business value and in following known principles of agile software development. The purpose of the guardrails is both for alignment and to keep people on the right path. In a highly regulatory context, the reasoning behind the regulations need to become part of the guardrails for the teams. However, a second step needs to be taken to make sure, the laws are followed: There have to be a lot of agreements with the regulatory authorities on which realizations of the rules they would accept. Sometimes there could be a agile approach to reach the same end. As an example, in many regulations you can find the need for a segregation of duties via a 4 eyes principle. Would it be possible to introduce pair programming to fulfil this need? Another example would be the duty to have a tamper proof documentation of tests and their coverage. Do we really need to take screenprints? Or is there a tool to do that for us? What kind of analytics could be taken to show coverage?
What about the Team?
In the end, the team needs to embrace the regulations as a quality feature and not as a blocker. This can be achieved by having the team be part of the process, on how they want to implement the measures that need to be taken, including constructive measures to improve quality and fulfil regulations from the beginning and also including the documentation duties. To achieve this, most importantly they have to understand the purpose of the measure. For this, not only a translation into agile terms but also examples of what should be avoided via the measure need to be given. In some cases, also the exact regulations have to be explained, for example if a certain kind of test is required by regulations.
After having made sure the purpose and goal is understood, the “implementation” of regulations within the team can be left to the responsibility of the team. In a mature agile team trust can then reduce the amount of control as expected when reading regulatory requirements. And as with other quality requirements, the tester often has the best education to keep the focus of the team on these requirements. She will, together with the product owner, foster an atmosphere to keep this agile dimension relevant.