i
A “new” way of working
You’ve probably heard about agile teams, software development, and other applications. Agile is the newest weapon in the software development tool kit (though the term has been in use for 20 years or more), and it’s believed to be a panacea for all manner of programming challenges.
While agile methods have distinct advantages over non-agile methods (we’ll discuss those a little bit more), we just wanted to point out that these two are ends of a spectrum of how work gets done, not so much of what the code specifically is. Agile is the “very short cycle” end, while waterfall is the “only one long cycle” end.
This kind of training on how to do it seems to be missing from many actuarial development paths. Most actuarial training is technical, not process-oriented. Younger actuaries are told what to do (calculate a reserve, develop a new recording database, build a key indicator reporting system), but not trained on how to do it.
Yet the concept of a development cycle does somewhat parallel the Actuarial Control Cycle, in which problems are addressed using three repeated steps: define a problem, design a solution, and monitor the resutls.
However, actuaries are often used to years-long cycles. Historically, it has taken a long time to design a product; set up pricing parameters; get approvals; sell policies; see claims; measure statistically significant differences; realign the pricing parameters and solve again for the new rates. Potentially years.
The process then is not that different for software tools. In general, agile methods and waterfall methods have very similar components. Just differ on whether things happen linearly or in parallel and over what time frames.
Waterfall methodology explained
This is the historic way that software was developed. It emerged from past practices of developing pretty much anything else, where someone decides they need a thing to solve a problem. They decided what it should do, they built it, they figured out whether it worked, and then they applied it to the problem.
The term “waterfall” comes from the linearity and the strict hierarchy of completion for the various elements before progress can be made to the next step. Those steps are illustrated below:
Those terms are all fairly self-evident, so we aren’t going to spend a lot of time explaining them. What’s important is the cascade effect, where, for example, “System Design” can only take place after all “Requirements Analysis” has completed.
Obviously, this served the software development industry well for a while, so there must have been some positives of using this method. We can think of a few.
Pros of waterfall development
First, there is a high level of control both of the individual elements as well as the order in which they fit together. Plus, there is a clear definition of what’s required for success: completion of each stage on or before the approved timeline.
And there is always a great deal of transparency into what’s on schedule, what’s ahead or behind, etc. It’s easy to see where you stand when using waterfall methods.
Cons of waterfall development
Let’s start with the fact that it’s a rigid and inflexible system. This may have been good in the early eras of software, when requirements could be clearly defined and capabilities were limited. However, with today’s modern interconnected world, it seems as if changes happen daily. The inability of the waterfall model to handle late changes without a “change process” limits effective application.
As well, late identification of unforeseen issues which were not discovered during requirements planning often leads to either late delivery or pushing additional features to “Phase 2” projects, which may not even happen.
However, the biggest problem is that there really isn’t anything workable or usable until very late in the process. Leaving very little opportunity to correct if it looks like things are going off course.
Agile methodology explained
In contrast, “agile” methods (of which there are several) break the process into smaller cycles. These smaller cycles may have their own waterfall-like structure, but the major difference from historical development methods is that agile drastically shortens the cycles and involve end-users much sooner to get fast feedback early.
The Agile Manifesto highlights the mindset that is embodied in these faster-speed-to-value methodologies:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
[Side note, we highly encourage you to read the Twelve Principles of Agile Development. It’s not long and can significantly impact your mindset towards actuarial model development in more responsive ways.]
We think the pros of agile development are many.
Pros of agile development
It’s faster to get to some kind of working product. It’s faster to learn what’s working and what’s not, because end-users are involved much earlier in the process. As well, changing requirements are easier to incorporate, because the cycles happen so much quicker.
Agile development breaks down a lot of the silos that tend to restrict faster development. Teams who work this way see faster results because they’re organized across disciplines and are often trained to communicate clearly about expectations, interactions, and what they need.
It can’t be all positive
Yes, there are some cons to agile methods, which it would be foolish of us to ignore. Not the least of these is that customers are fickle, so if you keep asking them what they want, there’s a chance they will keep changing their mind and moving the definition of “done”.
There isn’t a good way to handle complex dependencies, i.e. if there are many precursor steps. Some teams may sit idle because they have either completed their parts and are waiting for other groups to churn, or they are the ones continuously churning and holding up those who are dependent on them.
Finally, there may be a lack of documentation and an absence of a clear chain of authority (or a history of changes) if all requirements are not laid out at the start, so that they can be checked off as completed.
Is it really that popular?
So why has “agile” become so popular? Or is it even that relevant anyway? Maybe it’s just a fad.
A quick search on Monster.com for jobs in software development illustrates the relative importance of agile skills compared to waterfall skills:
- Software development waterfall: 2,778 jobs
- Software development agile: 45,294 jobs
This is over 20 times the number of jobs that mention agile compared to those who mention waterfall. Like the natural world, the idea world also has competition. If there’s this much of a differential, it’s clear that agile software development is destroying the competition. In the future, we believe that virtually all software will be developed using agile principles.
And it’s not just software. The success of agile development has inspired other professions to seek to apply the same mindset to their processes. Marketing, engineering, and even public radio programming are seeing improvements in their development processes by applying agile principles. (When applied correctly, that is.)
How does it relate to actuarial work?
We’ll get into the specifics of how to apply agile to actuarial output in the next article. Model conversion (to a new system) seems to be a popular project these days, and one where agile methods would work well. It’s also applicable for building new models or functionality (IFRS-17 or GAAP LDTI, for example), and even process improvement of what you’re currently working on, such as experience studies or pricing cycles.
For now, we’ll ask how an agile mindset at your actuarial software vendor might affect your user experience.
Is your actuarial software developed in an agile shop? Are you, the end-user customer (or a proxy who looks a lot like you) involved in testing and vetting requirements through early feedback? Are releases happening frequently so that you are always on the “latest” version? Or is there a lot of lag between requirements definition and the time when you can finally implement?
If not, then you’re clearly getting the pros and cons of the waterfall development above. You’re getting rigid functionality delivered slowly in large, disruptive blocks.
You’re not getting the pros and cons of agile development, which include perpetual improvement delivered rapidly and in small, easily-incorporated chunks.
If you’re not getting an agile-developed product, how will that be adequate for your rapidly-changing working environment?
As well, agile development naturally fits with software as a service (Saas). Because SaaS providers have such an incentive to continuously improve on their user satisfaction, they also have an incentive to be continuously rolling out new features and enhancements. Rather than waiting for long times between large dump releases that may be stale by the time the vendor gets around to them.
The advantage for end-users is clear, as evidenced by the growing popularity of SaaS delivery of applications for everything from gaming (eSports) to project management (Monday.com) to distributed communications (Zoom).
The combination of agile development and SaaS delivery creates a positive feedback loop for end-users and the vendors. It’s a win-win-win and we expect that some time soon there won’t be any (or very little) work for waterfall-type development shops.
Okay, but what about actuarial calculations?
In the same way, we believe that agile ways of working in your actuarial teams is the way of the future. We’re not alone. Tim Fleming, of Guide One Insurance, says that the modern actuary “Works like an entrepreneur. Focuses on the real-world problem, not the actuarial solution. Works iteratively, experimenting and failing fast.”
And E&Y, no slouch when it comes to forecasting the future of work, had this to say: “The challenges and changes facing insurers, while difficult, are also opportunities for transformative change. Agile companies with a strategic focus can emerge as industry leaders, stronger than ever.”
“The challenges and changes facing insurers, while difficult, are also opportunities for transformative change. Agile companies with a strategic focus can emerge as industry leaders, stronger than ever.”
“What is the future of actuarial in insurance?”, ey, 2020
Don’t get any illusions that the rest of your company can transition to modern, agile methodologies and still accept slow, traditional output from their actuaries. You’re good, but you’re not that good.
We’ll dive deeper into these perspectives next time when we talk about how agile development may help you transform your actuarial work into an Actuarial as a Service center of excellence.
As we said, we believe this is the way of the future. It’s time to advance your actuarial practice, and the first step is on that journey to the future state is to apply SaaS, developed using agile principles, in your everyday work. Your innovation teams, your “financial modernization” teams, and your Chief Actuary will thank you
Next time:
How your actuarial team works: Agile vs. waterfall production cycles