Use Agile for Areas Subject to Regulations?
The Question: I asked for feedback on LinkedIn about using agile for target business problems focusing on an area subject to regulations, contract terms & conditions, agreement/deal provisions, business policies, etc. (Sound like your area?) The best reply I got back …
Guest Post by Sujatha Ramesh
Sr. Manager, Business Solutions at LearningMate
“In highly regulated environments, documented evidence of decisions, impact and approvals are a necessity. Agile practices discourage maintaining extensive documenting, relying on ‘sitting next to the team and explaining’ instead. You will generate precious little proof of what transpired and the decisions taken in doing so.”
Tags: agile, business analysis, requirements
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
David Wright (@dwwright99)
| #
Wild thought – all of the things in the reply’s first sentence become requirements, even user stories: e.g. “As an Administrator, I need to present documentation of decisions to the appropriate regulator, in order to comply with Regulation XYZ”.
I think what this implies is that not all user stories are implemented in software. Agile then become s about more than software, but about overall solution, which some practitioners are trying to push. I don’t know if this is enough to make Agile successful overall for this type of effort, but it has to start working beyond the software in order to have any chance.