Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Agility in regulated environments

Expand Messages
  • William Pietri
    ... Like George, I m skeptical. There are three sorts of regulation that I ve come across, and they can all be dealt with in ways that preserve the agile
    Message 1 of 4 , Sep 18, 2008
      George Dinwiddie wrote:
      Given we're in the finance sector, even the agile proponents say that 
      some projects simply won't work in an agile way (huge number of 
      compliance regulations, etc).
      I have yet to see a reason related to the finance sector that would 
      disallow agile software development.  What sort of problems are you 
      anticipating from compliance regulations?

      Like George, I'm skeptical. There are three sorts of regulation that I've come across, and they can all be dealt with in ways that preserve the agile values and spirit.

      One is where the domain is regulated, even if the development isn't. An example here is insurance. Insurance products are often heavily regulated, so the outputs of your software must conform.

      The agile emphasis on automated testing is a huge help here, as you can continually verify conformance. Frequent internal delivery gives experts more time and resources to verify as well. And since regulations and regulatory interpretations can change unexpectedly, an agile team can adapt more quickly and cheaply than the competition.

      A second is where there are expensive, slow external verifications of the product. I've seen this happen with internal regulation (like a security group at a large company), and hear it's similar with some external regulation (like FCC or FDA approval).

      From the agile perspective, this is just a very important release. Done right, agile approaches give higher quality at lower cost. It also lets you discover potential issues sooner, allowing research and discussions with regulators. The main difference I've heard to normal agile approaches for this is an additional investment in more traditional, off-team QA, and on-team experts in compliance.

      The third is regulation that affects the software development process itself. For example, Sarbanes-Oxley or CMMI.

      My understanding here is that agile processes can easily be made to comply with both the spirit and the letter of most of these. But because it looks very different than a traditional shop, you need to find an auditor who can apply the regulations thoughtfully and creatively, rather than following a checklist based on how a waterfall shop would do it.

      Hoping that helps,


    Your message has been successfully submitted and would be delivered to recipients shortly.