It’s often said that if you want to make big changes at anything, you must start small. Start small and take one step, one tiny action today. Soon, the small actions build on each other.
Take that 40 pounds you resolved to lose on New Year’s Eve. If you’d started small — maybe by targeting a daily, 20-minute walk, or by simply downloading a fitness app and just started recording what you eat — you might have been successful. Instead, you went on a carb-free diet and bought a deluxe gym membership Jan. 1. By President’s Day, you were off the wagon, and you haven’t been to the gym since St. Patrick’s. You started too big and then gave up because it was too hard.
There is value in the maxim about starting small, and it can even apply in enterprise technology. But hear this: When it comes to changing the culture and practices around your company’s software development, the old “start small” does not apply. If you are a C-level technology exec who’s decided to wade into Service Virtualization as a way to make your dev/test operations faster, less expensive and better-quality, the best advice is to go big — as big as you can.
As Jason English and John Michelsen wrote in Service Virtualization: Reality is Overrated, picking low-hanging fruit is no way to trigger a revolution:
Ever try out a new stain remover? The instructions will say to “test on the material in a less noticeable area” first. Well, we think the opposite should apply to your earliest SV efforts.
Advice: Pick a hairy problem first. Go find the biggest, most stubborn goat of a software problem that exists in your environment. You know, the one everyone’s complaining about that makes delivery run late and over budget. Locate a key software-enabled initiative with many moving parts, including big mainframe availability and data conflicts that are eating untold hours and dollars. Tell them you can use SV to decouple those complex constraints in days or weeks of modeling, not months or years of coding. Nobody will believe this is possible.
Why start with a hairy problem? This group should be ready and willing to try something new. When the constraints are already well-known, failure is certain if something doesn’t change. The potential improvements of eliminating the constraints will be massive. Yes, you could pick something easy, but would that make believers out of the organization?
Let’s unpack that logic for just a moment. First, I know what you’re thinking: “I’m supposed to use a new approach to tackle the biggest problem I have? Isn’t that a little risky?” Well, yes, of course. On the other hand, your hairy goat of a problem is posing plenty of risk to your organization already, costing you lots of money and frustrating everyone. This is exactly the idea. When SV works in helping you untangle long-hopeless software disasters — and it will; studies have shown it — you’ll hit the jackpot.
By starting big, you focus on a problem that everyone in the organization knows and understands well. They know well the costs involved, the frustrating constraints, the endless months of project delays, the embarrassing software glitches that hurt your brand. Everyone knows how hard they’ve worked to fix these things before.
Now, just imagine the effect when your team is successful in using simulation technology to solve these long-frustrating problems, speeding up development while producing a higher-quality product, on the big stage? Presto. You don’t have to worry anymore about justifying the costs of SV tools to your boss. You won’t have to evangelize anymore about the value of Service Virtualization. You won’t have to talk any other teams into using it. They’ll be tripping over each other to use the tools next.