Monday, December 05, 2011
Why "Agile" has only had a modicum of success in insurance
Many people know that I have adopted agile values to the core and that I also work in the insurance industry. I figured I would share thoughts on why Agile hasn't been wildly successful...
1. The majority ofleadershipmanagement comes from a project management background: The first acknowledge that needs to occur is one of term confusion. Many do not delineate the important difference between a project management lifecycle (PMLC) and a software development lifecycle (SDLC). The former will gravitate toward project management concepts ranging from Scrum, Kanban or the infamous but otherwise mindless debates over comparing them to waterfall. The later will find value in looking at approaches such as Extreme Programming and building test cases first, however this isn't really visible if you haven't risen the ranks from software developer to CIO.
Let's acknowledge that Agile has been wildly successful in companies and cultures where the engineering mindset is much more valued than the project management mindset.
2. The focus on documentation: Can you think of an industry vertical that outranks an insurance carrier in terms of sending confusing documentation to their buyers? They have a habit of sending 100 page documents such as policies to 90-year old grandma's and couldn't care less about whether it is understandable by the receiving party. So, what makes us think that writing understandable documentation is going to happen?
We can all get caught in the vortex of asking for good documentation, but this is a trap. There is nothing in any Agile methodology that can overcome this challenge. I can tell you from my experience, I'd love a proper requirements document - but I've yet to see one. Every requirements document I see is loaded with assumptions on both sides, and rarely do both sides agree on the assumptions. I had one experience where the customer agreed that one "feature" we were developing for them was totally not what they wanted, but they were afraid to alter the requirements document because they were afraid we'd negotiate out of some features they wanted. So we went merrily along developing something that they would not use. Doesn't think feel like your insurance policy?
When insurance carriers adopt the policy of brevity, then they may stand a chance.
3. IT doesn't know who the customer is?: Having an on-site customer representative is risky, because he/she is bound to be pretty junior. Is the customer really going to spare a senior decision-maker for an entire year? But regardless, the customer representative "becomes" the formalized requirements specifier.
Now, combine this thought with the acknowledgment that many insurance policy administration systems have more tenure than even the most tenured IT employee. Insurance business logic is a collection of exceptions that have been built up over time and has reached the point that no individual even knows them all. Usually, they have been lost in the documentation archives and survive only in code. Therefore, the person that knows how the business works the best in its current state tends to be some lowly IT employee.
The practice I think is best employed is to sometimes go customerless and to encourage IT to adopt the principle that before they write code, they need to learn how to read code.
| | View blog reactions1. The majority of
Let's acknowledge that Agile has been wildly successful in companies and cultures where the engineering mindset is much more valued than the project management mindset.
2. The focus on documentation: Can you think of an industry vertical that outranks an insurance carrier in terms of sending confusing documentation to their buyers? They have a habit of sending 100 page documents such as policies to 90-year old grandma's and couldn't care less about whether it is understandable by the receiving party. So, what makes us think that writing understandable documentation is going to happen?
We can all get caught in the vortex of asking for good documentation, but this is a trap. There is nothing in any Agile methodology that can overcome this challenge. I can tell you from my experience, I'd love a proper requirements document - but I've yet to see one. Every requirements document I see is loaded with assumptions on both sides, and rarely do both sides agree on the assumptions. I had one experience where the customer agreed that one "feature" we were developing for them was totally not what they wanted, but they were afraid to alter the requirements document because they were afraid we'd negotiate out of some features they wanted. So we went merrily along developing something that they would not use. Doesn't think feel like your insurance policy?
When insurance carriers adopt the policy of brevity, then they may stand a chance.
3. IT doesn't know who the customer is?: Having an on-site customer representative is risky, because he/she is bound to be pretty junior. Is the customer really going to spare a senior decision-maker for an entire year? But regardless, the customer representative "becomes" the formalized requirements specifier.
Now, combine this thought with the acknowledgment that many insurance policy administration systems have more tenure than even the most tenured IT employee. Insurance business logic is a collection of exceptions that have been built up over time and has reached the point that no individual even knows them all. Usually, they have been lost in the documentation archives and survive only in code. Therefore, the person that knows how the business works the best in its current state tends to be some lowly IT employee.
The practice I think is best employed is to sometimes go customerless and to encourage IT to adopt the principle that before they write code, they need to learn how to read code.
