Agile & Regulatory Requirements

Financial regulations proposed in the industry have a fixed set of rules, conditions and fixed timelines. Regulatory requirements are those IT product requirements that arise out of these Financial Regulations and such Regulatory Requirements have a Fixed Scope and Fixed Time.

When I am in a session packed with individuals from Finance and Banking domain there is common concern raised in the room around Regulatory Requirements and the usage of Agile

The concerns are valid and I thought I’ll share my opinion coupled with some experiences around this in the post.

These requirements are non-negotiable.

I’d put it this way, its tough to negotiate as there can be lot at stake. Let’s consider a case where there is a set of requirements all labeled as “Must have” as per MoSCoW prioritization technique. One such requirement from that set is as follows

“Submission of end of day extract of trades with X condition to the regulators”

At the organisation level to comply with the regulation, this requirement can be achieved in following ways

• Fully met through the IT product.
• Partially met through the IT product with some manual effort by the business users.
• Fully manual by your business unit.

In the above requirement, submission of the extract with accurate data is more important than how it is generated within the organisation. Therefore generation of extract or the generation of supporting data to prepare such an extract can be your “Must have”. Once the extract data is available, you or the business users can create the macros or scripts to prepare the extract in a specific format required by the regulators and deliver it. Automation of delivery mechanisms can be your “Should have” which you may be able to negotiate and prioritize it in later releases. With this you get some space to push up the next “Must have” requirement up in the backlog.

Scope and Time both are non-negotiable, then why not follow waterfall ?

With waterfall, the entire success of the product is based on the initial plan and the initial requirement analysis. I’d like to share a case where agile may have saved the product and its team from disappointment.

Team Titans worked on a shopping cart application which had users around the globe and the product was developed by following a waterfall cycle. Titans were developing requirements around booking of orders based on the functional specifications. The development took about 2-3 months and Titans were finally ready to demo the changes before they drop the new changes into UAT environment. Since the product had users from all over the globe, the demo was scheduled in 2 time zones. The 1st session was with Asia and UK region and it went well, applause everywhere !!. The 2nd session was with users from America region and it is here that the Titans realized that the changes done are not acceptable to the users from this region as its not functionally compatible with the rules of that region. The Titans had to postpone the release.

In the above case, the functional specification was over a months work and was signed-off by a set of users from Asia and UK region, the assumption during analysis was that all regions follow the same way of booking orders. One of the question that arise here is that “Can this not happen with teams following Agile?” Well the probability of such tragic thing happening with agile teams is less as there are more frequent product reviews(sprint review/iteration reviews) i.e. Continuous Plan Do Check Act. Agile helps you build the right product and deliver the right features at the right time.

Prioritization of requirements is done, there is nothing that can be taken out or pushed down, everything has to go this release, what can I do now ?

This concern is not specific to agile, its not new too. If your scope if fixed and cannot be negotiated further, time is fixed then increasing the budget can be the way out i.e. add more people.

When adding new team members, if you are adding 1 to 3 new team members for a short time, then it is worth adding them to the existing team rather than creating new fringe teams. I’d have those 1 – 3 new team members work along with the existing team so that there is quick access to product knowledge, less integration points, less handover activities, more synchronization and more collaboration. The downside might be that team events such as planning, daily stand ups, retrospective and reviews may take a little longer to finish but that should be manageable given the benefits on the product side.

Overall

To conclude, I think when we are up against a Fixed Scope, Fixed Time requirement, taking an agile approach becomes even more important as there is less room for errors.

DISCLAIMER

THE OPINIONS EXPRESSED HEREIN ARE MY OWN PERSONAL OPINIONS AND DO NOT REPRESENT MY EMPLOYER’S VIEW IN ANY WAY.