When software projects frequently miss release dates and go over budget, unplanned rework is often the culprit. So why aren’t more companies Shifting Left to get testing and QA involved earlier during sprints?
|
It’s well-known that Shifting Left can help software project teams minimize unplanned rework, lengthy delays, and budget overruns, |
“Prior perfect preparation prevents pretty-poor performance.”
Whether you’re prepping a festive feast for your family or busting out the holiday decorations on a lazy Sunday, there’s a good chance you thought of that sentiment (or a slightly more mature derivative) at least once or twice. It’s the same reason you prepped the dressing and casserole the night before Thanksgiving, so you could spend the next morning focusing on the turkey and other sides.
Yet, as proactive as we can be in some phases of our lives, we’re still lacking in others.
Take software testing and QA, for example. It’s well-established that Shifting Left can help minimize unplanned rework by applying testing and QA processes earlier on in sprints. But despite the fact that it can help project teams prevent lengthy delays and budget overruns, a lot of software testing organizations just aren’t doing it.
We know this because we’ve surveyed an array of IT leaders over the last six months in an effort to understand how the industry at large is approaching software quality from a process standpoint. And when it comes to Shifting Left, the results were pretty eye opening: 53 percent weren’t doing it at all—indicating that their testing strategy was best defined as “an undefined process” or “a minimally-managed process that still follows coding.”
In short, this means that more than half our respondents aren’t engaging in “prior perfect preparation” from a software perspective. I don’t think you need me to tell you the kinds of performances they’re failing to prevent, right?
In a typical Agile project, Shifting Left means getting testers and QA personnel involved in things like project planning, backlog grooming, user-story inspections, and code analysis. Without QA’s input, critical questions like “How will this be tested?” and “What is considered ‘done | done’?” don’t get asked—which leaves the project susceptible to a rash of unplanned rework, budget overruns, and delays.
Fortunately, implementing this kind of change is far easier (and less costly) than getting started in test automation, for example. So, if you think your organization is part of that 53 percent, now is the time to start getting proactive. And if you could use a little help getting started, feel free to drop us a line. Whether you need an organizational assessment or just a bit of free advice, we’re more than happy to lend a hand.
‘Tis the season, after all.
Cheers,
Mike Hodge
Lighthouse Technologies, Inc.
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting
After spending over 20 years managing, developing, and deploying complex software/hardware systems for both commercial and Department of Defense (DoD) applications, Jeff founded Lighthouse in 2000 with the aim of establishing a company whose customer service was only eclipsed by the quality of its work. Armed with an encyclopedic knowledge of motivational leadership tactics and a wealth of expertise in software quality assurance (QA) processes and technical leadership, he’s both a hands-on company leader and the primary architect of Lighthouse’s celebrated workplace culture.
