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.