“Sometimes it takes such a long time that I actually have to write the correct code, send it over to them and ask them to implement it.”
Unsuitable processes: Even though the problems of the pull request process were well known by the onsite developers, for the managers, it all looked fine, and consequently, no measures were taken. One reason it looked fine was the key performance indicator (KPI) measurements. While evaluation metrics can be a good process governance approach to mitigate PD (section 4.8.1), they can also be misused, creating PD of type “unsuitable process”. For example, the offshore teams were measured by KPIs set by the company, and these were related to numbers they received from queries in Jira (e.g., how long a task had stayed at a certain stage in the development process). So even though many pull requests were rejected and the quality was not seen as satisfactory, the KPIs on the code and productivity were met, resulting in happy managers but frustrated onsite developers.
“The offshore teams are measured by the number of pull requests that are approved or not, but for some reason that measurement is calculated by completed Jira tasks and not actual PRs in the system where we approve the code. Often, I feel that one pull request has ten attached Jiraissues, to double the KPI. I think measuring an outsourcing partnership based on the number of approved PRs is not a good solution.”
Redesigning processes: Consequently, there was a delay in addressing and solving the well-known problem. Eventually, to mitigate the challenges of the offshoring set-up, the company introduced additional quality meetings where they looked at the PRs and discussed them. Further, they introduced Slack as a tool to make the communication more informal and faster and, therefore, more quickly could clarify issues related to PRs. The situation improved a bit.
However, it became clear the new process did not work out as intended after a while since the quality problems persisted. Further, the remote company had a high attrition rate, resulting in new experienced developers replacing the people who could deliver appropriate code quality after a year. The annual turnover rates were: 2016: 4%, 2017: 18%, and 2018: 38%. The new people joining the company in India did not have the proper technical skills, domain knowledge or process knowledge. As a consequence of low productivity and processes that did not work, the sourcing relationship was eventually canceled for the teams.