Over the last 10 years, IT leaders have been under increasing pressure to improve speed of delivery and innovation within their organizations. As a consequence of the business environment in which insurance companies operate today, senior technology executives are being called upon to create solutions that enhance a carrier’s ability to compete – such as those that focus on product development, process automation, legacy modernization, predictive modeling and now the use of big data. While these initiatives are vital for pushing companies forward competitively, there has been little focus on the importance of sound software delivery practices to their success.

At day’s end, the output of every initiative is software, not project artifacts. Effective software delivery practices – which range from the most basic, such as the use of daily build and automated unit testing to Agile delivery methods – are the best way of ensuring the highest quality software. Conversely, the continued use of poor and outdated software delivery practices tends to have a material impact on speed-to-market, execution and delivery outcomes, and it is a contributing factor to the frequency of project failure in the insurance industry and elsewhere.

It is truly amazing, how many project teams struggle to build/unit test their software on a daily basis. If this isn’t done, how are you going to know that the software is working on a daily basis?  No project plan, no matter how sophisticated is going to answer that question. Are you willing to wait until system integration to find out if your software is working? Well, the sad truth is that many of us are today. The focus of most software delivery teams and the supporting PMO processes tends to be the project plan, requirement document and other such artifacts rather than the end product. It represents a misguided focus on the means rather than the end.

One way to focus teams on software solution itself rather than the development process is to shift from waterfall project methodologies – prevalent in the insurance industry today – to Agile/Scrum delivery methods. Insurance IT departments have tended to regard Agile as a more experimental methodology, suited to “greenfield” solutions or those involving non-core business processes. However, there are compelling reasons for the industry to adopt Agile as the norm and relegate waterfall practices to the exceptions. Waterfall has its uses, but a methodology such as Agile is needed to respond to today’s relentless demand for technology-driven business innovation and increased speed-to-market.

Why Agile?

Agile, when done correctly, requires a higher level of discipline than needed for waterfall methodology.  However, the reward for acquiring that discipline is clear. When waterfall is used, many of the issues that plague projects don’t surface until late in the process, sometimes after coding is completed and quality testing has begun. That often results in delays and compromises that erode the promised business value. When using Agile, the same issues are detected early, giving all stakeholders the opportunity to correct faults, keep the overall project on course and achieve full business value.

Which is Riskier, Agile or Waterfall?

Some IT professionals believe that waterfall methods are less risky because requirements are fully exposed before work begins. However, a very strong case can be made that the Agile Scrum and “sprint” approach actually reduces project risk and increases the potential of delivering software better, faster and cheaper. As explained in “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle:

• Scrum copes with the risk of not delivering the desired end product by allowing the business owner/customer to see the product as it is built by delivering software with every sprint.
• Scrum copes with the risk of not delivering all functionality in a release by developing functionality based on highest priority first ensuring all high priority functionality is delivered.
• Scrum methods significantly change the estimation process, which is managed and controlled through the team under the guidance of a scrum master, assessed with each sprint and reported by the team via work effort/completion burn down charts.

Additional Agile Advantages

A study conducted by software productivity researchers from QSM Associates revealed a typical business system comprising 50,000 lines of code was completed 31 percent faster than the industry average in the QSM industry database of completed projects (4.4 months vs. 6.4 industry average).  Michael Mah, who led the research team, indicated the testing defect rate, was four times better than the industry norm. As with all things, your experience may vary, but it’s worth trying given the distinct benefits that can be obtained.

Making the Shift

As with all things bold, a shift to Agile will be exciting but also difficult and fraught with a degree of uncertainty.  The shift will require adaptation across people, process and technology.  Agile requires early, active and ongoing participation by the business/product owner without exception. The adoption and use of Agile/Scrum methodologies needs to become mainstream within an organization in order to achieve accelerated delivery of solutions on a consistent basis.  Finally, to gain the full advantage of Agile, we must exploit technology to reduce and eliminate manual IT processes and provide solutions that optimize the use of IT assets.