Many insurers are interested in the modern development methodologies of Agile and Continuous Delivery, but worry about how those approaches will work in such a highly regulated industry. When done properly, using an Agile development methodology and/or a Continuous Delivery approach shouldn’t prevent an insurer from putting controls and reviews in place to satisfy external regulations (and internal rigor). A test-driven approach supports both Agile and Waterfall development efforts.
First, just because a development team is doing continuous delivery or packaging releases into two-week sprints doesn’t mean that code is being moved to production. One of the points of this approach is that code is constantly being built and deployed to a test server and that smaller chunks of effort are packaged for business user review. This means that some of the API integration and build issues that often hold up a project at the end are being nurtured and considered the entire time. It doesn’t mean, however, that actual production releases can’t go through the same rigorous testing and sign-off before ever moving to production servers. You can take an agile approach to a project with two-week sprints that doesn’t actually go into production more than once or twice a year.
(Note that some organizations do consider continuous delivery to mean that once code has been committed by a developer, it can be tested and moved to production at any time. While this is interesting in theory I know of very few organizations that actually do it this way, and none in the insurance industry that do. The idea to embrace with CD is that you have a production quality branch ready to go at all times, but that doesn’t mean you have to actually move that branch to production outside of a predictable schedule.)
Second, when done well, an agile approach actually results in more business user review and testing of a system as opposed to less. Testing is spread out over the entire process rather than done in one large burst at the end. A key value of the “sprint” concept is a continuous involvement of business users. Engineers are supposed to be delivering something every single sprint that can be demonstrated and reviewed by stakeholders. Unfortunately, this is where a lot of organizations fail to properly follow the agile methodology. A lot of companies (not just insurers) who embrace the idea of a sprint, really just treat it like a way for developers to chunk up rapid milestones. Agile is not the same thing as Rapid Prototyping. Without the business stakeholders regularly reviewing the results, adjusting priorities, and signing off on items, it’s not really following the agile protocol.
Third, there’s a misconception that requirements in an agile approach are highly fluid or not well defined. While an agile approach is supposed to allow you to make rapid shifts in priority, it doesn’t mean as an organization you have to do so. If there are a set of regulatory-demanded requirements for a project, those are going to be at the top or near the top of the priority queue, and no amount of flexibility will mean that they get pushed off the list. Until they’re implemented and signed off, the project isn’t going to go into production regardless of how many sprints have passed.
While I’m a big fan of an agile approach, I don’t think it is right for all insurers or even right for all projects at an agile-minded insurer. If the executives at an organization feel uncomfortable without very detailed project plans and requirements documents, the culture may not be right for agile. If you want to make some important feature updates to a legacy core system, you’re probably going to want to take a waterfall approach of defining the changes, implementing, and testing them; it’s often very difficult to do the sprint method with systems like that. But if you’re building a new web portal and the culture supports it, an agile approach can work great, especially when UI development is involved. And sometimes a mix is in order: if you are implementing a new core system, even if you take an agile approach you’re probably going to want to have some major planning and requirements gathering sessions up front so that you can define costs and timelines with your vendor.
This blog entry has been reprinted with permission.
Readers are encouraged to respond using the “Add Your Comments” box below.
The opinions posted in this blog do not necessarily reflect those of Insurance Networking News or SourceMedia.
