"We need to become much more agile": top insurance company personnel often make this statement in podcasts, interviews, and blog posts. The topic has been on companies' minds for several years. We have addressed this issue as well. Shouldn't everyone who wanted to become agile have completed this transition by now?
A big misunderstandingAgile methods originate from software development, and this is where they were first tested. The principles of the "agile manifesto" serve as their basis. The word "agile" means to be "versatile and active." Due to factors such as globalization, digitalization, and networking, our world is becoming faster and faster. Faster means that the time intervals between changes or even innovations are becoming shorter and shorter. This ongoing rapid change is called VUCA (volatile, uncertain, complex, ambiguous).
IT managers were happy to identify increased speed as a key benefit of using agile project management. This possible advantage often represents the whole. And this is where a misunderstanding lies. The reason for this is that the manifesto for agile software development states:
we are uncovering better ways of developing software by doing it and helping others do it. Through this activity we have learned to appreciate the following values:
- 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 an industry such as insurance, where there is a lot of tradition and many established players, much time is needed to develop and introduce new products, rates, and business models. That is why agility is seen as the answer to many problems. However, the fact that agility also requires changes at many other levels of a company, for example in cross-functional collaboration and the departure from traditional hierarchies and management principles, is sometimes disregarded or underestimated.
“Agile” is not an end in itself
Disappointments are ultimately the result of expectations that are too high and a wrong approach. Those who have previously taken too much time to implement new product ideas will not assume innovation leadership in their own division overnight simply because agile methods have been introduced, perhaps even imposed, in some departments. And everything doesn't suddenly become a lot faster either where the development of new (software) solutions or products took too long under the burden of outdated IT, bureaucracy, hierarchy, departmental thinking and project descriptions.
Agile methods are neither an end in themselves nor a panacea. They offer the potential to be more "agile," in other words, to adapt more quickly to different circumstances and changing needs. But for a traditional company to approach the much-vaunted agility of insurtechs, it takes a bit more.
Where agility often fails
But what hinders agility in many insurance companies? You'll notice why right away if you consider the work environment. For example, the IT department teams can already work according to agile approaches, but they are dependent on collaboration with internal stakeholders, external service providers and customers, who, however, work according to traditional methodology. This is where agile and traditional methods meet. As a 2020 study by the University of Applied Sciences Koblenz in Germany found, this is not uncommon. For example, 74 percent of the companies surveyed said that they were unable to consistently follow through with agile methods because they had these kinds of working conditions.
However, the study, which is well worth reading, also produced other important findings that point the way to the successful use of agile methods. On the one hand, the responses indicate that distributed teams make agile working more difficult and that success also depends on the size of the teams themselves. With a size of more than ten people, the difficulties grow with respect to benefiting from agile methods to the extent that one desires.
In order to successfully introduce agile methods, however, it is not only a matter of these kinds of conditions. For this to happen, all internal stakeholders need to develop an appropriate mindset. In addition, internal incentive systems must also correspond with the new process models. If both are missing, then it is not surprising if there are problems with the introduction and implementation.
No amount of looking at agile insurtechs for inspiration will help. As start-ups with predominantly young employees who have the appropriate intrinsic motivation, they have fewer problems with agile working techniques.
What could also cause agility to fail (not only) in insurance companies is the assumption that agility can be prescribed. And so the new method is imposed on well-structured processes that have become routine, but then cannot meet expectations.
From milestone to sprint
A large number of positive experience reports lead to the conclusion that agile methods are the better approach when it comes to a project with high uncertainty. For example, when it is not yet clear how the idea can be implemented in concrete terms, or if there are ambiguities in terms of content. In such cases, agile methods actually allow for greater agility. This is because projects that were designed using traditional methods are usually based on a comprehensive, precisely-planned work breakdown structure with milestones, delivery dates, and deadlines. There are numerous logical and content-related dependencies between the individual elements (work packages). In addition, the product or project is not functional until all components or subprojects have been completed and accepted. In contrast, the agile environment proceeds iteratively and in short, time-limited cycles (sprints). The goal is to create a fully-functional element (increment) at the end of each sprint that can be added to in subsequent sprints.
Transparency and communication are success factors
Key to the success of agile software development are transparency and communication. In the linear approach of the traditional waterfall methodology, the definition of milestones enables the project progress to be tracked. In agile environments, such milestones are on occasion skipped, changed, or omitted because new issues or options have arisen in the development process. This leads to misunderstandings with management or the non-agile customer. For this reason, it is important to adapt existing reporting to the new methods.
And finally, agility in an insurance company is also a communication task. This means that all parties involved must understand the reason why this path is being taken. One must assure others that it can be sensible to release software iteratively and not when it has the most comprehensive feature set possible.
The successful implementation of agility (in insurance companies) is therefore also a communication and leadership task, if not a change project that goes far beyond the IT department. It remains exciting to observe how this will be achieved and where the journey will lead.
Learn more about digitalization, agility, and culture change here. If you would like to talk to us about innovative insurance IT, please feel free to contact our expert Karsten Schmitt, Head of Business Development.
