Click here to download a .pdf version of this newsletter.

Return to Main Page

In My Opinion
Should We Be Agile?
By Grover Edie, with Brenda L. Kendall, PMP, AIS 

Over the years, both as a company employee and a consultant, I have watched company projects fail to deliver. Often the customer got exactly what was specified, but not what was needed.

Scope creep, distractions, specification changes, and a host of other diversions make the deliverable late, over budget, and not “just what the customer wanted”—even though it might be exactly what the customer ordered!

Our work load does not seem to change. There is never enough time in the day or week to get done what needs to get done. There are many ways to try to organize our projects—the question is: what works best? Is there a method that enables us to better deal with scope creep, changes in priorities, and the other influences that adversely affect the project?

To-do lists work for multiple, small projects, and I use them on a daily basis at work and at home where the projects tend to be short and repetitive. However, at work, one problem with a to-do list is that there are many projects and tasks with varying completion times, complexity, and required levels of concentration (for example, compare taking out the trash to doing your federal income tax return), and the penalty or benefit for the completion or failure to complete each of these projects varies. Some of the penalties increase over time, and some of the benefits disappear if the task is not done by a certain due date. To-do lists work, but they are limited.

The more sophisticated project planning tools, such as MS Project, Gantt Charts, Pert Charts, and so forth, work fine for the large projects, but have too high an overhead for smaller projects. There needs to be something in the middle—say a few hours to a week or two of effort.

In the IT world, the traditional method of delivering reports follows the “waterfall” method: define the business requirements, design the report, write the code, test the report, deliver it, and get feedback from the customer.

For over a year, I have been involved with the data warehouse unit (within IT) of Michigan Millers Mutual (MMMIC), who has been using an Agile method called Scrum. Different from the waterfall method, this process was working so well that we adopted it in our actuarial activities. We found it works just as well for those sorts of activities as it had for IT report generation.

Brenda Kendall is the Scrum master for the Pricing team. I asked her to help me write this column. You can find a lot about this online, so we’ll keep the descriptions short and tell you how we are using it. (See the bottom of this article)

There are many ways to be Agile, and Scrum is just one of them. Agile is an interactive and incremental development framework where requirements, planning, development, and delivery are done in a time-boxed approach by self-organizing and cross-functional teams. Scrum is an Agile method of managing projects or business requests assigned to a team. At the core, Scrum allows the team to focus on delivering the highest business value in the shortest amount of time. Teams are self-organized, which allows them to determine the best way to deliver the business requests. In order for Scrum to be successful, it must be embraced by leadership and be at the core of the company culture.

Once a business request comes into the team, a user story is created in their product backlog by the product owner. The product backlog is essentially an organized list of requests that have come into the team. Each story is business-weighted, or prioritized, by the product owner along with any other customer. In our case, the business weights are assigned by the customers in a group meeting. The heads of commercial lines, personal lines, and marketing all sit together and agree on the importance of each item. Once the stories are weighted and ordered as such in the product backlog, the team estimates the size and effort of each user story. This initial estimate is truly a high-level approximation and is done during an estimating meeting with all customers participating to answer any questions the team has.

Activities are planned in one- to four-week time blocks called “sprints.” We use two-week sprints as they allow a quicker inspect and adapt cycle for continuous improvement. During the sprint planning meeting, the team determines what their capacity is for the current sprint and the product owner determines what the sprint goal is, which provides focus for the team. The product owner reviews the product backlog for the highest business-weighted items, and discussions take place between the product owner and team for each item. It is a negotiation of sorts: capacity versus what the product owner wants delivered within the two weeks. Each user story agreed upon is brought into the sprint backlog and broken down further into tasks and finer estimates until the team capacity is full.

Once the sprint officially begins, the team holds a daily Scrum meeting that generally lasts less than 15 minutes. The purpose of this stand-up meeting is team accountability. Each team member answers three questions: What did you do yesterday? What are you committing to today? What is in your way?

At the end of each sprint is a review meeting. The purpose of this meeting is to report back to the business areas what was completed during the sprint. While there is a lot of activity and communication with the business area during the sprint, the review meeting allows anyone in the company to see what the team has completed, or not completed, during their sprint. After the review meeting is the team retrospective. The retrospective allows the team, product owner, and business areas to reflect on how the sprint went. This includes looking at areas that need to be improved upon and areas where the team has done something good that needs to continue. The team agrees to which items will be incorporated into the next sprint.

In addition to the team, the key roles we previously mentioned are the product owner and the Scrum master. The product owner is responsible for keeping the product backlog groomed, which includes prioritizing the work. The Scrum master is responsible for making sure the team follows the Scrum practices, assists in removing impediments, and facilitates each of the meetings previously mentioned.

My conclusion is that actuarial activities can benefit from other methods of establishing priorities and managing projects, and Scrum is one of those methods we should explore. I’d appreciate hearing from any of you who are already using this method or other similar methods.

Brenda L. Kendall, PMP, AIS, has been a project manager for four years and prior to that was a senior business systems analyst for four years. She has worked in the insurance industry for 17 years. PMP is the Project Management Professional designation by PMI (Project Management Institute). AIS is the Associate in Insurance Services designation by The Institutes (AICPCU).   

Visit the following links to learn more:   

Click here to write a Letter to the Editors

Copyright © 2018 Casualty Actuarial Society. All Rights Reserved.