Home

Eight Years of Agile Journey in the Insurance Business in Indonesia

David Bejar, Head of DevSecOps& Agile Practices,Allianz Indonesia

David Bejar, Head of DevSecOps& Agile Practices,Allianz Indonesia

Allianz Indonesia started its journey towards agility in 2014; our IT projects were then often painful: they were late, individual heroics were required, users protested that the output wasn’t what they expected, deploying to production ended in rollbacks, major bugs were found after launch, changes were requested when project was already closed… Fast forward three years, we concluded 2017 making 50 deployments to production a month; moving to present day, we closed 2021 making 100 deployments to production a month, over 3.2 changes per day! Today, our business colleagues and our customers are happy with our digital solutions, IT no longer objects to or delays changes; we embrace change and deliver it at speed, all while employee engagement polls reflect that we have now a much happier IT talent.

I was there when we started in 2014, I was not alone and can’t talk on behalf of others, this is just my side of the story. To be frank, I was skeptical and arrogant about us ever becoming truly Agile. Skeptical because how on earth would we change our way of doing things in an environment like ours, a company in a highly regulated industry, an organization entity of a multinational with strict controls over its remote entities, and an organization operating in the insurance business which is conservative by design. Arrogant because I thought I got it, I thought I understood Agile, I had informed myself, attended a couple of trainings, and I had experience delivering value and fixing projects in trouble; I was convinced that was it, we were where we could be, there was not much more. Yet, there was this promise of delivering more value with happier employees that kept me going, digging, trying, I saw the frustration around me, what if it was possible to change that?

To go from there and then to here and now we had to shift teams’ culture: we organized full-time dedicated engineers around applications, moved away from time bounded projects, got business more frequent and closer involvement into development, fought for team autonomy, etc.

We also had to shift teams’ skills: enhanced engineering practices, introduced new skills and practices such as DevOps or UX into the teams, we hired coaches and we grew coaches from within, etc.

These coaches, by the way, webbed a support system that allowed us to sustain the improvement rate even during the toughest times of the pandemic, when sales were dropping and individuals were scared or sick, that is, when our fluency was put to the test.

Business needs IT to be Agile, but IT doesn’t operate independently, it shouldn’t. For IT to perform those team’s culture and skills shifts we had to also drive shifts outside IT. Moreover, IT steady improvement in agility moves the system bottleneck to other functions of the organization that struggle to adapt to the frequency and speed of change of IT. Consequently, there were other shifts we had to commence to work on during the last few years, such as organizational structure and culture shifts: we are adding business expertise inside the teams, boosting market focus, optimizing cross-organization value streams, etc.

What we think is our most valuable lesson learned after all these years is that one must make mistakes to learn, when it comes to achieving agility, it is not possible to learn from someone else’s mistakes, only from your own errors. How we got to where we are today is a long story that is not portable, because our organization, like yours, is a complex adaptative system. The experiments that we ran along our way towards agility helped us to learn and, at the same time, transformed the problem that we were to face next regardless of whether our experiment was a success or a failure. Yet, what for us didn’t work might be positive at your organization.

Business needs IT to be Agile, but IT doesn’t operate independently, it shouldn’t. In order for IT to perform those team’s culture and skills shifts we had to also drive shifts outside IT

Our second lesson, is that we only did progress, evolve, improve, and sustain because we had internal champions and senior sponsors. It is easy to be fooled by Agile panacea peddlers, sometimes we were, but there are no simple solutions to complex problems, in example, we now don’t believe that by changing the organization structure, creating new standards and policies, and forcing new methodologies, an organization will become Agile. In one hand, because it is not an Agile approach to change (where are the feedback loops?), in the other because it won’t change your organization’s fluency.

When we are reached out by colleagues working at FSI organizations from across the APAC region seeking for guidance on where to start, or how to progress, their eventual reaction would mention that they can’t be more agile because the regulator, auditors, culture, etc. I get it, I was there in 2014. If there’s no determination, an internal push, a firm conviction that this is the right thing to do, not just for the business and the customers, but also for your coworkers, there won’t be a way around the obstacles. If you got that drive, there will be a path.