“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.