This blog is all about my experiences and insights as an Offshore Software Development Entrepreneur. It describes the inherent challenges that come with offshore development as well as the solutions we use at Ignite to create a high-performance cost-effective onsite-offshore software development model.
This is indeed a remarkable achievement, especially in India with its well known high turnover. What is the secret that my second colleague knows?
Well, basically, he knows that it is really hard work to keep people happy and challenged , yet he is willing to invest (and this is indeed an investment with measurable ROI) this time even though these developers are not on his payroll.
Here are some of my insights on the subject:
"…We invest a lot of time in establishing long-lasting relationship with our developers. There's no other way, if you want to avoid the huge cost of high turnover. I have been practicing offshore software development for over than 8 years now and I believe this is definitely one of the largest enemies of this field.
We managed to achieve a constant average of 5% turnover per year in the last four years. I think this is a normal turnover that reflects the natural need people have for change. I'll try to summarize my insights on the subject:
We prefer working with an Easter European facility rather than an Indian one. We found that in general, the Eastern European are more loyal and are not in a constant search for the next opportunity. They value stability and technical challenge more than an insignificant salary raise gained by replacing an employer. Moreover, working mainly with EMEA region I find the Eastern European alternative much more effective, in terms of lesser mentality gaps, closer time zones and lower costs for travel logistics.
We employ an "Ambassador exchange program" – every 2-3 months we send our onsite project managers to work offshore face to face with the offshore team and vice versa – sending offshore R&D team leaders to work on customer site. This serves several purposes: in onsite visits R&D team leaders really start to grasp the customer's line of business. When they come back to their offshore location they can then provide an added value of understanding their customer's business objectives and not only the technical requirements, like they typically do – staying in their comfort zone. This helps a lot in the onsite-offshore communication. Also, it gives them a sense of the bigger picture and belonging to the customer's team which reduces retention.
When working offshore, the onsite project managers, finally understand the difficulty in working offshore – it's like working in a glass bubble – you hear only some of the voices and considerations yet you are expected to produce as effectively as someone onsite who is fully aware of all the considerations of all stakeholders. When they come back to their onsite location, they communicate the bigger picture to their offshore developers much more clearly, which makes the team much more cohesive.
During these ambassador exchanges we encourage social activity between our project managers and our developers. People who drank beer (or Vodka!) together somehow communicate better even when they are separated again – there's some "invisible glue" that was created during this social activity. Again, it also strengthen loyalty and create long-lasting teams – people prefer to work with their friends.
We provide training courses as well as professional certifications to our developers free of charge. In general Eastern European value dearly their professional development and achieving industry-standard certifications (in Java, .NET , Scrum etc.) is very important for them.
On top of the benefits that we provide to our developers as an employer, we also encourage our customers to strengthen the corporate brand and sense of belonging in various ways: it could be a small appreciation bonus on a successful delivery, a company event in the offshore location, a vacation sponsored by the customer or even just a simple shirt with the customer's logo – sometimes that makes all the difference in the world."
"What happens if the customer is not familiar ith Agile methods, can you still utlize Agile development methodology in such a project?"
From our experience at Ignite, it is not mandatory that the customer will be educated with regards to Agile practices.
For example, we hade an incident where the customer's own in-house team worked in a traditional waterfall model. The customer's outsourcing experience was based on fixed-price engagements only, where, from his point of view, the outsourcing risk is manageable, and still we managed to bring a distributed outsourced onsite-offshore team that practiced agile in a fixed-price model, working collaboratively with the customer's in-house waterfall R&D team.
The customer heard about Agile and was willing to give it a shot as long as it will not take too much overheard, and as long as this would still be a fixed-price engagement. Once we requested, and he agreed, to allocate a product manager to work with us, our onsite project manager assumed the role of product owner (this was a Scrum team), working face to face with the customer's product manager on one hand and managing the offshore R&D team using Scrum internally.
Typically, the customer's product manager should have taken the product owner role, but due to lack of familiarity with Agile practices he preferred to stick with traditional methods. Our project manager "interviewed" him at the beginning of the project, created a set of high-level user stories and defined the priorities based on the objectives set by the product manager. Although all the guidance was coming from the product manager, from the offshore R&D team perspective, the product owner was our own project manager, they did not communicate with the customer's product manager directly.
We assigned the stories/features to 3 weeks iterations and kicked off the project. Towards the end of each iteration our project manager would sit down with the product manager, present the upcoming deliverables and then the two used to reprioritize the features of the upcoming iteration.
As in any other software development project, the deliverables of each iteration triggered some insights and new understandings of the final product and often – some change requests. On one hand, this was a fixed-price project and therefore change requests are billable and might break the budget and due date objectives, on the other hand – we are practicing Agile methods which welcome change requests as natural part of a software development process.
To solve this dilemma we utilize a process of exchange requests rather than the plain change request procedure. In an exchange request procedure our team will examine the requested change and try to identify a lower priority feature, with similar effort estimate, which was not developed yet, and can be exchanged with the change request at hand. This way, we still meet the customer's due date and budget objectives while responding to change.
Of course, this is not an accurate science. Sometimes it's not so easy to find the perfect candidate feature for this feature exchange. On average a fixed-price Agile project will have between 10%-20% budget overruns due to change requests. Having said that, it is still much better then the grim statistics of standard waterfall fixed-price projects where 60% of them are 200% over the agreed upon budget!