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.
It feels as though the word "value" has appeared in more discussions about software development and delivery than in the previous two decades. We see this increased demand for immediate, tangible value across the entire range of technology producers and consumers. The dubious value of legacy applications, which have grown like kudzu, is the impetus for many painfully difficult cutting and pruning jobs within IT departments. Faster realization of value is driving more applications and infrastructure into the cloud. Software vendors are realizing that, while revenue is vital, the long-term relationship with the customer depends on the mutual value that both parties think they're getting from the relationship.
If we measure software by value, instead of cost, revenue, completeness, or other possible measures, we have to measure the software development process in a complementary way. What characteristic of software development is most likely to generate a valuable result? If your answer is "speed," think again. Predictability is a much better measure.
At the IBM Innovate conference last month, Walker Royce made a very plausible case for valuing predictability over velocity. Here's his keynote address, which is definitely worth watching.