The Benefits Of Agile Software Development In Regulatory Projects
Businesses and organizations across the United States must adhere to ever-changing regulatory requirements, and software development projects often come about in response to a change in regulation. Financial institutions and medical businesses are particularly prone to changes in the law, and a reliance on software means that core systems must continually adapt and evolve. Agile software development methodology is increasingly popular for this type of project. Here are three crucial reasons why.
Speed of delivery
Waterfall project teams spend significant periods at an early stage defining and documenting requirements in detail. The output (a business requirement specification) becomes the reference point during the entire project, but it is often some time before any work starts, as everyone focuses on the requirements specification.
Agile projects don't work at this level of detail. Instead, agile projects deliver the work in short, detailed iterations. These iterations (or scrums) generally work in two-week blocks, during which the project team focuses on a set of user stories that developers then use to develop new or revised code. This approach speeds up the delivery cycle. In fact, a 2013 survey found that 23 percent of businesses chose an agile project methodology because of the potential for accelerated speed to market.
Speed is particularly important with a regulatory project. If your company has limited time to respond to a change in the law, an agile approach is more likely to succeed. Agile methodology allows you to take advantage of quick wins. For example, your software developers can often finalize one or two new features that you can quickly release, whereas a waterfall project would have to wait until everything is ready before making changes live.
Ability to cope with unclear requirements
Changes in regulation are often unclear or ambiguous. While some legislation is very prescriptive, other changes are open to interpretation and rely on reasonable business decisions. Waterfall projects don't work well with ambiguity. The precision of the requirements gathering process means you can waste a lot of time trying to accurately define regulation that is deliberately open.
Conversely, agile methodology thrives in these situations. The iterative approach allows the project team to quickly devise and develop a proposed solution that a subject matter expert (product owner) can then consider. While this may take several attempts, the development process is generally quicker and less complex this way, and the early engagement of the product owner often highlights early problems with the requirements. If necessary, you can then seek early clarity or further information to define the outcome the regulator expects.
The ability to adapt to scope change
Regulators will often amend or update their requirements. In fact, research in 2013 tracked an average of 110 regulatory changes every day during the third quarter of the year in the financial services industry alone. What's more, a challenge from a lobbying group or a high-profile court case may result in an update to an approved change, which, in turn, affects all active projects related to the new legislation. For a waterfall project, this situation is often difficult. You may need to revisit the requirements specification, and some projects literally have to start over again.
Agile projects are able to adapt to these changes more easily and quickly. The iterative nature of an agile project makes it easier to change direction, discard certain requirements or go back and revisit work that the team has already completed. With an agile project, you can continue to add new or revised requirements throughout the project lifecycle. With a waterfall project, there is generally a point of no return.
Waterfall projects will often only 'smoke out' issues at a later stage. For example, the effect of one change on another part of the system is often not apparent until the project team completes regression testing at the end of the project. Agile projects test each requirement as part of each development iteration. As such, the team normally gets earlier sight of potential software conflicts.
Agile development methodology is increasingly common in American software projects, and this approach is particularly beneficial where regulation prompts change. Talk to a technology consultant for more information and advice about this way of working.
