It was early 2008; the company executive team was working on the vision for the next decade. Our competitors were eating into our revenue and a causal analysis had shown that our legacy ERP systems couldn’t compete against the latest technologies and Service-Oriented Architecture (SOA) based rich internet applications that our competitors were offering. We had to move quickly and we had to retain and increase our existing share of 40% which was diminishing fast. What came out of the executive leadership to the delivery leadership was crystal clear. Rewrite existing legacy applications in the latest and greatest technologies currently in the market and address three main objectives

-       “Good” of the legacy system is retained.

-       “Bad” in the legacy system is not incorporated

-       “Missing” parts in the legacy system is addressed

There were strict deadlines to rewrite the legacy system and we had to have a new product ready soon to ensure we have ample market share.

The marketing team was tasked with identifying a platform to brand this new product. A usability company was contracted to ensure that the new product would meet international usability standards. Meetings were held with partner companies, OEM providers and select customers to further the vision. Indications on what was in store in the near future were communicated in user conferences and user groups.  It was also ensured that existing customers were part of the feature documentation and product backlog creation process. A detailed product map was created which listed the milestones and phases across three years when the whole ERP application would be rewritten in the new technologies.

With the affront knowledge that data migration, implementation, training and setup for an existing client would take anywhere near 3-6 months, a staggered release of application modules was planned in a way that every six months there would be a release of new application module. This way incrementally the clients could add on continuously without a feeling that the product took so long to be delivered. The technology panel selected Microsoft.Net, WWF, WPF, client server with SOA architecture as the model to move forward. Microsoft MVP’s were used to design the core framework on which the new product would be built. Enough care was taken to ensure that most of the things which would be used across application modules of the ERP product would be generic. Hence batch processing, workflow management, message center, dashboards etc were kept separate.

As the application needed to be ready soon, we decided to follow Agile methodology so that we iteratively build a system and we have something of business value coming out on a month to month basis. To ensure development is achieved 24/7 and faster turnaround of features, identified based on the objectives of our company we wanted to use a distributed development team where teams would be formed with people from both US and India. This would give us the time-zone advantage and work would continuously be accomplished and we would also be able to leverage some cost arbitrage. Agile was abuzz when we started on this product development. We had not tried Agile development in our company and from the industry we had come to know that Agile is what is being embraced in most of the product companies. Our leadership felt Agile was the perfect match to what we wanted to achieve. It was the right framework for us to embrace for the application rewrite. At least this framework emphasized on the need for involvement of the product management and the development teams on a regular basis and promised a tangible deliverable which can be assessed at the end of every sprint.

We came up with a resource plan which started initially on the presumption that we would have two developers from US and three developers from India in every virtual team. We had a phased six months ramp up schedule wherein this team would eventually grow into 16 developers in the US and 24 developers in India. This way we would be able to run eight parallel teams and churn out features at a very fast pace. We faced multiple issues when we went about setting up a virtual team for our development. These were basically across people, technology and process.

People: Ability to work in Agile teams

Our developers were used to working in the standard water flow methodology. They expected clearly defined requirements and would completely design the overall product and then get into construction, validation, verification and deployment of the new product. Agile was something new and uncharted waters for the whole team. All that we developers could conjure was surprise at how the whole activity which we used to span over three to six months can be condensed to every sprint of a month’s duration. There was confusion everywhere as to what is the Agile way and there was more confusion than understanding of the Agile methodology.

Reward and Recognition

With the advent of virtual teams and strongly skilled people working in teams, we faced the problem of motivation. After a few months, the work started getting monotonous for everyone. Initially there was the aura of new technology and the challenge to learn new things and put new frameworks in place. But after a while it was only about developing maintenance screens. Both teams alike felt that their counterpart in the other geographical area was getting the best things to develop and implement. It was difficult to appease both the worlds. We had to come up with small teams within teams where members were from both US and India and give them specific technically challenging things to keep both the sides motivated.

 Aspirations and Career Progression

Aspirations of people in US and India were totally different. People in teams in India after a while felt that career wise they were hardly progressing. They believed that though they had the same experience as other managers in the company they were just scrum masters of a small team. They were unable to see any progression or promotion to any new role. Agile as a methodology which was being followed in this project did not provide them with any scope to play any role higher than that of a scrum master.

Technology

When we started on the technology stack identified by our technology team we realized that we were working on the latest version of the software. It was a big challenge to work with the newer versions of the software and information or assistance on these products was very less. The support groups were very few and there were innumerable delays to iron out insignificant of issues which came in the way of our feature development. We had to define a training plan for people who would join our team, it became very necessary to have a skill up gradation plan as we would for sure never get people on these latest versions and we had to revisit our plans based on the learning curve of the developers.

Network

Our company had a decent connectivity with our US office. Once we started development on the new product line we realized that our network was choked with the amount of traffic coming in. We had the servers situated in US. To ensure all development happened out of the same source code and that we have versioning of the source code maintained on our servers developers would connect to our central source database. We had never envisaged a situation that network bandwidth could cause productivity drop. We had to plan a proxy server at our India location to ensure the developers here would access the source code from a local instance rather than US.

We also had to increase our budget for internet bandwidth so that we could support better connectivity between the two offices. This way we would at least ensure technology is not a roadblock for the success of the project.

Domain Knowledge

Most of our teams in India never realized the significance of the work we were trying to deliver. They never understood what we were trying to develop. On detailed verification of the instances we realized that the process of how things got done were different in the US visa a vie India. We realized the team in India totally lacked the domain expertise on the subject and hence there were problems galore.           To address this we had to bank on in-house knowledge banks. A few of the Indian colleagues had worked on testing the existing ERP application. We turned to them to work with the documentation team and come up with quick help and explanations on the domain. We had to arrange for help available from the current application and schedule small quiz to test the understanding of domain within our teams.

           

Tools

Once we started on the virtual teams which had a time zone difference, we came to realize that we had lot of confusion gaining ground when we discussed features over the phone. From a root cause analysis we realized that if we did any discussion within a room full of people, everyone would be engaged and we would be able to successfully deliver the feature. With the virtual team, intra team communication itself was suffering due to the distance. We invested in headphones and cameras for each individual in the team and enabled video calls over our office communicator. This way we started to have daily stand-ups over video calls, which helped us overcome a lot of confusion over our daily work and helped increase productivity. Once we started ramping up the teams we realized that two conference lines were never going to be able to support all the eight teams. Usually whenever the teams dialed in to discuss on a developmental feature, they would be surprised to see that they were intervening or we had to go back and procure more conference lines to support all the eight teams.

Processes

Time Zone

Due to the time zone difference, our teams both in US and India had to stretch to work around to ensure they had daily standup calls. Especially during the monthly planning and scrum closure meetings, one of the teams usually had to either come early or stay late.

Team meetings

We had to formalize a time zone specific team meeting to ensure everyone in the team across the time zones attended the team meetings and that everyone is informed of the progress on the project. We had to bring in an outlook calendar item for every conference line we had to ensure that people blocked the calendar for a particular conference line and then no one else would barge into their call.

Process Call

With the Agile process when we took the help of a process consultant he pointed out to us the need for all scrum masters to meet on a weekly basis to identify and correct course. We setup a weekly call wherein we would discuss across the board on the different processes we have setup and how we can go ahead and improve them. This helped us overcome a lot of challenges in the project. We were able to discuss the challenges and setup a process to overcome the same.

Testing

When it came to testing the application we realized that domain knowledge was scarce and we had to ensure that the QA is part of the team and is embedded into the scrum team so that we take advantage of the fact that we continuously test as we build. It was a challenge to test deliverables across geographical teams and we had to come up with a detailed QA process to ensure when the QA can start testing on a deliverable and how the handshake between developer and QA would take place. We had to procure a sophisticated defect management system and set it up to help the QA of our product. When we realized that sprint QA would not suffice in our product testing we introduced a testing phase at the end of application module. This would ensure that we would be able to catch any defect which would have gone unnoticed during the sprint QA.

Communication

During the course of our project, we realized that there were multiple instances where we could sense a communication breakdown. People on either side were not able to communicate effectively. Either the Indian team mates were talking quickly or they were not able to understand the American accent. Though we were comfortable interacting with each other, when we ramped up the team completely we had people from every nook and corner of India. There were people who had immaculate communication skills, but we also had a mix of people who had a strong mother tongue influence. They also came from different backgrounds and had a specific choice of words based on their vocabulary. We had to invest in training them on accent neutralization and communication effectiveness. This helped us overcome a lot of barriers in both written and verbal communication within the virtual teams.

 Travel

What we realized from day one was the need for the teams to have face time with each other. Until or unless we ensured teams spent time with each other the trust factor would be sorely lacking. To achieve this on a budget that would be affordable we introduced a process wherein every quarter 2-3 people from both US and India team would visit the other country for a period of two weeks. This way they would collaborate better and build a relationship which is far better than working as aliens across the world.             This truly benefitted the project. After a few quarters we saw that teams would pull up their socks better to meet deadlines, the teams from either side would still work towards the sprint goal even if one of the team members was not available etc. This helped when we wanted the product owner to travel to India and spend time explaining the product roadmap, the overall domain etc.

Case Analysis

Our team is of the opinion that people, technology and processes have to work in tandem for the success of any virtual team. Whenever we are part of a virtual team we are bound to have problems thanks to the time zone difference and the cultural differences. Whenever we introduce a radical change like introduction of new technology or new way of doing things we need to factor in some time for the change.

We also have to work with an open mind that there is no silver bullet which will solve all the problems we face. We will have to prioritize and address each and every issue as it crops up. Though virtual teams offer a lot of challenges when the machine starts working it are simply a beautiful experience to be part of such a team. All the hard work and effort is meaningful and successful virtual teams offer a definitive competitive advantage.

 People: Ability to work in Agile teams:

The company has to realize that it is not easy for people who are accustomed to certain ways of doing things to actually learn something new. Such a sudden change of direction has to be followed with ample support and training. Anything dramatic such as moving to a different methodology has to involve training the leaders first in Agile methodology and follow up with a directive that the leaders train the new people who join this team. The training has to be same across both the geographical locations so that understanding and implementation is so much smoother. We hired an internationally acclaimed scrum coach to train and certify our people across the geographical locations. It cost a lot for the company to get most of the scrum masters certified by the scrum alliance. We also had to invest heavily in the culture training. We realized some months into the project that we were having people issues across the teams. Very few people could realize this had got to do more with the way the different culture’s reacted to situations. When we met a trainer who used to train multinational corporations on getting onto a third culture, where everyone in both the geographically separated teams were made to realize how the culture views things, the productivity got better and everyone had fewer people issues, we realized that’s what we had to invest for making this team a success.

Technology

We also believe that technology plays a strong role in today’s workplace. We have to identify and implement the right technology to take advantage of the benefits it offers. It is imperative in today’s competitive world that we have to adopt and utilize technology for our competitive advantage.

Process

What has been a differentiator in our success has been the fact that we have been able to identify the right process which becomes our recipe for repeating success. It is essential that we learn from our mistakes and put in the right processes to address them. It is not very easy to setup a virtual team. Any team either in house or virtual needs a lot of patience to build. The amount of effort needed to build and sustain a virtual team is immense. There are many problems which are caused by various factors when we work as a virtual team. The management has to be receptive to these challenges and needs to work with patience and with a long term strategy to make virtual teams a success. The investments in a virtual team will pay off in the long run and line managers from both the geographical areas need to communicate and resolve all the differences that crop up and identify means and methods to correct them as they go.