Agile or Not Agile: That Is the Question

Problem

One of the key challenges working in the traditional healthcare sector -- and especially insurance -- is that development cycles move dramatically slower compared to consumer or SaaS startups because of the lack of continual feedback. In dental insurance, our customers would typically enroll once a year or go into the platform twice a year. Insurance is widely considered as an emergency rather than a product people engage with repeatedly.

However, our company was all set up to follow Agile best practices. We were running Scrum, had two weeks sprints, and adhered to the build, test and learn methodology, but we were not getting enough information back. In addition, things we needed to build couldn’t fit into two-week sprints -- even when we could complete the code, we couldn’t ship it because of compliance, regulatory, and other go-to-market constraints.

Actions taken

We decided to find a version of the software development framework that would allow us to keep what we believed were Agile best practices. We wanted to preserve the team autonomy, the ability to learn fast and change direction when needed. Yet we needed longer cycles and to be able to go more on intuition and less on data than what Agile is set to do.

We assessed a variety of frameworks with the goals of having longer cycles time, more resilience to the lack of data, and the ability to ship asynchronously to the code. What we ultimately landed on was the Shape Up framework.

Once we have decided on a framework, we started to slowly move the organization to the first two longer cycles. We developed six to eight weeks cycles and were willing to work on a particular feature only if it would take six weeks. If we could do it in six weeks we would ship it; if we couldn’t do it in six weeks we would pass it on.

We also enforced building our analytics into the front instead of the back half of the process. Agile traditionally prescribes that you build something, measure it, ship it and see how it goes. Instead, we would put upfront a lot of measurement of a variety of common use cases and then we would rely on our business insights team to predict the possible outcomes if we would change different variables and we would build that into our product requirement. Rather than doing some market research and relying on subjective impressions, we had an analyst developing a model that could predict different outcomes. While this approach didn’t necessitate certainty it allowed us to feel that taking a bet was worth it.

Lessons learned

• Cycle times are arbitrary. Changing cycle time didn’t have an actual impact on how the team perceived their autonomy but it had an impact on their ability to deliver a meaningful amount of data and value to the customer and their buy-in into that value. With shorter cycle times, everything felt erratic and we would have sprint goals that looked like a feature description with no customer value focus. When we gave the team some extra time we noticed how better they became at solving problems and getting closer to our customers. In addition, our developers didn’t only rely on a product person to come up with requirements but were able to find time and space to learn. Also, they were able to spend less time in meetings and more time figuring out how to deal with those often complicated problems that insurance brings to us.
• We modified Agile to serve our needs. For example, our ceremonies were fairly time-consuming and often unnecessary. Many people would adopt Agile as opposed to agile as a methodology. People often lacked the most rudimentary understanding of why they were doing what they were doing. They would have planning and refinements, retros and standups and after all those meetings would tick all the boxes on Agile instead of being focused on delivering the value.
• We learned how to separate shipping from delivering features to our customers. Our site reliability engineering team did a great job to allow the code to go safely into production, whether behind feature flags or in a canary environment. The team could move onto the next thing while our program management team and our marketing team would work on the actual deployment of that feature as they put it through legal review, compliance checks, all the things that are specific for the insurance industry but separated from software development. We still have continuous integration and continuous delivery but we do it in a way that is safer for a highly regulated environment.