Skip to main content

How do you do Scrum in a regulated environment?

I hear this question often from people in the pharmaceutical branch, air traffic control, banking and finance - any place where strict regulatory compliance is required, and it came up again at my last CSM course.

Regulated environments are complex, both because of the regulations themselves and the high risks associated with the domain being regulated, which means that Scrum is well suited to developing products in this sector. Let's look at Scrum's building blocks, some objections to using Scrum in a regulated environment, and then, using traceability as an example, let's look at how Scrum can be used to address a regulatory requirement.

Building blocks

Scrum is designed for solving complex problems as a team, without defining any domain-specific process. Scrum gives you several building blocks to ensure that your delivered product meets all of the necessary requirements:

  • The Product Backlog, a planning instrument
  • The Definition of Done, an agreement to ensure quality, 
  • The Increment, an additional slice of customer value, integrated into the previously developed slices, and
  • The Product Owner, a role that takes responsibility for the whole product

Scrum does not tell you to write any particular documents, but if creating and maintaining certain documents is required for your project, Scrum gives you the mechanisms to ensure that they get written and maintained properly.

Product Backlog

The Product Backlog is the source of all requirements, both functional and non-functional, for a project. All requirements belong on the backlog. Non-functional requirements should appear high on the backlog, so that the Implementation Team and Product Owner can discuss the implications early in the project. Usually non-functional requirements will get translated into functional requirements and/or items in the definition of done to ensure compliance.

The Product Backlog is ordered. The top most item will be done first. Then the next one, then the next one, etc, until "all" the backlog items have been implemented. (More formally, the Product Owner decides when "all" features have been implemented).

Definition of Done

The definition of Done is simply common understanding among everyone in the project on what it means when you say, 'This feature is done.' So for instance, if a release note must be written for every feature, then writing the release note belongs in the definition of done. A definition of done typically requires proof that the new functionality has been implemented correctly and that all previously implemented functionality is still working correctly.

The goal is that there should be no undone work at the end of sprint. If that goal is achieved -- and teams that achieve it often do so with the help of automated testing -- then the Product Owner can call for a release at least at the end of any sprint (and possibly more often, depending on the teams engineering practices).

The Increment

Under Scrum, teams deliver solutions incrementally, once slice at a time. These slices are integrated together to create the entire product. The increment at the end of the sprint should be 'potentially deliverable' - there is no undone work, so if the product owner believes there is more value in releasing than not releasing, she can call for a release.

These "slices" are defined by entries in the Product Backlog (and are often called stories). The stories get mapped to acceptance criteria, which can be logged or documented as appropriate. When the acceptance test is green -- and the remaining aspects of the definition of Done are satisfied -- the story is considered done.

Even if it is not practical to actually deliver at the end of each sprint, it is still desirable to have granular control of what is done. It is by implementing features in small slices and by insisting that there be no undone work at the end of sprint that Scrum teams achieve the ability to deliver predictably. By measuring progress in terms of deliverable functionality, they gain the ability to predict when the total package will be finished.

The Product Owner

When is the whole product really done? When can we really release? That is the decision of the Product Owner. The P-O decides which items will be done first, whether a feature is really done, and when the product as a whole can be released (even if release means "released to the approval process.").

Meeting Regulatory Requirements

So how will your project meet the regulatory requirements? Here's how I would do it:

  1. Identify the requirements of the relevant regulations, both functional and non-functional, requirements, non-functional requirements, or deliverables - whatever! 
  2. Prioritize these at the top of the product backlog. So in the first sprint or two, the team will figure out how to satisfy these requirements. Probably they will produce new backlog items and/or entries in the definition of Done. 
  3. Treat the regulators as stakeholders. Identify their needs. They have (or should have, and maybe need help to develop) a definition of ready - when is a product ready for approval. Try to understand that and you can make it easier to get your product approved. Although it may seem impossible, I would try to reach out to them to start a dialogue, explain how we are developing, what Done means in our process. Regulators are people too.

Does Scrum fit a regulated environment?

One thing that troubles some people is the idea that the project would be released to the authorities every sprint. Releases have high cost, require many signatures, and it just doesn't make sense to release.

OK. Then don't. If there is no point in releasing, then there is no point. However the advantages of the having the product in a releasable state every few weeks are still tremendous. By creating a steady stream of finished, deliverable value, you increase the predictability of your project and dramatically reduce the chance of a major setback near the end.

Why prioritize? I have to deliver everything!


Yes you do! And you have to deliver to a deadline. Now if time is getting short, which would you prefer?

  1. Deliver 'everything' but in questionable quality. 
  2. Deliver many features, but the undelivered features are of unknown importance, some get used every day, some not at all, or
  3. Deliver all the features that are used every day or every week and leave out those that only get used seldom or not at all (which makes up 2/3rds of a typical project).
Even if you really have to deliver everything, option 3 is your best choice, for your customer and your reputation!

Handling a regulatory requirement

So let's say you have a requirement for traceability. For every implemented feature, you have to show: where the requirement came from, who implemented it, and show that it was implemented according to the requirements.

A backlog item is a requirement. It has a title and can be enriched as you see fit. Almost every project will enrich the backlog entries with acceptance criteria. And we can enrich them with the necessary information for traceability.

A backlog item serves as a reminder that you will have a conversation (or several conversations) to define what that requirement means. As you get close to implementation, you will have those conversations with the appropriate stakeholders and enrich the backlog item with those decisions.

While you could use an Agile management tool to record this information - and some of them have nice integration with testing tools, let's assume we're using a wiki the product backlog. So the backlog items get recorded on the wiki page.

As the team and the stakeholder(s) agree on the meaning of the story, e.g. the acceptance tests, the screen design, etc, they will record these these decisions on the wiki-page for that story. Design documents and other files can be attached as well. If subsequent decisions change or clarify the requirements, these get logged here. 

If there is other information we need to record, like who was involved, this can be recorded in the wiki. Templates help us remember what information to record and a checkbox in the definition of Done -- rigorously applied! -- ensures that we remember to keep the data up to date.

By the time the story is implemented, test cases will be have been created and implemented. Some of those test cases are acceptance tests. Ideally, you would automate them. In that case, it is easy to link the story to the results of the test suite. Even if not, you can still link to the test description and upload the test reports. A product page links to every story that is part of the product, which in turn link to the requirements, which finally link to the test suites and the test reports. Voila! The whole chain is present: Traceability:

And, last but not least, by following your definition of Done, you ensure that you have checked that any manual links are set and that the templates are completely filled out. So every time you implement a feature, when it is Done, you certain that you are release-compatible. When you have implemented the entire backlog, you are certain that the entire result is ready to start the road to approval.

Comments

Silvana Wasitova said…
Well summarised, thanks Peter!
Peter said…
Thank you Silvana! (And it's so nice when someone posts a compliment which is not simultaneously a SPAM link ;-)
andy.blogger said…
Really enjoyed the summary!

I was wondering if you are aware of any pharmaceutical companies that currently use agile methodologies?

Thanks!
Peter said…
Sure, lot's of them. I have had representatives of many in my public courses, and I have company courses for at least two. One that I know of even has a Scrum handbook - How we do Scrum in a/our regulated environment..

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …