home Exploratory Testing Case Study: Offshore Team Innovation Lab

Case Study: Offshore Team Innovation Lab

Lab team brainstorming session

Whether you work in engineering/product, operations, or even marketing, keeping your team trained and engaged with their work is a challenge that is universal for all managers. This is hard enough when your team is in-house, but what are you to do, when you have multiple teams to manage across different time zones?

Many companies today use some form of offshoring, outsourcing, or a combination of both when it comes to their testing staffing, but building the skills of those teams to operate in cutting-edge technologies and methodologies can be tricky, especially when one factors in expectations of staff (both in-house and the off-shore team) perceived cultural dynamics, or the need for teams to problem-solve and troubleshoot on their own.

In this case study we will lay out the results of engaging an offshore team’s creativity, excitement and intelligence to light their innovation fire and solve their own growth issues.

The method behind the madness: the making of the Innovation Lab

LogiGear, realizing this challenge, set on a solution to better train their staff in their offshore locations. Besides teaching the team in leading technologies, the goal of the training was to foster innovation and problem-solving independently of the home office. With that in mind, the LogiGear home-office came up with the following solution. It would develop an Innovation Lab.

The goal of the Innovation lab was two-fold: First, to train the team in cutting edge technologies through the Innovation Lab, and encourage hands-on learning via IoT and mobile devices. The second goal of the innovation lab was to instill a sense of ownership in the offshore team and teach them to foster solutions to problems they faced on their own. This would allow them to gain more autonomy from the home office.

Peter F. Drucker released an essential management book called Innovation and Entrepreneurship. His book paints a picture of the disciplines required for innovation and entrepreneurship.

He states, “Innovation is the specific instrument of entrepreneurship—the act that endows resources with a new capacity to create wealth.”

Drucker detailed the Six characteristics of knowledge work. We’ve talked about it before in LogiGear Magazine’s “Leader’s Pulse.” However, instead of the US home office side leading this effort we decided to try an experiment of our own: we will have the offshore team lead this.

Team problem-solving session

The US team came up with the idea to loosely guide the team to build a mobile product, this would be the Innovation Lab. The US team’s involvement was minimal—after conveying the complete ideas and goals of the project,  transfer of ownership to the Innovation Lab was given to Vietnam. They would have complete autonomy on how to build the lab. They were in charge of all decisions, and the first important decision was staff selection.

There was a selection of experts as key members of staff—and most essentially—they were in charge of training other members on the project.  Although all of these responsibilities were carried out in Vietnam they adopted an American-style training method.

 

Build and test…and manage

The local Vietnam team demonstrated a great desire to learn and practice new technologies.

Here were some of the people issues they encountered:

  • Scheduling was difficult. Each of the staff/engineers had some project responsibility. It was tough to keep constant staff on the project.
  • Innovation, R&D, Learning is essential—it had to be carefully balanced by revenue work.
  • Communicating, updating, handing off tasks was—just like in any engineering office—difficult and time consuming. These skills are slowly built. We “bypassed” usual leads and got some newer engineers.
  • In regard to technology, specifically, they ran into problems with automating APIs and web services. Also, getting programmers for Apple iOS was more difficult. They had to get some practice in. The staff worked together to train each other.

The staff wanted to do the task and were excited at the prospect but when it came down to it, they, like tech workers all over the world,  didn’t want to write anything. The home office needed information on how things were going and training needed to be built as it happened but for a while there was nothing.

The issue here was, the staff only wanted to work on tasks that they found interesting—not what needed to get done, this included documentation. Building training for their team members was required. But training was not that interesting. The solution: managers found the few testers who did find it interesting and let them run with it, while others built examples. Although initially, there was a little resistance to try new things. It took some time for the team to feel comfortable with the

whole “learning-by-experimenting” concept.

 

Defining and making the product

The product and technologies were to be built, tested, and test-automated by the offshore team. With this, we wanted them to learn about new technology and gain experience in the following areas:

  • Building and testing mobile apps
  • Integrating web services/APIs
  • Integrating social media APIs
  • Integrating embedded devices/IoT
  • Using simulators/emulators
  • Test automation for all four of the aforementioned technologies
  • All of this will flow into an awesome Continuous Integration (CI) process

Building a mobile app is a continuous process; build, test, automate the testing, hone in on the CI process and pipeline, and repeat.

The team took it step by step using SMAC as their model. First, came mobile and social. Next, was hardware/IoT devices, and then there was capturing data and analytics. Last, was the solution to learn cloud development skills. The app they developed was for runners, it was called Fit/IO.

This app would be able to plan, execute, and share their daily runs. The app would be built with maps, geolocation, photos (with the option to upload onto Facebook and Instagram), weather, and a heart rate monitor.

The user would be able to:

  • Check weather through the National Weather Service web service and geolocation
  • Get a map through Google Maps web API
  • Take the users heart-rate through an embedded system device or wearable with an embedded system
  • Get air temperature through an embedded system device
  • Take a picture with a mobile device, a watch, or a wearable camera
  • Post pictures and text to Facebook through the Facebook API
Diagram of the proposed system to build

Key challenges/findings:

  • Knowledge workers need to be challenge
  • Staff needs knowledge transfer but are capable of learning quickly by themselves
  • Training needs to be more exciting and fun.
  • Doing this for a modern, scalable, long-term solution takes time and investment
  • Building it locally is important and has its hurdles for the distributed team

Recall that one of the goals of the project was to foster ownership and solutions in the offshore team. This was a big pain point between both the home office and offshore team.  Some of the initial, easy

tasks became a profound learning experience. For instance, it was a big deal to just come up with a name for the product, name the team, or create the logo. The Vietnam team regularly wanted the home office to approve their ideas. The home offices—as much as they could—said: “No, this is for you to decide, not us.” In order for the project to be successful, the home office needed the Innovation Lab team to solve their own problems and not wait on or answer to the home team.

We had another unique systematic issue with existing skills on Continuous Integration; some staff had already worked on CI projects. The quick and easy solution was to take that experienced staff and have them complete the task, but doing that would not benefit the other team members.  The other team would not have the opportunity to be innovative or expand their skillset.  Also, for training and “local experts”—on how to implement CI—they had to find staff who had not worked on those projects.  The easy solution would become a problem in the long-run. Choosing the team over the quick solution was a first. They had to turn the experienced staff into the local experts.

With the adoption of the US training style, there were going to be cultural hurdles, as many of the staff had to think more like “Americans.”   There was also friction when team members needed to take responsibility. Accountability is important when you are working with a team far away.  Our “people issues” were frustrating.

Team reviewing a list of The 7 Habits

Another goal of this project was to have this team take responsibility in order to transfer knowledge in an innovative way. While some may love traditional delivery methods, the point was to deliver training in a way that would both: engage the work and allow for high retention rates.

The team built a new style of training. The home office asked that the training be built using a modern, mixed delivery method. It had to also be scalable, repeatable, and engaging way. Mixed delivery from the home office perspective is reading, video, homework, quizzes, lecture, discussion, practice, learn-by-doing, and exercises. Their solution would include some traditional style methods, but with more elements of practice-based techniques, incorporating elements of gamification. The managers of the project realized that it was not enough to just do the project. In order for the team member to truly learn and retain, the project had to train others. By doing this, it allowed individuals to develop personal growth and cultivate team growth. As an individual learns, they also become the local expert, which enables them to consults others that may face similar problems.

 

The results

It might have taken longer than expected but it was a success!

The first demo to other staff was big and important. Everyone wanted to be a part of the project and took great pride in their work. From this first demo, they grew in ownership and control. Once the other staff saw this as a real “lab” to practice, play, learn, and make mistakes, the understanding of innovation, “trying things,” and “suggesting things” took off. It was more than “a suggestion box.” The staff was actually recognizing the freedom to create and change.

Once the team got over these hurdles, they were able to have fun building the product and learning. The team went above and beyond. The home office asked them for two social API Integrations and they submitted four (Instagram, Facebook, Google+ and Twitter)! Plus, they added something beyond the original scope: a cloud music player.

Lab member connecting IoT hardware for testing

The key is to continually focus the team on solving their problems, and to take responsibility for transferring knowledge.

As they do more and learn more, they are innovating and optimizing. We’ve worked a lot with the distributed teams on developing modern training materials, exercises, and games.  This took the most time, but they are growing by leaps and bounds. Another lesson we learned was that while trainings are great, this lab was meant to be a work-in-progress.

Overall, for the home office and the distributed team, the learning has been profound. The offshore team is smart and can be trusted with a lot more decision making. The distributed team takes more responsibility and are excited to do so. They are no longer timid or looking for others to make decisions for them.  The spirit of innovation: experimenting, optimizing, questioning, sharing information has been lit and has taken a big leap forward for the whole organization.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006).He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.
Minh Ngo
Minh Ngo started his testing journey in 2008 as a Technical Engineer for Personal Navigation Devices at TomTom International B.V, Netherlands and joined LogiGear in 2012 as a Test Manager of TestArchitect product. He oversees LogiGear’s TCoE as Lead— responsibilities include R&D for automation, best practices, and testing services.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe