Posted by Tom Grant on July 27, 2011
Now that Agile has moved into the mainstream, it is encountering a whole new raft of challenges, including compliance. The word on the street for at least the past couple of years is that trying to be Agile and satisfy regulatory requirements is a lot like juggling chainsaws and machetes: theoretically possible but certainly not advised.
Fortunately, the word on the street is nearly always wrong. When I started interviewing people who had made Agile succeed in highly regulated environments, I expected to hear a lot of handy best practices that I could synthesize into a research document — essentially, a tactical guide to compliance. If you're a medical device company and you need to document six ways from Sunday how you validated and verified the software embedded in a new device, here's what you might do. If you need to deal with the auditors, here's where an investment in an application life-cycle management (ALM) tool might help.
Although this type of research depends on interviews, it's worth taking a peek at the available survey data to see if it has any additional insights. And boy howdy, am I glad I did. Sifting through the data collected in the survey that Forrester did in conjunction with Dr. Dobb's Journal, I found the first of two big surprises about Agile and compliance:
Agile adoption in the most regulated industries is not significantly different from the adoption rate everywhere else.
"Not significantly" translates into only a couple of percentage points. While not every app dev team working in a pharmaceutical or power company is necessarily affected by compliance, the long arm of regulation does reach fairly deeply into these firms. Financial services companies, for example, have to worry about how regulations affect not only customer-facing apps but also many internal applications. Auditors are very persnickity about the hijinks people can pull through ERP systems or even internal collaboration apps, and they're definitely interested in whatever paper trails they leave behind. You'd expect to see some significant consequences if Agile and compliance are truly incompatible.
The survey data provided some other interesting insights into what does and does not change in app dev teams as a result of living in the iron grip of compliance. Therefore, I wrote two documents, one covering the tactics for dealing with compliance and another presenting the survey data.
I don't want to sound as though I'm minimizing the difficulties that regulations and audits pose for Agile teams. Quite the opposite — compliance is clearly a tougher challenge than, say, making Agile work in a distributed team. (I field inquiry questions from Forrester clients every other day on making Agile work in distributed teams, so I also don't want to sound as though I'm pooh-poohing that challenge.) Having teams in different time zones poses a single problem; compliance poses several. Validation, verification, prescribed workflows, traceability— any one of these hard realities of compliance would be hard enough. Unfortunately, they never come alone, and the few I've mentioned here fall far short of an exhaustive list. (And, of course, no one is subject to just one regulation . . . )
To many app dev teams, whether or not they're Agile, compliance feels like a video game in which, after you just beat one nasty level boss, another one is waiting in line for you. That's what makes these survey results extremely reassuring. Even though compliance is a scary, many-headed monster, people do roll up their sleeves and deal with it. The tactics are not easy to master, which is why some ALM vendors like Rally are putting some effort lately into explaining how tools can ratchet down the difficulty level. But it's definitely possible to master them.
What's the second surprise from this line of research? In my next post, I'll talk about how app dev teams have gone beyond tactics to build an effective compliance strategy. The surprise is how this strategy succeeds because of Agile, not in spite of it.