Some business catchphrases end up washing up on shore in the land of forgotten managers. Not this one, though. I found a catchphrase that underscores the very nature of what it is to be on a QA team.
I was an underclassman at Rensselaer Polytechnic Insitute when the late C.K. Prahalad published an article in the May-June Harvard Business Review Define defining the term “core competency” for the first time. He writes about Rethinking the Corporation,
Once, the diversified corporation could simply point its business units at particular end product markets and admonish them to become world leaders. But with market boundaries changing ever more quickly, targets are elusive and capture is at best temporary. A few companies have proven themselves adept at inventing new markets, quickly entering emerging markets, and dramatically shifting patterns of customer choice in established markets. These are the ones to emulate.
Prahalad goes on to talk about the need for upper management to assume ultimate responsibility of innovation and strategic evaluation of the risk of their decisions. This may sound redundant — why wouldn’t top management assume and evaluate the risk of their teams — but even today this is not the case. CIOs are caught uncertain about a decision and simply hand it down to their direct reports, “This is yours, run with it.” There is a time and place for that, certainly. Is it possible that there are some risks too great to transfer to a subordinate? Is it possible that while your QA team is the team you can afford to keep farthest from you (keep friends close, enemies closer), because you have built trust in them, you as a business champion must underscore your support and championship of QA instead of sending them to another land?
“It never makes sense to outsource your core competency,” recalls Tony Hsieh, CEO of Zappos.com in a piece written for August 2010’s Harvard Business Review. Tony is speaking about exceptional customer service, the principle upon which his entire company is founded. He sought to put the customer first before all retail profits, and by focusing on the customer, hoped the profits would follow. His predication came true. So if a web product’s core focus is delivering high-value content and services to its users, what does that say about the focus on quality and the decision to risk everything by outsourcing the very group that will ensure your profit margin? In web product development, the quality of the user experience must be placed first in order to win. In order to win, your QA team must have full championship of management. QA needs the responsibility and the authority to operate.
Seven reasons QA outsourcing fails:
1. Ensuring quality delivery of the web product’s vision isn’t shared by the whole company. Fighting over the scraps tossed on the floor of the feast table, executives squabble about moving pieces on the chess board of offshore partner overhead costs, staff rates, who is working what hours, communication failures, and who should be moved off or brought onto the team. QA is not just a department that can be shaken, stirred, and relocated. Let QA do what QA does best: analyze, test, measure, facilitate feedback, and manage the software process after the implementation phase. In Scrum, a mature product is largely run by QA. CIOs should be regularly meeting with QA and Product — not their direct reports or other VPs — to see where their priorities should be.
2. QA isn’t empowered to act. If you make QA’s most powerful lever the lever to escalate to their director, who goes to the VP, who goes to the CTO — or worse, even more layers in between with offshore liaisons, offshore project managers reporting to onshore project managers, etc. — you will have too many wheels spinning with indecision and bickering over whose opinion is strongest. Often in these situations, might is right wins rather than the quality of the user experience, and the end product suffers. QA must have the authority as well as the responsibility — they go hand in hand.
3. When you know someone needs to go, you don’t let them go. Firing is an uncomfortable but necessary part of keeping the right people on the bus – both onshore and offshore. Avoiding the hiring and firing process is avoiding managing. Be careful of giving your offshore managers too much control of their own resources — remember, it’s your money that is paying those people. If you can’t understand them on a conference call, always keep in mind that there are plenty of people who can speak your language in a way you can understand. Don’t settle for a situation that won’t work. A QA manager, tester, or contractor who is a poor performer or has a negative attitude that stays on the team in spite of failed attempts to revive them is like a wound that goes gangrenous and won’t heal — everyone sees what is going on and it is like a virus to productivity and attitude. If HR policy dictates the person must stay, set them aside with a low level task and move the authority for getting work done to people ready to step up. If you’re out of budget, take scope away or increase timelines. If you can’t do that, have a serious sit down with your CTO and ask him what he would do if time, scope, and resources had to remain fixed, and one of those began to suffer.
4. You use QA metrics against developers, you allow scope creep, and use best practices. That’s not a typo. Skilled people don’t have to advertise best practices: it comes through in their work. Putting names by defects and starting to see who is generating the buggiest code or who is taking on the most points in a story brings attention where it’s not wanted. A good Scrum master will instead look at who is junior and needs mentoring, and ask high producers to take time out for coaching and mentoring junior skilled team members. Educate your project managers that an opportunity to take on extra work is almost always best used by asking the developer if code needs rework or a good combing-through. Junior PMs are often caught in the piñata trap — they think they are better managers if they are delivering more points or more functionality. This is a junior point of view that even very senior managers still hold on to. The winner is the team that develops the best product, not the one with the most features. And finally, the consulting team that sells you on best practices is almost always the one that doesn’t know why those practices are best for you. If they did, they’d be talking about your process and the mechanics of how it works and how they can partner with you, not selling you a bundle of Best Practice boxes with templates and documents inside. Anybody who celebrates Best Practices is selling something.
5. You’ll use email for things email wasn’t designed for and avoid your teams when they’re busy. Email is good for record keeping and legal trails of breadcrumbs. Email is decidedly poor at problem solving. If you must use a distributed team, use free video-conferencing from Skype. It is amazing that we have such useful, high bandwidth technology, and yet people still pontificate over email. As a leader, set the tone. If you don’t use email and your people know you won’t answer email, they’ll get up and come to you. And then you’ll see them getting up and going to other people. Don’t leave your teams alone when they’re busy. Walk over and just chill out. See what they’re doing. Strike up a casual conversation with someone in deep thought. Let the team know that when you show up, they need not map a Pavlovian link of fear and loathing to your arrival. This is decidedly most difficult to do when using an offshore team.
6. You’ll view understanding the QA process as overhead instead of an investment in reducing time to market. Because managing an offshore contract takes precedence over the QA team, right? No! Stop taking your VP buddies to the golf course and take your QA lead out to dinner. Repeat this as many times per month as possible and socially acceptable (we QA people have excellent appetites). Too many CIOs and executives don’t fully understand the “whys” behind the methodology behind publishing and qualifying defects in the way QA does, or the reasons certain automation frameworks are selected, or the reason that certain performance metrics are or are not chosen, or the reason a load test is set at the settings calculated. Good QA Managers love to talk about the successes and failures of their methods and coach others. If you had the option to look into the deep operating core of your human heart with little expense to you, would you do it? Or would you be too scared at what you might find out? It’s better to know how your quality organization is qualifying your products than to be too afraid to find out. The information is out there, and QA is the best positioned at communication and presentation of anyone in a Scrum team. They have the best view of the theatre when onshore working with the team. It is hard to do this in a cube maze somewhere in a foreign land. Is it really worth the money you’re “saving”?
7. You won’t make time to celebrate successful deployments by complimenting the developer-tester bond, telling exceptional stories to upper management, and having upper management personally thank the technical team. How can you celebrate a person’s success if they are not a part of your culture or ever physically around? Do you send them a pound cake? Offshoring dehumanizes people. Go to lunch and dinner once a month, more if possible. For major deployments of top product features, have lunch or dinner brought in, and have upper management stay late on a few major deployments, just to be there. Bring in ice cream when the clock hits 9pm. Splurge for something more than pizza. If the team only sees the top brass when the fan’s RPM’s have slowed on account of waste matter, that sends the signal that you’re hamsters in a wheel, not human beings trying to create something great.