Session 69: Case Study: Lean-Agile Product Development for Wearable Accidental Death

Insurance SOA Antitrust Disclaimer SOA Presentation Disclaimer

Applying Agile Methodology to Actuarial Modeling

Steven ShermanAIGVice President, L&R Model Operationssteven.sherman@aig.com

May 2019

2

Review the concepts associated with the Agile & SCRUM development lifecycle How Agile is can be used by Actuaries to deliver models more nimbly, reliably and

efficiently. We will contrast the agile methodology with other approaches such as waterfall and

explore the benefits of adopting the Agile methodology. Understand the agile team, roles and responsibilities We will also review the real world challenges faced with applying agile techniques

specifically to actuarial modeling and provide lessons learned to help provide proactive ways to overcome these challenges and be successful in adopting an agile approach to actuarial model development.

Learning Outcomes1) At the conclusion of the session, attendees will be able to2) Explain the end to end agile process and the benefits over traditional

development methods3) Understand Agile teams cooperate and collaborate to deliver business value4) Identify where Agile techniques can help to help drive efficiency in Actuarial

model development

Agenda

3

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable products.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working products frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support

they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation. 7. Working software is the primary measure of progress.8. Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility10. Simplicity – the art of maximizing the amount of work not done – is essential.11. The best architectures, requirements, and designs emerge from self-organizing teams.12. At regular intervals, the team reflects on how to become more effective, then tunes

and adjusts its behavior accordingly.

4

Benefits of the Agile / SCRUM MethodologyThe Agile / SCRUM methodology provides continuous and frequent delivery of working model components in small, iterative increments, insuring delivery of the highest value features for the business.

Emphasizes Collaboration

Improves Budget Management

Catches issues early

Adaptable to changing needs

Continuous improvement

More efficient use of resources

More effective prioritization

Stakeholders are integrated

Continuous, frequent delivery

Improves communication

Allows for course correction

Improves quality assurance

5

Anatomy of SCRUM

Product Owner

• Maximizes Value

• Works with stakeholders

• Prioritizes work• Insures

Understanding

Development Team

• Builds the product

• Cross Functional

• Self Organizing• 3-9 members

Scrum Master

• Insures SCRUM is efficient

• Leads by helping

• Coaches team • Helps break

blockers

Roles

Sprint Planning

• Determine what can be delivered

• Establish Sprint Goal

• Plan the work of the sprint

Daily SCRUM

• 15 minutes• What did I do

yesterday• What will I do

today• Do I have any

blockers

Sprint Review

• Demonstrate Deliverables

• Stakeholders Attend

• Business discussion

Retrospective

• Continuous improvement

• What went well

• What can we do better

Events

Product Backlog

• Ordered list of all deliverables

• Responsibility of the product owner

• Constantly refined

Sprint Backlog

• Highest order items from the product backlog

• All the work required to meet the sprint goal

Scrum Board

• Manages the flow of the work

• Facilitates Daily SCRUM

• Tracks done• Burndown

chart

Artifacts

Product

• A holistic deliverable that provides value to the business

• Must satisfy a firm’s need or desire

User stories & Epics

• User stories are the Primary development artifact of SCRUM

• Requirements• Epics Are large

bodies of work comprised of user stores

Deliverables

SprintThe Increments of Time That The Product Will Be Delivered, typically 2-4 Weeks

6

The Agile / SCRUM High Level Process

1. The SCRUM team maintains a backlog of all required work

2. The Product Owner works with stakeholders to establish priorities

3. An end to end team is assembled, representing Development, QA, Production, Product owners, Users and Stakeholders

4. The team only works on what can be delivered within a sprint, typically two weeks

5. Every day, a 15 minute daily SCRUM meeting is held, attended by all team members

6. At the end of each sprint, a quality assured, production ready set of deliverables is produced.

7. A retrospective is performed at the end of each sprint to address issues, reprioritize as required and continuously improve

7

The Agile / SCRUM Process

8

Our Fictious ProjectThe fictious project we will use to facilitate this presentation is the development and delivery of a market data dashboard

9

How to Write an Effective User Story

An Effective User Story

As a <type of user>, I want <some feature> so that <some reason>

As a <type of user> — This is the WHO. Who are we building this for? Who is the user?

I want <some feature>— This is the WHAT. What are we building? What is the intention?

So that <some reason> — This is the WHY. Why are we building it? What is the value for the customer?

INVEST In Good User StoriesIn order to create good user stories, start by remembering to invest in good user stories:

Should not be as independent as possible

Independent:

It is an invitation to a conversation

Negotiable:

If it does not have value, it should not be done

Valuable:

Has to be estimated to be properly prioritized

Estimatable:

Do the simplest thing that works, then stop

Small:

Every story needs to be testable in order to be DONE

Testable:

10

How to Break Down User Stories, Epics and ProductsUser stories are smaller granular components, which make up epics, which make up the product

A

User Story Examples

A. As a model owner I need to be able to filter specific indices for market analysis

B. As a Financial Analyst, I need a chart with the SPX to understand specific market trends

B

Epic Example

A. Delivery of a chart comparing multiple indices for multiple time periods for specific attribution analysis

A

B

C

C

Product Example

A. Delivery of a comprehensive market data dashboard with a snapshot of all market data that effects reserves and capital allocation, measured over time to allow senior management to make informed business decisions based on market movements

D

D

Be creative when thinking of how to break up deliverables into smaller user stories to fit within the defined sprint cycle, which is typically two weeks

11

Story Points – The Key Metric

Planning Poker Assign Story Points Work Quantity

Assign story points to each user story

In aggregate, is the quantity of work in the sprint and backlog

Velocity

User stories completed represents the team’s sprint velocity

A technique of estimating whereby the team make estimates on each user story by playing numbered cards. The cards are revealed, and the estimates are then discussed. The entire team votes, not just specific subject matter experts.

Every User story in the backlog is issued story points. Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a user story

The aggregation of all story points in the backlog represent the overall work required to complete the project. A specific number of user stories will be placed in a sprint. The number of user stories in a sprint is based on the aggregation of story points & how much the team can accomplish

Velocity is a measurement of how many story points the team is able to deliver in a sprint. This is typically calibrated over the course of several sprints. Velocity is critical to setting priorities, setting stakeholder expectations and sprint planning

Story points are critical to the Agile / SCRUM process. The following depicts how they are established and how they are used.

12

The SCRUM Board – Defining and Managing the SprintBacklog In Progress Testing DoneSprint To Do

3

1

5

3

1 3 3

1

80 Story Points 9 Story Points 4 Story Points 3 Story Points 4 Story Points

• The SCRUM Board is the main facilitation tool for the SCRUM process• Physical or virtual task board consisting of all the user stories (work) to be completed in a sprint• As the sprint progresses, cards with the documented user stories are progressed from left to right• The team members themselves self-assign user stories and move them as they progress• The Scrum Master facilitates the process and helps break blockers, but does not assign tasks• By the end of the sprint, all user stories should be in the done column (done means “done”)• Any incomplete user stories are considered hangover

13

Daily SCRUM MeetingA daily, 15 minute time boxed daily meeting, attended by all team members used to synchronize activities and create a plan for the next 24 hours

The daily SCRUM meeting• Makes the team more productive and efficient• Improves communication• Eliminates other meetings• Identifies impediments for removal• Highlights and promotes quick decision making• Improves Development Team’s level of knowledge

During the SCRUM meeting, every team member articulates• What I did yesterday• What I will do today• What is getting in my way or keeping me from doing my job

Bad habits that ruin a SCRUM meeting• Using the meeting as a status report for management• Trying to solve problems during the meeting• Discussing things not part of the SCRUM• Using the meeting for future planning• Allowing the meeting to get off track• One team member dominates the meeting

14

Sprint Burndown – Measuring The Team’s VelocityThe Scrum Burndown Chart shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to help insure the project is on the track to deliver the expected solution within the sprint.

It helps the team to understand and calibrate their velocity, which is the key measurement of how much work the team is able to accomplish in a sprint.

15

Hangover – The Key to Measuring and Managing Project Risk

Hangover user story

Sprint120 story points

Sprint220 story points

Sprint320 story points

Sprint420 story points

Sprint520 story points

When a user story does not get completed within it’s planned sprint, it is hangover. Hangover is your key warning signal that there may be an issue with the project and allows you to adjust very early on in the project lifecycle.

• Hangover in a single sprint should be considered a warning signal• Hangover in multiple sprints should raise red flags• Any given sprint can only accommodate a certain number of story points based on the team’s

velocity• Any hangover requires an adjustment of some kind as the user story has to be accommodated

in another sprint. • Adjusting scope can be accomplished by removing a lower priority user story, simplifying the

requirements of an existing user story, or adding team members• Hangover is the key to continuous improvement throughout the project lifecycle.• Retrospectives help the team to understand the root cause of hangover and adjust

accordingly

In the following illustration, we have 5 story points of hangover in the first sprint. The challenge is figuring out what to do with it.

16

SDLC Practices that impede Agile Effectiveness

• Lack of proper organizational structure• Lack of development standards• Lack of subject matter expertise in enterprise

software development• Lack of IT involvement• No disciplined change management process• Too many changes• Lack of adequate testing• Models delivered to production late• Inability to flex and adapt to change• Deliverables do not meet stakeholder

requirements

SDLC Practices that Compliment Agile

• Solidify roles & responsibilities across teams• Implement & enforce development standards• Utilize test driven development practices• Utilize ticketing system to manage change• Implement governance, peer & tech reviews• Develop in modularized, plug & play components• Standardized & automate testing processes• Implement disciplined change mgmt process• Utilize version control and automated release

management tools & processes• Establish holistic communication protocols• Include stakeholders in the development process

The Software Development Lifecycle plays a significant role in the effectiveness of AgileSDLC Practices That Impact Agile Effectiveness

17

Waterfall

• Detailed, up-front specifications of features, requirements, and user expectations

• Comprehensive design of the entire product before any development work is performed

• Advance creation of complete plan, estimate, and schedule for the development of the entire product

• Acceptance or rejection by the user of the entire finished product

• Top down management and control of the process • Primary measure of the progress is typically the plan • Aversion to change which costs money and time• Big bang implementation/delivery• Responsibility of success falls on project management

Contrasting Agile with WaterfallAgile

Production Release

Candidate Every Two

Weeks

2 Week Sprints

Agile Methodology

• Continuous engagement and participation is an integral part of the project

• Iterative, incremental delivery of work• Incremental opportunities to adapt to develop a

product in line with user’s needs• More opportunity to innovate and course correct• Team members serve each other and self organize• Primary measure of the progress is the working

product• Provides the ability to create and respond to change. • Deliver incrementally to increase ROI and customer

satisfaction• Responsibility for success is shared across the team

Waterfall Methodology

18

Challenges Actuarial Teams Face in Adopting Agile

Challenges

• Lack of proper organizational structure• Lack of Agile / SCRUM training for team

members• Inexperienced product owner• Inexperienced Scrum Master• Scrum Master does not understand the

subject matter or business• SCRUM is not tailored to fit the culture• Difficulty in seeing how to break the work

down into smaller deliverables that can be achieved within a sprint

• Testing models can be time consuming and can consume many hours of the sprint, significantly slowing iterations and velocity

• Gaming the process to claim the team is doing SCRUM, but really is doing waterfall

• Lack of participation in the various meetings

Remediations

• Solidify roles & responsibilities across teams• Insure all team members are trained in SCRUM in• Insure product owner is well trained and

expectations of the role is well understood• Scrum Master should be experienced or a coach

should be assigned to assist• Scrum Master should take the time to understand

the subject and business to be a better facilitator• Strive to preserve key principles, but understand

the culture and how to fit SCRUM to it• Be creative in looking at all the ways to define a

deliverable. It only has to be an atomic demonstratable component

• Consider use of test beds, clustering or statistical sampling in testing to reduce test time

• Be clear. Done is done – from development through to testing to QA. Don’t put development in one sprint and testing in another

• Be sure team members are committed and made available for the process

Have fun, enjoy the process, enjoy the teamwork, enjoy the collaboration, enjoy the results!

19

The RetrospectiveThe retrospective is the key to continuous improvement. The team should strive to improve each sprint by being open, transparent and self reflective about what went well and where can we improve.

20

Retrospective for this presentationThank you for your time! Don’t forget to take the survey so that we can continuously improve for future SOA presentations!

Were your goals met?

What did you find helpful to you and your team?

Where can we improve?

Any suggestions for future presentations?