In my previous post about Agile practices and compliance requirements, I described the first of two big surprises encountered while doing the research. Compliance, as it turns out, is not quite as high a barrier to Agile as we thought. The second surprise has to do with the approach teams have developed to getting over or around that wall. 

Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)

In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.

In hindsight, this approach makes perfect sense. Products need anchor points in time, which compliance certainly imposes. Audits and regulatory submissions impose a deadline for a particular "release," the package of documentation, aggressive risk management, accountability, and other requirements needed to get a stamp of approval. The definition of "done" is very clear in a way that a backlog of user stories might not always suggest.

Other aspects of compliance impose another time-based aspect of productization, a road map. If you're embedding software in medical devices for the American market, you're no doubt aware of 21 CFR Part 11. Of course, if you're in the medical device business, you're probably interested in selling your wares in Canada, Latin America, Europe, and elsewhere, in which case you need to satisfy regulations like 21 CFR Part 11. Voila, you now have a road map with very clear "releases."

The flurry of activity around releases of the compliance "product" also looks very familiar to anyone who has participated in a software product release. You've stared at the same requirement countless times, thinking that you understand it fully, only to have the stakeholder (auditor, regulatory official, etc.) tell you that you've interpreted it in the wrong way. New requirements slip in late in the release cycle as the stakeholder explains that planned feature X is useless without unplanned feature Y. You try to negotiate with the stakeholders to help them understand that you may be satisfying their requirements, just not in the exact way they expected. The one difference, of course, is that you can't cut anything from the release: Either you're compliant, or you're not.

Describing this unintentionally product-oriented strategy to compliance proved to be too much for a document describing the tactics for dealing with compliance (traceability, documentation, workflow, etc.), which was already bursting at the seams. Therefore, we published these findings as two separate documents: one covering the tactics and the other describing the strategy. Having said that compliance is a many-headed problem, I then proceeded to write three separate documents on the subject — in effect, providing a many-headed solution. So sue me.