For years, increasing organizational agility has been a top priority of insurer IT strategies. In addition to embracing modular and configurable software and service-oriented architecture, insurers are also increasingly turning to agile development methodologies to improve the quality and fit of their custom developed applications. While the benefits of adopting agile development can be significant, the change management involved in educating both business and IT on this new way of doing things can be significant as well.
Agile development is a group of software development techniques emphasizing iteration and collaboration, as opposed to more sequential software development processes culminating in a final deliverable. The main principles stated in the Agile Manifesto:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
In speaking with dozens of insurer IT leaders recently about agile development, most of them have seen positive business impact in project quality, IT productivity, and in business/IT alignment. However, with agile's less structured approach, there is less direct impact on project completion time, with some insurers even seeing poorer performance. This may be caused by the lack of a true "end date" to agile development. The true advantage of agile is not the improvement in speed, but rather the greater likelihood that the solution will meet the business need at the time of completion.
Switching to agile is a learning process. Generally, as leadership and staff become more experienced with agile development methodologies, their positive feelings grow and skepticism declines. But there are challenges along the way. One insurer I spoke with recently was surprised at "the quick adoption rate by business leadership," while another commented "business analysts (in business units) quickly became advocates." But they also cautioned against issues of change management, including resistance from IT and the need for following project discipline. There also can be challenges in working with sourcing parties who may be more familiar with traditional waterfall approaches, in keeping momentum going, and in planning and execution.
Another insurer I talked to emphasized the value of agile in building cross-team enthusiasm, noting that "the business and IT staff both enjoy the interactive and iterative development process."
Insurers have also seen significant improvements in business/IT communication. One was surprised by "How much more quickly problems bubble to the surface and can be resolved more quickly; the strengths and weaknesses of the team and team dynamics are exposed much more quickly."
Several other insurers mentioned that they used a modified form of agile development, and perhaps the most interesting quote was this one:
"Moving to this methodology was a shift in how to think for us. We had to learn a new vocabulary, look at projects in a different way and understand that rework was not a bad thing. We also had to learn that perfect was the enemy to the good. Adding functionality in an incremental fashion instead of doing everything up front is hard to accomplish. Prioritization of functions is critical and using object-oriented analysis/object-oriented design is much more complex than we ever imagined, but now that we have some experience under our belt, the work is getting done at a quicker pace, but still not as fast as before."
It is important for insurers to realize that agile development is not a formal design methodology or an excuse to avoid documentation or project/program management discipline. The take-away from these principles is on balancing flexibility, regular communication and collaboration with the minimum constraints required-not to impose no constraints.
While agile development holds significant promise in terms of business/IT alignment, user enthusiasm and acceptance, it also has a number of challenges:
* Retraining IT and the business in terms of learning a new vocabulary, embracing the need for continuous rework and for close collaboration between IT and the business.
* Project management. Harmonizing a traditional project management methodology with the agile development process is challenging, but it is doable and worth the effort. Agile can be a very effective way to not only align business needs with development, but also reduce some project and vendor management risk since code/components are delivered very early in the project. It allows companies to address higher-risk elements up front and/or assess their technology partners early in the relationship.
* Reorganization of governance processes. It is important to note that most carriers' governance processes were not designed to deal with changes (often significant ones) on a real-time basis and will need to be adjusted to do so.
If a team is not comfortable providing honest, regular feedback, and team members are not willing to take responsibility, if proper prioritization and prioritization of tasks does not occur, if a team cannot be dedicated to a project, then carriers will not see the benefits of using agile development. IT and business leadership need to approach the potential benefits and concerns of agile software development techniques in a realistic manner in order to get the most out of them.
Matthew Josefowicz is director of the insurance practice at New York-based Novarica, and can be reached at mj@novarica.com.
