The economic climate of bigger is better has been shifting much media attention and fiscal policy away from smaller franchise operations and toward the monolithic pavement deserts that are filling towns and rural routes. The promise of mass employment, tax revenues, and large construction contracts is a tempting apple for any city planning board to turn down. Harvard University Economics professor Dr. Edward L. Glaeser and Harvard Business School‘s assistant professor are calling a time-out to local communities with the somewhat surprising message that this model is misguided.
In August 2010’s Harvard Business Review, Glaeser and Kerr talk about the secret to job growth is thinking small. In fact, their research indicates a strong correlation between regional economic growth and small entrepreneurial companies. The overlap to software quality assurance? The city is the software project, and the companies are the teams making the projects go.
Along the way of managing web software quality assurance teams and implementing QA strategy for complex services-based enterprise web products, I’ve found that the results published by Glaeser and Kerr are identical to my experience of how to most effectively set up multiple QA teams for success. Best practices can only take teams so far: encouraging and coaching QA Managers into entrepreneurial adaptive approaches to testing can yield far stronger results for web product and implementation teams.
Why is this? What happened to the approach of a single metrics dashboard for entire silos of functionally similar business units? What about similar looking status reports and multicolored spreadsheets with thousands of formulas computing more metrics than an MBA review nightmare? There’s nothing inherently wrong with these ideas; they must benefit many teams because of the raw number of companies selling dashboard and management solutions. But be careful: Not only can data be misleading, argues Glaeser and Kerr, but its “reasonable to wonder whether [a variety of] special circumstances skewed the results.” I have to agree with the good doctors — I’ve simply been in one too many status meetings where the numbers don’t add up to a quantitative (the numbers support a measurable situation) or qualitative (the nature of the root cause) story that explains where we’ve been or offers any tangible insight into why we find ourselves where we are as a software development business unit or implementation team.
The nature of software quality assurance is one of checks and balances; QA is meant to be a scientific process of audit. The software product concept, the communication to development, development’s internal idea processing and conversion to working code, the deployment process, the testing process, and the loop-back to product. No matter what software development paradigm the team follows, product has to see the widget before they’re shipped. More often than not you’re better off settling down with some popcorn and getting ready for some good laughs rather than betting the farm the customer will have a problem-free experience with the end build right out of the gate.
Entrepreneurship in leading QA teams is important. There is a fine balance between coaching QA managers to where they need to be in terms of (A) people skills, QA and software development processes, and QA and Management tools and (B) trying to control too much. Entire books are written on how to find this general managerial and life balance — one of my favourites has to be Harvey MacKay’s shark book. You can’t expect to hire QA managers, put them managing different products with different teams in different areas and, these days, quite possibly different parts of the world, and expect them to report to the same set of metrics just to make a status meeting go smoothly.
The job of a QA Director is to synthesize information up from your QA Managers in their own language, not yours. You can then translate to the status meetings as needed. Give your QA managers as much freedom, with the coaching needed to grow their skills areas where you’ve measured them to be weak, as they need to innovate and inspired not only their QA staff but their fellow QA managers. This idea is a concept called interdependence and it is given momentum when managers inspire managers by staying in touch with the moving parts of a software project that need attention.
“And a little work in that direction goes a long way. Research shows that once entrepreneurship gets established, it tends to be self-pereptruating.” Couldn’t have said it better myself.