Monday, December 05, 2011
Why "Agile" has only had a modicum of success in insurance
1. 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.
Links to this post: