We cannot with any honesty call the offshoring that has been in existence for the past three decades a distributed development model. One of the primary condition of distributed development is that every one of the distributed teams must function in an autonomous manner. Please note that autonomous in this context is never full autonomy for the distributed team, their decisions are always bounded by the clients bigger product vision and direction. There is no benefit in the early stages of a startup, to hand over autonomy to remote distributed teams. This will change as the product matures and team dynamics improve.
The current offshoring model use of the term distributed is mostly a marketing ploy. The model is more representative of distributed as in, divide up. The necessary work is divided up (by the client or his representative role) and then handed over to the remote teams. This chunking allows the work to be quantified in terms of effort, and hence also converted to monetary terms. This working model also explains why the transition to agile teams was (and still is) so difficult for offshoring.
The financial risk was a known or at most calculable in the old model.
In the agile development context, learning went hand-in-hand with the idea of fast fail and iteration speed. This combination increases the required competency level of the team members. Agile, instead of alleviating the clients risk, made its monetary quantification more complex.
Although, the idea of a long term relationship between the client and the service provider, and its supposed (not so conclusive) benefits, it is difficult to quantify the reduction in risk this brings to the client. One would expect the combination of agile, devOps and continuous delivery would reduce the risk to the client. But, as usual “knowing of” and “knowing” are two entirely different things. Exploiting these techniques requires a qualitative leap in the team structure and dynamic. Exploitation is not only about choosing the right technologies. It is about the empowered team to stand up and take ownership and responsibilities, it is this dynamic that is also the most fragile.
For the startup (client) that offshore its work, the experience of managing the dynamics of team structure, the domain and technology complexities, may turn out to be a total catastrophe. Distributed teams failures can also have a monetary charge on other teams that are successful, by increasing their wait time. Such failures disturb the working dynamics of the teams and increases the long term relationships, the onset of the blame games.
As long as the offshore service provider has an option to just transfer resource from a lost client to a fresh client, the risk for failure is solely carried by the client.
What is required is a risk transference mechanism that will change the working relationship of client and service provider to one of carrying a shared risk. Such a shared risk is necessary for the clients to accept the service providers offering of distributed autonomous teams.
Having a penalty clause in the contract is not the same thing as risk sharing, it is more a contingency plan for the client. More importantly, the penalty is a reputation risk cover for the service provider. This can easily be indemnified against, and the larger the organisation the more ineffective. Since the client faces many different types of failures each with a different chance of occurring, and different amount of loss, a single number such as a penalty is unsuitable.
From the service providers perspective the risk transference must lead to an incentive to differentiate and improve his service provisioning. Without such a motivation the service game will only follow the old rules with very little hope of long term sustainability of the service model.
There is a body of study that suggests that financial options are a suitable contract for such a risk transference. But, in practice this is an unknown quantity in the offshoring sector.