Both business management strategy and technical QA strategy share a common Achilles’ heel. Throughout my career as a software QA professional I have seen two distinct approaches to building QA programs. I’ll discuss the pros and cons of both approaches in this article.
The first approach is to focus on executing functional testing and ensuring that existing automation and performance scripts run as expected and that defects are raised as per process. This method usually uncovers some defects and major integration problems that the team can fix before pushing a system into production. A higher level QA strategy is often hinted at but not clearly measured, defined, or goals set — the focus is on the test execution piece and less so the automation architecture, performance philosophy and calculations, and staffing concerns for the next 3-6 months. “We’ll cross that bridge when we come to it” is the winning perspective here, and when the bridge comes, it’s not so much an ordered crossing — after all, there is no real workable vision to march to — but rather more of a mad scramble. This cycle is vicious.
The second approach is to employ systems-thinking and empower testers and managers make valued downstream choices. Feedback is encouraged back up the management chain, with emergent properties such as innovative testing methods and techniques that are designed for the actual products created vs. the imaginary products that were born in a conference room 6 months ago.
Execution by means of upholding values put forward by a QA Director and/or CTO results in QA testers and engineers that are not just mindless doers but both the brains and arms and legs of the software development body. This cycle is virtuous.
Roger L. Martin is the dean of the Rotman School of Management at the University of Toronto. He is the author of The Design of Business: Why Design Thinking is the Next Competitive Advantage. In Martin’s article, “The Execution Trap” in August 2010’s Harvard Business Review, he argues that drawing a line between strategy and execution almost guarantees failure. On the other hand, “when workers are made to feel empowered,” he writes, “the whole organization wins.”
Why then is the dogma of execution-is-job-one so prolific in our management and technology organizations? Jamie Dimon, CEO of JPMorgan Chase, wrote in 2002 that “I’d rather have a first-rate execution and second-rate strategy any time than a brilliant idea and mediocre management.” Larry Bossidy, former CEO of Allied Signal, co-authored by best-selling book Execution: The Discipline of Getting Things Done, in which the authors presented the idea that the failure of most strategies was due to poor execution, as opposed to faulty strategizing.
The problem with this perspective is that it removes responsibility from the business champions and those responsible for the ultimate vision, purpose, and mission for the teams; it shifts blame to those who would carry out the mission. This position results in emergent properties of blame and data slanting — failure can always be attributed to poor execution — rather than a systemic inquisition and re-evaluation of the vision and values championed by business decision-makers that software development teams seek to uphold.
Searching for reasons why this strategy fails can be compounded especially when strategy consulting firms are engaged. Why do consultants flock to these situations? Think about it – if a consulting firm can see that a client is embracing the concept that the providers of strategy are not held accountable for the results, this paradigm guarantees payment for providing no measurable results. The results are, after all, measured not as a function of the principles upheld by the strategy penned, but on the line-workers who carry out the golden binder of deliverables. Should the project fail, the firm’s management will drop blame squarely on the workers. Perhaps they’ll even re-engage the consulting firm for a second project or need a new phase of engagement…
It seems like choosing the first strategy results in money spent on re-engineering strategies for failed strategies, keeping workers as technical day-laborers and struggling with keeping up with turnover and consultant fees. If true software development excellence is what a company wants, it sounds like they’re going to pay for it whether they get the results or not, so — why not select the second strategy, which empowers workers and has no place for blame?
In both scenarios, management is looked to for a finely-crafted vision. Why not have the CTO engage with other company leaders to craft a broad and purposefully somewhat abstract choices to guide the initial direction of the software development organization, and then empower the application development and QA organization to make choices that best fit the changing scenarios involved in software development.
If they are using an Agile flavored methodology, they will be able to change quickly with product enhancements and business requirement updates and remain flexible enough to provide adjustments to the software product on a week to week or iteration to iteration basis.
Ultimately, this delivers the most business value quickest, but it requires that upper management remain engaged instead of sitting back and watching the movie play, and how the movie ends isn’t their concern.
Despite the warning that strategy formulation and implementation or execution are “interrelated in life” and “equally important,” four decades later, the strategy-execution theory artificially conceptualizes them as separate. It is high time that we delved a little deeper into the twisted logic of our current approach. If we don’t, we are almost certain to fail. […] It is time to revisit and revise our upstream theory. The business world may be utterly convinced that better execution is the path to greatness, but in truth, a better metaphor would be much more helpful. Only then will the rank-and-file employees of organization be free of the scourge of buy-in sessions. And only then will the promise of empowerment have a chance of being realized.
If you’ve been running the strategy-first good-luck-QA model for a while, you can’t suddenly change tracks and expect to solve the problem by having QA attend high level meetings and vision exercises, assign a laundry list of to-dos, and hold the team’s feet to the fire when they haven’t succeeded in a few days. Decide to make the change at the CTO or executive level and begin engaging QA managers not to generate reports, but to have conversations with management and QA staff about what is working, not working, and where QA feels they’re not being heard.
If QA had the keys to the city and could unlock any change in the company to make it completely awesome, what would they do and more importantly why would they do it? Seek to have these conversations. If you do not yet have a culture where these conversations can be had yet, build up to them. Have lunch meetings where you have open-ended conversations about how things are going. Maybe direct the tail end of the conversation toward this end.
Engaging QA directors and managers in this way and helping QA managers to engage their testers and engineers in this spirit of teamwork and systems thinking will foster a culture of openness. Openness is an emergent property of systems thinking, but it does not happen in a day. This takes time and persistence. Strong corporate and team culture requires someone who can think in a systems perspective to see that the whole is far more than the sum of its parts. If you don’t have such leadership, perhaps its time for an investment in an organization or individual that can help you get to where you want to be.