Musings on project management: Agile compliance with customer standards

Friday, August 1, 2014

Agile compliance with customer standards

"They" say about Agile:

You don't have to bother with gathering requirements; requirements just emerge
You don't have to have any documentation; it's all in the code
You can do away with V&V: verification and validation, because that's like QA tacked onto the end
You don't really have to have an architect, because (somehow) the best architecture emerges

In my view, and what I tell my students: Nonsense, all of it! "They" have never tried to build something with OPM (other people's money) and been personally accountable for how the money is spent, what value is produced, and how the value/cost ratio was managed to the advantage of the business. But even more important, "They" have never had to be responsible for business-critical performance.

But to that add external regulators. Regulators don't give a flip about what "They" think. There had better be outcomes that can be audited back to the base level; there had better be documentation that supports claims; there had better be a way to do V&V before the "what did you know when and why didn't you know sooner" questions arrive via your local lawsuit.

In any regulated product market, like medical devices for instance that are built with a lot of software, the focus has to be on the joint satisfaction of the buyer/user and the regulator. Fortunately, both of these groups are on the "output" side of the project, which fits Agile quite well.

Where agile has a vulnerability is in the compliance part... unless compliance is built into the backlog, either as a framework or as explicit "stories". To not do so is to take a really unrealistic path to only temporary success... temporary until the regulators tear it apart.

Same comments apply for any number of regulated businesses, like banking, by the way, and back office areas like cash management and receivables where these things have to sustain audits, to say nothing of safety systems like certain critical avionics, ship controls, and industrial controls.

And, in this day and time: "big data". Ever tried to validate a data warehouse with tens of millions of records? The issue is simple; the solution is not. Reporting from a data warehouse is almost like "lying with statistics": you can find some data that fits almost any scenario, but is the context accurate; marriage of data with context is where the complexity (and information) lies. Doing data reports in Agile could be fool's errand if the "stories" are not carefully crafted.

Security intrusion avoidance anyone?