Actuarial Outpost
 
Go Back   Actuarial Outpost > Actuarial Discussion Forum > Software & Technology
FlashChat Actuarial Discussion Preliminary Exams CAS/SOA Exams Cyberchat Around the World Suggestions


Reply
 
Thread Tools Search this Thread Display Modes
  #11  
Old 09-30-2016, 01:26 PM
Neutral Omen's Avatar
Neutral Omen Neutral Omen is offline
Member
SOA
 
Join Date: Oct 2011
Favorite beer: Kwak
Posts: 6,990
Default Agile development in insurance

For posterity, here is my prior company's (tech firm) agile process in practice:



Start with a queue of tasks.

First cycle begins.

Week 1: a week of planning (estimate task time, available dev resources, customer priority, etc)

Next 2 weeks are dev. Developers get a queue of tasks to be done in this cycle, and get busy. They work in a Development Environment.

By week 4 we roll out a release to the Testing Environment. Testers begin to test and log bugs. Week 4 the Developers focus on debugging.
- In the meantime, business analysts and product begin to plan the 2nd cycle. Note dev resource availability here depends in part on how buggy Cycle 1 is.

At week 5 the bugs slow down, so developers alternate between bug fixing and new development for Cycle 2.

Week 6: Cycle 1 is now debugged. It sits in Staging Environment where Tech Support can get comfortable with the new updates. Also, our Media people work on buzz around the new updates.

Weekend before Week 8, Cycle 1 is pushed to our customers. Monday they all get spammed with media buzz and training webinars.

All throughout this process, customer feedback trickles into our queue of tasks.

Benefits:
- customers get a regular stream of updates
- all resources are utilized at all times. Devs always have work from some cycle. Business people are always planning or evaluating. Media people always have work. Tech people always have new featuers to learn.
- critical customer feedback (or what our CTO wants) and critical bug fixes can be implemented in 2 months tops. Contrast to 2+ years for waterfall.

kapish?
__________________
Spoiler:


Quote:
Originally Posted by mathmajor View Post
you are a visionary

Last edited by Neutral Omen; 09-30-2016 at 01:30 PM..
Reply With Quote
  #12  
Old 09-30-2016, 01:55 PM
BenKester's Avatar
BenKester BenKester is offline
SOA
 
Join Date: Sep 2013
Location: Des Moines metro
College: Northwestern College (IA)
Favorite beer: Stouts
Posts: 9
Default

How important are early updates and/or customer feedback?

From the pension consulting area:
1. For government filings, agile doesn't add anything.
2. For annual valuations, maybe not a ton either. You're not going to significantly change your report based on what the customer wants.
3. For other projects like projections, there could be a lot of value in at least a hybrid approach. Rather than putting all of this time into fancy graphs, share your preliminary results with the client before the decision for a full report.

However, once you get into sharing half baked work with the client, you run into all the ASOP 41 issues. The profession has already been down this route and leans towards full analysis + full communication.

A core value with agile is the customer knows best. They know their business needs better than the devs. They are paying the bills. So let's make this process so the customer gets what they want. One reason agile hasn't taken off is actuaries don't hold that premise.
__________________
“All of humanity's problems stem from man's inability to sit quietly in a room alone.” - Blaise Pascal
Reply With Quote
  #13  
Old 09-30-2016, 02:50 PM
Neutral Omen's Avatar
Neutral Omen Neutral Omen is offline
Member
SOA
 
Join Date: Oct 2011
Favorite beer: Kwak
Posts: 6,990
Default

Never try to think of a "hybrid approach" between waterfall and agile, it is an antipattern and a very bad idea. Typically this is the first thing that comes to management's head..."we'll be geniuses and slowly transition to agile", which basically means release crap product mid-way through your waterfall.

What you are describing is validating client requirements.

You can't "agily" file stuff with the government. You can file wrong stuff and fix it later. I think you're heading down the wrong path here.

Agile is a methodology for development of software. So your actuarial tools (spreadsheets, etc) can be developed using agile. But performing actuarial work would require you to invent a new and separate methodology from Agile.
__________________
Spoiler:


Quote:
Originally Posted by mathmajor View Post
you are a visionary

Last edited by Neutral Omen; 09-30-2016 at 03:03 PM..
Reply With Quote
  #14  
Old 09-30-2016, 03:11 PM
Neutral Omen's Avatar
Neutral Omen Neutral Omen is offline
Member
SOA
 
Join Date: Oct 2011
Favorite beer: Kwak
Posts: 6,990
Default

IIRC Agile was motivated by two reasons not addressed by Waterfall:
1. maintain customer engagement, addressed by frequent updates. Are you looking to maintain continuous engagement by your regulators? (typically you want the opposite)
2. continuous use of human resources in all departments (see my example for how this is addressed). Are your actuaries short on work? Are you looking to have them continuously engaged in preparing filing materials? (typically no, you want to get this stuff out and over with asap, and move on to other projects)
__________________
Spoiler:


Quote:
Originally Posted by mathmajor View Post
you are a visionary
Reply With Quote
  #15  
Old 09-30-2016, 03:21 PM
Neutral Omen's Avatar
Neutral Omen Neutral Omen is offline
Member
SOA
 
Join Date: Oct 2011
Favorite beer: Kwak
Posts: 6,990
Default

Note that Agile is not a sequence of waterfalls. It is the continuous progress on various planned releases. Its agility comes from your ability to set the scope of each release in accordance with your available resources.
- So if in one cycle your people are free to focus, you can roll out new features.
- Next you got a lot of training, so you can just have a release of customer-identified bug fixes.
- If you got a huge enhancement that'll take several months, you can make incremental progress on it while still planning some minor changes along the way to provide some news to your customers.

Contrast to waterfall, where you might plan for a few months. Then you better have availability of all your resources for the next 2 years at the correct time to meet your timeline.
__________________
Spoiler:


Quote:
Originally Posted by mathmajor View Post
you are a visionary
Reply With Quote
  #16  
Old 09-30-2016, 04:11 PM
Jon Marshall Jon Marshall is offline
CAS AAA
 
Join Date: Jan 2014
Location: Reno, NV
College: Brigham Young (BS Math), Minnesota (MS Industrial & Applied Math)
Posts: 3
Default

I would argue that a lot of internal actuarial tools are actually created using a fairly Agile process. You've got short deadlines, you've got a very flexible platform (often Microsoft Office with some technical add-on like R or Matlab), and already you've got a close connection with the business (either underwriting or finance) and the developer (actuarial). The actuary usually has a really good idea both of what is needed and an idea of how to get there. So instead of spending a ton of time formally scoping out the project, the actuaries kind of just jump into it and start developing, checking in regularly with the business.

Over time, as the tools become more sophisticated and widespread in the organization, you need a more robust platform than Excel or Access alone can give, and you tend to fall into a waterfall approach for IT to systematize it. This can get very frustrating for the actuary, who already has a tool that meets all of their requirements except those prevented by limitations of MS Office and would like to just have IT port it over to a better platform.

For this reason alone, it's good to get IT involved early even in custom actuarially-developed tools. They can help with best practice on modular design, data architecture, security, and version control that may be a little painful in the initial development, but will pay huge dividends when they eventually take it over. I've seen this work really, really well, and it's very satisfying when you can get an honest-to-goodness synergy where Actuarial gets IT's perspective and IT gets Actuarial's.
Reply With Quote
  #17  
Old 10-01-2016, 10:19 AM
PeppermintPatty's Avatar
PeppermintPatty PeppermintPatty is offline
Member
CAS
 
Join Date: Sep 2001
Posts: 39,061
Default

Agile is obviously unsuited to filing rates with a state. But it might work for developing internal pricing tools.

My friends in computery fields like it.
Reply With Quote
  #18  
Old 10-04-2016, 10:58 PM
oedipus rex's Avatar
oedipus rex oedipus rex is offline
Member
SOA AAA
 
Join Date: Nov 2002
Favorite beer: too many to list here
Posts: 15,352
Default

Quote:
Originally Posted by Jon Marshall View Post
I would argue that a lot of internal actuarial tools are actually created using a fairly Agile process. You've got short deadlines, you've got a very flexible platform (often Microsoft Office with some technical add-on like R or Matlab), and already you've got a close connection with the business (either underwriting or finance) and the developer (actuarial). The actuary usually has a really good idea both of what is needed and an idea of how to get there. So instead of spending a ton of time formally scoping out the project, the actuaries kind of just jump into it and start developing, checking in regularly with the business.

Over time, as the tools become more sophisticated and widespread in the organization, you need a more robust platform than Excel or Access alone can give, and you tend to fall into a waterfall approach for IT to systematize it. This can get very frustrating for the actuary, who already has a tool that meets all of their requirements except those prevented by limitations of MS Office and would like to just have IT port it over to a better platform.

For this reason alone, it's good to get IT involved early even in custom actuarially-developed tools. They can help with best practice on modular design, data architecture, security, and version control that may be a little painful in the initial development, but will pay huge dividends when they eventually take it over. I've seen this work really, really well, and it's very satisfying when you can get an honest-to-goodness synergy where Actuarial gets IT's perspective and IT gets Actuarial's.
I'd agree with this and point out that the actuarial control cycle is actually very similar to the processes that coincide with an agile development cycle (where you are improving on a work product each "release"/valuation date)
__________________
Life can only be understood backwards; but it must be lived forwards. --S.K.
Reply With Quote
  #19  
Old 10-05-2016, 08:00 AM
whoanonstop's Avatar
whoanonstop whoanonstop is offline
Member
Non-Actuary
 
Join Date: Aug 2013
Location: Los Angeles, CA
Studying for Spark / Scala
College: College of William and Mary
Favorite beer: Orange Juice
Posts: 5,865
Blog Entries: 1
Default

Quote:
Originally Posted by oedipus rex View Post
I'd agree with this and point out that the actuarial control cycle is actually very similar to the processes that coincide with an agile development cycle (where you are improving on a work product each "release"/valuation date)
I made a bet with myself that I'd never hear this term outside of the FAP modules, but it appears I was wrong.

-Riley
__________________
Reply With Quote
  #20  
Old 10-05-2016, 08:53 AM
Marcie's Avatar
Marcie Marcie is offline
Member
CAS
 
Join Date: Feb 2015
Posts: 8,853
Default

Quote:
Originally Posted by whoanonstop View Post
I made a bet with myself that I'd never hear this term outside of the FAP modules, but it appears I was wrong.

-Riley
So what do you lose (win), Riley?
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -4. The time now is 04:08 AM.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
*PLEASE NOTE: Posts are not checked for accuracy, and do not
represent the views of the Actuarial Outpost or its sponsors.
Page generated in 0.16035 seconds with 9 queries