The 3 vital factors for successful offshore software development
In offshore software development, you must be aware of 3 vital factors below that will certainly help you to get the maximum value from your offshore team.
1. From working agile to living agile
A lot of organizations found that agile processes support offshore collaboration. We hire some agile consultants , train our people, make some handbooks and voila ‘we work agile’. Agile is a popular term today. People sense they miss out if they don’t work agile. So they say ‘we are agile, we follow scrum, our processes are agile’.
Agility basically means flexibility. It’s away from bureaucracy, rigidity and waterfall. Agile can refer to processes or how work gets done. But it’s also related to people. An agile process without agile people gets stuck.
With parts of your team offshore, agile behavior is crucial. We need to understand each other (the remote colleagues, the culture, why people behave a certain way). We need flexibility in dealing with the (cultural) differences. Instead of forcing our own values and expectations upon other people, we need to adapt our own behavior to the new situation. By discussing the behavior of the individual team members we get the team on the same page.
2. From fixed pricing to sprint payments
Many organizations start with offshoring fixed price projects. Managers expect fixed pricing from their vendors, as they get budgets and need to fit their projects within that budget.
Agile/scrum and fixed price are not a happy marriage. I even believe it’s the wrong combination and we should avoid it. The promise of agile is a team that builds the software the company needs step by step (instead of building what was envisioned at the start of the project). Step by step, the team determines what needs to be built. Based on what has been built, product owner ideas and user feedback, the end result might be 80% different from what was envisioned at the outset of the project.
Contracts and agreements need to become more agile. What can be provided at the start, is the scope of a project. The goal is to deliver as much business value and features within that scope. The product owner on buyers side is in the drivers seat and decides what is built each sprint. While the scope is fixed, functionalities are not. Payments can be done for the result of each sprint. We can either invoice the time spent or the % of user stories that have been done. For example: a sprint has 100 story points and 80 points get done, the invoice contains 80 story points (based on a price per story point) or 80% of the time spent. 20% of the time was ‘wasted’. If the team consists of a buyer and a vendor, they could share the 20% ‘loss’ 50-50. If there are more than 2 parties, the 20% could be shared equally.
This is the future of software development and works very well in offshoring specifically. It applies to software, but types of work can also be done with this method of paying for results. The risk is shared and interests are aligned.
3. From delivering what is asked to collaboration
The old model of IT services is a based on a black box approach. The buyer sends requirements into the black box on the vendor side. The vendor builds the product as specified and ships it to the buyer. The buyer pays what was agreed. While this model can work, we’ve seen in the past decades that many IT projects fail and I believe that the shipping to partner mentality is the one of the main reasons.
We need true collaboration. As human beings, we are building something together. There is no you and me, only us in a real team. Even if we’re part of different companies, we want to achieve the same outcome. With such mentality, true partnerships can emerge. Partners can sell each others products in their respective markets. They can develop products as a joint effort and then jointly bring them to market. The vendor aims at making the buyer more competitive, incur cost savings, win in the market. In offshoring, this mental change is crucial. The people doing the work are geographically and culturally distant, so ‘collaboration’ is needed to bridge the distance.