Does Agile work in the Insurance Industry? »

Can it work in today’s insurance industry? Experience has shown a mix of old school waterfall and agile is most affective for the insurance industry and below are arguments to support this:

  • • Strict legal and business impact on technical implementations:
    Like most corporate environments there is always a large legal and business requirement impact when trying to build a technical implementation. Rules and guidelines need to be followed and the most minor requirements in a developers eyes can have a large business and in some cases legal impact. Documenting these requirements in a business requirements and function design documentation can ensure that requirements are not missed. Don’t get me wrong even with the most detailed documentation requirements can be missed but they add evidence and strengthen the business backing and buy in for a project. Documentation also makes the business take ownership of the project and provided evidence of sign off.
  • • Prototyping:
    Prototyping seems to be the most regular used section of Agile across all industries. Prototyping has helped provide companies with a visual aspect of a proposed implementation. In a client’s eyes a picture paints a thousand words; they don’t often care what’s underneath as long as it does what it says on the tin and visually looks appealing. Prototyping then gives the client a visual representation of documentation and lets them see the future in a clear manner.
    When displaying a prototype to a client they can often, there and then start the branding and look and feel discussions. Branding and look a feel can be a nightmare and can often delay deployments due to legal implications and simply down to the client’s requests. What is seen as an easy front end change to a client can often lead to lengthy back end changes, therefore if the client requests can be defined earlier in the requirements gathering phase this can help planning and also decrease the impact of scope creep.
  • • Off-shoring:
    Off-shoring is an ever growing trend in the business environment and can be an area where documentation is needed as a strict guideline. Often is the case with offshore teams, if it is not documented then it is not built. Especially in the insurance environment as stated above strict attention needs to be followed to the implementation of product rules and legal detail/ wording. Documentation in this case gives the developer a clear rule set and guideline to follow.
  • • Iterations:
    We have seen iterations work for implementations where a company could release a live working application to a client in a month. This had a standard structure but could provide the client with basic online insurance capabilities in a short period of time. This application was built onsite and had little documentation. Currently iteration 2 is being built to provide the client with more functionality.
    This shows that the Agile structure can work but this application was built following existing and in use white labelled software and was carried out by developers who had built similar applications.
    Luckily the client provided buy in early for this development and was satisfied to stick to the standard structure being implemented by the development company.
    If on the other hand that the client wanted a totally different implementation then documentation would be needed to ensure all requirements were followed.

Agile seems to work in environments where you have an experienced team that know exactly what they are doing but documentation cannot be overlooked in an environment where legal implications are highly prominent. Evidence and business buy in needs to be documented to decrease scope creep and the ever present situation where a client says “I never asked for that to be built”.

© Copyright 2020 3CA PTY LTD

Sign Up to our email newsletter!

I agree...
Sign Up Now