There is no doubt that using Scrum in developing software for use in regulated industries such as healthcare, law or finances, presents a serious challenge. That being said, there are just too many myths surrounding this which discourage teams from even trying it.
In reality, it is perfectly possible to use Scrum to deliver software for regulated industries. In fact, working in Scrum can actually help teams deliver better software and answer the specific requirements posed by those industries.
Today, we will be taking a closer look at the many myths that discourage software development teams from using Scrum when working on products for regulated industries.
Myth #1 - Scrum Does Not Accommodate for Required Documentation
Heavily regulated industries are notorious for the amount of documentation that accompanies absolutely everything that is being done in those industries, including developing software. Various regulatory bodies often require stupendously detailed documentation which describes every decision made in the development process.
It is not that difficult to see why many people see this as incompatible with Scrum, an Agile framework. After all, the Agile Manifesto clearly states:
Working software over comprehensive documentation
And we are definitely talking comprehensive documentation here. Comprehensive with a capital C.
The thing is that the Agile Manifesto does not prohibit comprehensive documentation if the occasion calls for it:
while there is value in the items on the right, we value the items on the left more.
Moreover, in the Scrum Guide, the word documentation appears precisely zero times. Scrum is not bothered with documentation at all. It is a framework that easily accommodates different practices and if the standard industry practices require comprehensive documentation, Scrum will accommodate it.
We do not have to be happy about it, but it should not prevent us from using Scrum for regulated environment projects that call for documentation.
Handling documentation simply becomes a Product Backlog item and having all proper documentation becomes a part of the Definition of Done for features, iterations and releases.
If done the right way, this approach actually makes for safer and less taxing handling of documentation.
Myth #2 - Regulatory Requirements Are a Bad Fit for Scrum
There are two main reasons as to why this is a commonly believed myth.
For one, many people see the traditional, phased approach as more suited for handling various types of regulatory requirements - traceability, legal compliance, established practice-related ones, data formatting-related ones, etc.
To many people, the traditional approach feels safer when handling such critical requirements, with traditional requirement formats and concretely structured ways of incorporating them throughout the product development lifecycle phases.
In reality, Scrum actually features a number of mechanisms that make it perfect for handling regulatory requirements in an efficient, stable and safe manner.
First of all, there is the Product Backlog where regulatory requirements are added, usually towards the very top so that the entire team can discuss them and clear up everything. Moreover, if new requirements arise, the Product Backlog can easily be amended to include them without having to backtrack through phases.
Product Backlog item descriptions and the Definition of Done criteria also perfectly accommodate all the interactions, documentation and testing that ensure the compliance of different features and releases. Once again, this helps respond to any future changes to the regulatory requirements.
Finally, there is the Product Owner who is responsible for the Product Backlog and accepting work as Done, i.e. compliant with the requirements. This is definitely a better solution than having different people responsible for implementing regulatory requirements across various phases of product development.
Another reason is that a big part of the Scrum community is allergic to the idea of requirements being part of Scrum and Agile, in general. They believe that requirements (even non-functional ones) need to be replaced by user-oriented concepts such as benefits and outcomes.
This is a fantastic article on this subject. Despite the fact this article is written from a pronounced anti-requirements standpoint, you will notice that it provides an exception to this ‘no requirements’ rule - compliance requirements. This is because the author understands the realities of developing software for regulated industries.
Unfortunately, some people, in their quest for Agile purity, do not make the distinction and put compliance requirements in the same basket with other non-functional requirements.
Myth #3 - Scrum is too Iterative for Stakeholder Involvement
One of the most pervasive myths surrounding the use of Scrum for developing software for regulated industries is that its iterative nature is not best suited for stakeholder involvement.
The sheer number the perceived inaccessibility of both the companies’ own (legal team) and external (various clerks, officials and regulators) stakeholders makes some people believe it would be impossible to get them all involved in a product that is developed iteratively.
According to this view, it is far easier to get the stakeholders on board only at the very start and the end of the project.
We are not saying it is easy to engage all the necessary external stakeholders throughout an iterative product lifecycle, but it is far from impossible.
For one, we have to remember that stakeholders are just people who might be perfectly willing to get involved, especially if they know this will lead to a better product.
Moreover, Scrum entails mechanisms that are specially designed for stakeholder engagement. For example, there is the Sprint Review which presents the opportunity for stakeholders to see how the product is coming along and give their feedback. The Product Owner also serves as a single point of contact which facilitates and simplifies stakeholder involvement, as opposed to having various people responsible for this across traditional development phases.
Myth #4 - Scrum’s Frequent Iterative Releases don’t Work for Regulated Industries
In some people’s view, Scrum is always and invariably about releasing increments as often as possible, often after every Sprint. It is understandable why people with such a dogmatic view would see Scrum as incompatible with developing software used in regulated industries.
The software for such industries usually features complex interdependencies that are made even more sensitive by regulatory requirements. Also, signing off on relatively tiny increments by everyone responsible would be too time-consuming, making the whole exercise too costly.
In other words, intensive release cadences simply do not work for regulated industries. The myth actually holds up so far.
The only problem with this is that Scrum doesn’t say anything about actually releasing increments regularly.
Scrum speaks of "Done", useable, and potentially releasable product Increment[s].
In Scrum, the product or its increments are released when it makes sense. In the case of regulated industries, this will simply be done less often than in some other cases, while the project will still benefit from having a product in a releasable state, developed incrementally.
Regulated industries undoubtedly do pose a challenge for the Scrum framework and teams that work in it. That being said, the two are far from irreconcilable. In fact, with a bit of work, Scrum can actually be used to develop superior software for use in regulated industries, especially with a scrum board tool you can trust.