Offshoring isn’t going away. But maybe we can be more intelligent about how we do it. Margaret Dineen has some ideas about how not to offshore and she shares them with us today.
When I hear people talk about their plans to offshore software testing because it’s a separate function and is too costly, it both confuses me and makes me a little bit sad. I believe successful projects require collaborative development (and to me, collaborative development includes testing), and I really question the meaning of cost reduction. I don’t understand how losing valuable business knowledge and loyalty can be considered a cost-saving measure.
I absolutely love working with people. I love the daily interactions, the relationships we form, and the experiences we share in the workplace. I love working with people who know the business inside and out, the people who understand not just the business rules, but also the reasons they were introduced in the first place. They understand how customers are using the product, and they understand business value.
If I asked you about the most successful project you’d ever worked on, I’m willing to guess that you’d talk about the people on the project, the great communication that existed among the team members, and the respect you had for those people. You might talk about challenges along the way that the team worked together to overcome, or about the fact that everyone wanted the project to be successful so they went that little bit further to make it a reality.
With a successful project, there’s a magical combination of ingredients that take the project from average to wonderful. The energy, the relationships, and the knowledge gained continue long after the project has been deployed. If we can try to understand what those key ingredients were, we can harness them to facilitate positive change from within.
Kaisen Consulting carried out a survey across a wide range of industry sectors, including retail, utilities, financial services, leisure, IT, medical, accountancy, and consultancy, to see what makes people feel either good or bad at work. The key findings are as follows:
- Motivation will suffer if the emotional dimension is ignored.
- Organizations need to invest in building their teams.
- Recognition is fuel for motivation.
- Managers make the difference.
- Business success and customer satisfaction barely featured as motivational factors.
In terms of business value and cost savings, I’m not qualified to tell you in dollars or in percentages what this means. Nor can I put a value on the benefits of having a motivated team who wants to work together and pull out all the stops in order to get something good deployed. I have no idea how to put a value on an organization with a high rate of staff retention, high staff morale, and a real desire to continually challenge themselves.
Business value is not realized by cost reductions. Focusing primarily on cost reductions is likely to provide only short-term benefits. People who have been involved in cost-saving exercises before will automatically associate it with being asked to do more with less, to increase their workload, possibly to reduce their staff, and to increase their stress level. It’s also a heads-up to update a CV and start looking elsewhere.
It doesn’t take a genius to work out that if employees are just doing the minimum required and feel insecure about their jobs, then productivity is reduced. (David Bolchover calls these people “the living dead”!)
In my experience motivated software testers (or any employees) will constantly want to do things better. They will want to challenge themselves. They will have testing books on their desk, they’ll want to discuss testing techniques with their colleagues, and they’ll ask for training and workshops. They will know what’s good and bad about their testing process and will have ideas on how to fix the bad bits. All we need to do is to facilitate change that’s driven by them and encourage them to keep improving.
In one organization where I worked, management decided to engage an external consultancy to evaluate testing and improve efficiency—but it made this decision without first discussing it with the internal test team. The test team members actually did understand their own work environment and the issues with it, and they knew how to make it better. But the result of the management decision was that the internal team members felt undervalued and resentful, and they decided not to go out of their way to help the consultancy organization. The consultancy organization found it more difficult to meet expectations as the task took longer than planned, and the improvements didn’t end up lasting that long.
A few years ago, I caught up with someone whom I’d worked with previously, a lovely gentleman called Kenneth. We’d worked together in a great company that had gone through a restructure. After the restructure we both left, but Kenneth had gone back as a contractor. I asked him how the remaining members of the team were doing. His response is one I’ll never forget because it summed up the situation very well: The team had lost its spirit.
So, how do you actually go about implementing lasting process improvement in software testing? You can’t walk into an organization and implement change without understanding the culture and listening to what people have to say. You need to be prepared to get your hands dirty, get to know the software and the teams involved, perhaps sit in on a project implementation to see how it’s done, assist in a test execution cycle, raise some defects, or see how test reports are prepared before deciding on what the priorities are. You need to be able to wisely select the most appropriate strategies from your toolkit. Mostly it’s about listening, observing, and then engaging others before facilitating change. Every team and every project is unique.
As a manager, you can start appreciating all the people you’ve got in your organization and the particular blend of skills they bring. You can support them in their growth, and you can encourage them to keep learning.
If your ultimate aim is saving money, open a deposit account. If your ultimate aim is creating and deploying quality software in a sustainable manner and retaining good people and getting the best from them, then focus on the people—the benefits will follow.
User Comments
Agile values close, frequent, face-to-face communications. Therefore, we should never see any company using Agile and outsourcing development and/or testing, right? Oops! We see it all the time. And if they offshore the work, then you've got language, cultural and time zone barriers making things even worse.
The power of saving a buck - never underestimate it. When companies "embrace" Agile and then outsource offshore, they just want to save a buck even though the project is likely to tank. Actions speak louder than words.
Great article. I felt the same way about offshoring a few years ago. I worked hard to build and promote onsite QA teams and invested in the development of their technical skills. Unfortunately in QA, if you are technically strong you are lured into the role of a "developer". If you are strong and organized QA analyst, you're lured into product ownership or project management. I applaud those who remain in QA and continue to build on their testing skills. I wish there were more of these testers available in the job market. These professionals should never feel insecure about their job and from the barrage of emails from recruiters, they know they are valuable and hard to find. What do you do if you are a CTO or QA Director and you just cannot find these senior test professionals? I wouldn't fully discount the value of offshore testing services. Once you listen to your onsite testers' needs (as you have recommended), offshore teams can provide training and mentorship. Nearshore teams, with similar time zones and shared language, could be an affordable way to ramp up a more junior onsite testers without losing their "spirit". Thanks for sharing.