By R. Christopher Haines, Executive VP and Chief Operating Officer
Aren’t buzzwords awesome? It’s kind of like high school all over again. The in-crowd versus those not in the in-crowd. Get with us or you aren’t cool. There’s more and more of this kind of jargon showing up in insurance technology all the time.
One that has been around a while now is agile. Agile software development. Sprints, sprints, sprints. And oh, yeah. Don’t forget the scrum teams.
Don’t misunderstand. I get it. There were issues with the way things were being done, so people were desperate to fix it. Failed implementations were close to outnumbering successful ones. I don’t disagree with agile. I’m not trying to knock it in any way. But what’s really scary is overlooking basic common sense. That oversight got us into this trouble in the first place.
Here’s a concept from most agile approaches: Choose customer input and feedback over intuition or assumptions. Really? We had to be told this? Apparently so. That precept is on almost every agile diagram, or it’s in the foundation of every lesson. Why?!
It suggests that companies are developing software — putting the money, the time, and the energy into something — without a good feel for what their customers or prospects really need. I know it happened. I know it’s still happening. But it still amazes me.
Another beauty is teamwork. Let’s see if I got this: We’re so unsure people who work together will remember they work together we have to remind them to work together? Is that right? We all know the horror stories of the dysfunctional silos in software development companies. People complete their work and hand it off to the next group without much interaction. If someone gave feedback to one of the developers on one of the steps, all Hell broke loose.
What’s to blame? The buzzwords or bad leadership? Does it matter? Couldn’t we have recognized that assumptions are bad and teamwork is good without reinventing the whole process? Should software companies have gotten to the point at which it’s okay to develop what they want and not what customers need? Should it have been acceptable that Team A and Team B didn’t get along while the product suffered? Should the leadership of these organizations have stepped in and fixed these problems? Did it really require a whole new path up the same mountain? I’m not sure it did.
And just to let you in on a little secret, software deliveries are still late, quality is still an issue, and implementations are still failing. So, where do we go from here?