When agile meets auditor
The demands of a regulated environment shouldn’t scare project teams away from agile. BY DONOVAN BURBA
In a relatively short span, agile approaches have gone from the margins of project management to decisively in the mainstream.
But even within IT and software development, there’s one area in which agile still has to fight for a foothold. Regulated industries—financial services, pharmaceuticals, healthcare and the like—have proven to be less receptive to agile, even as more fields beyond IT take the plunge.
To be fair, regulated environments seem ill-suited for agile at first glance. Its iterative approach seems at odds with the rigorous validation, documentation and assessment requirements that projects in such industries must meet. Couple that with the increased consequences of failure—where a software failure can crash not just a computer but an entire financial network—and the reluctance to move away from the waterfall model is understandable.
“Agile methods are focused on delivering a large amount of business value to the customer,” says Denise Canty, PMI-RMP, PMP, senior IT project manager at Cenden Company, Washington, D.C., USA. “Regulated industries are more focused on safety first and may not be the best candidates for agility.”
respondents to VersionOne’s State of Agile survey credited implementing agile for improvement in their ability to manage changing project priorities.
“Agile methods are focused on delivering a large amount of business value to the customer. Regulated industries are more focused on safety first and may not be the best candidates for agility.”
—Denise Canty, PMI-RMP, PMP, Cenden Company, Washington, D.C., USA
However, done correctly and under the right circumstances, agile can both decrease project cost and shorten schedule. A whopping 92 percent of respondents to VersionOne’s State of Agile survey cited improvement in their ability to manage changing project priorities. In industries where regulations often change, the ability to better adapt can mean the difference between project success and scrapping the project. Agile also gives teams more flexibility to tailor their verification and validation tests to the actual product and adjust as needed—a critical concern in regulated industries.
Crucially, there’s more transparency with burn-down charts and agile’s focus on velocity, says Bryan Berthot, PMI-ACP, PMP, a San Diego, California, USA-based IT systems development life cycle project manager at Verizon, a PMI Global Executive Council member. “In waterfall software development, there’s a great fiction when using percent complete to estimate task completion, because you’re often relying on ‘happy path’ estimates from developers,” he says. “In agile, the task is either done or it’s not, and this is reflected in daily changes to the burndown chart.”
Reaping the benefits of agile requires balancing its rapid iterations with the often extensive testing and documentation inherent to regulated industries. It can also mean compromising with a hybrid approach—and recognizing that sometimes waterfall really is the best way to go.
THE STARTING BLOCKS
The first step to understanding how agile can help organizations in regulated industries is knowing the nature of those regulations. Though the word implies rigidity and consistency, regulations are ever-changing—and agile lets project teams shift along with them.
Marcus Glowasz, PMI-ACP, PMP, PgMP, senior IT project manager at Credit Suisse, Zurich, Switzerland, manages anti-money-laundering initiatives on which the requirements are largely driven by auditors and regulators. The issues they raise rarely come with much warning or time to get full sign-off from stakeholders.
“In that field, I have rarely experienced an implementation of the initial requirements, due to frequent scope changes,” he says. “A strict waterfall method can therefore not be applied to such projects. Agile approaches ensure that deliveries can adapt to regulatory deadlines that were unclear or not known at the beginning of the project.”
Project leaders can leverage those benefits to help persuade stakeholders to shed the comfortable but sometimes cumbersome scaffolding of traditional approaches. To win over skeptics, Mr. Glowasz’s team performs retrospectives on previous projects and identifies where change requests caused overruns. That gives the client a quantifiable, real-life look at agile’s potential.
PHOTO BY LUIS GARCIA
“In waterfall software development, there’s a great fiction when using percent complete to estimate task completion, because you’re often relying on ‘happy path’ estimates from developers. In agile, the task is either done or it’s not, and this is reflected in daily changes to the burndown chart.”
—Bryan Berthot, PMI-ACP, PMP, Verizon, San Diego, California, USA
As with any significant change in processes or approaches, starting small is a must. Mr. Berthot adopted a staged approach when, in a previous position, he introduced agile to a healthcare firm. He began with a small, sunk-cost project—in which money had already been spent and couldn’t be recovered—where the company could learn about agile, then followed with a larger US$100,000 software implementation project. Several lessons emerged from these efforts, including the organization’s risk threshold and the agile project team’s velocity.
“One thing we learned was that this core team—seven internal IT staff members—could do a good job when they could focus on one project at a time,” he says. “When they were split between two or three projects, velocity on all projects slowed considerably. When we took these lessons learned from the second project retrospective, the team was ready for its real challenge.”
The next project was a US$2.5 million software implementation to replace legacy homegrown software with a commercial electronic medical record (EMR) product. Because Mr. Berthot’s team had established data on the team’s velocity, the company was not overly aggressive in its time constraints; the EMR was successfully implemented under its baseline budget.
Even the most enthusiastic agile evangelists recognize that there are some times when it’s simply not the right choice. Several red flags signal the potential for failure, says Ms. Canty. She identifies four situations where waterfall may make more sense and agile should be kept on the bench:
- Inexperienced teams
- Inadequately defined user requirements
- Projects involving third-party vendors
- Projects that use legacy systems where the code is highly dependent on other code
And she notes that even projects that use agile approaches should consider using more traditional methods at key times. “Critical components of software should be developed under more formal software development methods,” she says.
The View From the Starting Line
Introducing agile approaches into a regulated environment is a daunting prospect in part because of the unknowns that come with the transition. Bruce Gilland, PMI-ACP, PMP, in Denver, Colorado, USA, has gradually been integrating agile processes into projects. Teams have started using sprints and iterative development on projects, and plans are in place to introduce other aspects, such as daily stand-ups.
Even with years of experience in software development and the PMI-ACP® certification under his belt, Mr. Gilland faces a host of unknowns that underscore the challenges of regulatory projects. The U.S. Food and Drug Administration’s regulations are designed with waterfall in mind, he says, so adapting them to agile processes raises questions.
“For example, if we bite off 20 requirements for a given iteration, do we need a new requirements document for those, or just add to the existing one?” he says. “Do we need a new design document or just add to the existing one? For testing, do we need a new test plan? New protocols? New reports?”
“Several members of senior management are interested in trying agile approaches, but they’re stuck in the mindset of having full feature sets delivered by a predetermined date.”
—Bruce Gilland, PMI-ACP, PMP, Denver, Colorado, USA
Similar issues around financial tracking and gathering end-user feedback will also have to be resolved along the way. An upcoming software-heavy project will give Mr. Gilland’s team the opportunity to ramp up its agile efforts, since it’s the hardware aspects that still are implemented using waterfall. The effort will not only help answer the aforementioned questions, but may also convince curious stakeholders.
“Several members of senior management are interested in trying agile approaches, but they’re stuck in the mindset of having full feature sets delivered by a predetermined date, often set by marketing and without much input from the R&D team about how long it will really take to create those features,” he says. “It will take a few small successes with projects that implement more agile features to make them comfortable with going full agile.”
WRITE THIS, NOT THAT
One of the biggest sticking points to agile adoption in a regulated environment is the question of the testing documentation required by auditors, says Vasudeva Sharma Mallavajhala, PMP, associate director of quality, Novartis Healthcare Pvt. Ltd., Hyderabad, India.
It’s an obstacle that manifests itself in different ways with different people. “System developers think that agile means no process and no documentation, so when they are asked to prepare documentation required for regulatory compliance, they think there is no benefit for them,” he says. Meanwhile, “the business people think agile cannot enable regulatory compliance because it means no documentation.”
The confusion comes from the misconception that using agile approaches means throwing out all documentation. Ms. Canty notes that agile values working software over comprehensive documentation, but still leaves plenty of room for necessary paperwork.
“Only create documentation that is requested by a project stakeholder,” she says. “If it’s not asked for, then don’t create it.”
Mr. Mallavajhala notes that while there’s no way to totally circumvent necessary documentation, teams can meet requirements without bogging down the process. These span:
- Including the completion of documentation as part of Definition of Done for each user story
- Including documentation as a task in the user story life cycle
- Allowing documentation sign-off at the end of release—before starting formal test execution—so that any changes to requirements do not have to go through a formal change management process
Also, teams don’t need to spend time documenting tests and systems used only for internal purposes or incremental developments that won’t be reported to regulatory bodies.
LEARNING TO COMPROMISE
The need for substantive (if not substantial) documentation likely precludes the use of nonhybrid agile in regulated environments. There’s no getting around the fact that traditional waterfall approaches will have to be integrated into any iterative process.
For example, Mr. Mallavajhala knows his team members will have to submit a certain amount of documentation and receive formal approval of plans, tests and systems throughout the project life cycle. But that doesn’t mean they sit around waiting for sign-off before moving to the next stage. Instead, they update their regulatory documentation throughout the sprints, and get sign-off just before the formal testing. “This way, the method avoids formal change management and approvals of specifications during development and thus enables better productivity and turnaround time,” he says.
“[In the anti-money-laundering field] I have rarely experienced an implementation of the initial requirements, due to frequent scope changes. A strict waterfall method can therefore not be applied to such projects. Agile approaches ensure that deliveries can adapt to regulatory deadlines that were unclear or not known at the beginning of the project.”
—Marcus Glowasz, PMI-ACP, PMP, PgMP, Credit Suisse, Zurich, Switzerland
PHOTO BY LUIS GARCIA
“As a project manager you need to recruit agile champions among your senior management and key project stakeholders. Ultimately, each business unit that has deliverables on a project must be operating on the same cadence.”
—Bryan Berthot, PMI-ACP, PMP
Indeed, an agile-waterfall hybrid can address a number of industry-specific issues that agile alone may not. Differences in regulatory jurisdiction and data availability can preclude remote teams from performing efficient testing, requiring a more traditional testing model, says Mr. Glowasz. Fixed-price contracts with third-party vendors are often incompatible with agile methods, he adds.
“The best experience I’ve had so far is with an incremental waterfall method that incorporates some of the most important agile concepts, such as embracing change, while considering external vendor constraints,” he says.
Mr. Berthot warns that other business units within the organization—such as regulatory, purchasing, legal or medical affairs—can hinder the adoption of agile if they continue to work in waterfall. In such cases, he says, products finished with agile go unreleased while the rest of the enterprise catches up. “If this occurs in your organization, as a project manager you need to recruit agile champions among your senior management and key project stakeholders,” he says. “Ultimately, each business unit that has deliverables on a project must be operating on the same cadence.”
An added benefit to a hybrid approach is that it gives those skeptics a chance to dip their toe in the agile pool before diving in, says Ms. Canty, and that can mean both early buy-in and long-term success.
“A change in culture is necessary in order to embrace change, and we know that this does not happen overnight,” she says. And, she warns, as more and more regulated industries adopt agile processes and reap the benefits, those that lag will increasingly be at a competitive disadvantage. “Companies that don’t keep up and embrace agility could be left behind.” PM
JANUARY 2015 PM NETWORK
PM NETWORK JANUARY 2015 WWW.PMI.ORG