There is no doubt that the IT vendor we studied was highly productive in terms of speed and quality, delivered good quality work on time, and was the customers’ preferred IT vendor, even in the competitive multivendor setup. As the preferred IT vendor, they gained more tasks, especially in situations where other vendors were not able to deliver. Now the question is, what was the cost of this high productivity?
Financially, global agile is more expensive than waterfall methods for the customer: when talking with the IT vendor, it was clear that they were able to produce the same kind of products much cheaper under the waterfall methodology. The argument for global agile as a way to save costs, which are often a fundamental problem in global software development , was not on the agenda. When we asked the IT vendor why they were using agile principles in the first place, they explained that it was a request from the customers: the customers wanted the vendor to use scrum. Let’s take a step back and reflect on this request from the customers. When you, as a company, are hired to deliver a service or a product, negotiations about the price, timeline, and collaboration are to be expected. Clients direct requests for how the vendor is to use specific methods are less obvious. So, why did the client request this? Despite it being a more expensive methodology for the client, they gained direct access to highly qualified people, who all had proportionally high salaries (though the IT vendor then had difficulty including and training new people to work on the projects).
What about the human costs of this high productivity? What happens to people when agile goes global? If we return to the principles in the agile manifesto, we find that the principles of “working software over comprehensive documentation,” “customer collaboration over contract negotiation,” and “responding to change over following a plan” are all very pertinent in the global agile outsourcing setting as well. In our case, there was close collaboration with the customer, the scope and objectives were a moveable target, and there was a constant focus on working software deliveries. However, if we look at the first principle of “individuals and interaction over processes and tools,” we see a shift. The processes and tools created to structure the agile delivery were used to micromanage the software developers’ work in all the small details. We can view the global agile principles in our case as an algorithmic machine, with specific input and output features. The input measures are the numbers, the hours, and the deliverables deadlines, which are then used to push people to maximize their efforts. Given the tools and processes of agile, the remote client is able to monitor and control every little aspect of the work done by the software developers. Sure, global agile is very productive. If the only criteria for success is high-quality work done fast, global agile is attractive.
Nevertheless, there is a dark side to global agile, since in the case of scrum comes tools and processes that can be used to micromanage software developers. Focusing only on productivity, we risk losing sight of individuals and the “mushy stuff” that is at the core of the agile ideals. According to Jim Highsmith for the Agile Alliance, “At the core, I believe agile methodologists are really about the ‘mushy’ stuff about delivering good products to customers by operating in an environment that does more than talk about ‘people as our most important asset’ but actually ‘acts’ as if people were the most important and lose the word ‘asset’“ (http://agilemanifesto.org/history.html).
I that we must consider the conditions for work created by the constant focus on productivity introduced and controlled by agile tools and processes. This risk of the “global agile algorithmic machine” is that it turns people into assets, resources, and numbers—and we lose sight of individual developers. While waterfall methodologies have been criticized for heavily regulating work and introducing micromanagement, our empirical observations point to how the global agile methodology can also be used for micromanagement and strong regulation of software developers.
Global agile provides good conditions for high productivity in software engineering but also these risks:
Perceiving people as assets, not human beings
Creating stressful work environments in continuous work cycles
Supporting clients in micromanagement from afar
Making developers and testers work out of sync with their local time zones
What we risk losing is the focus on the software developers and the self-organization and empowerment that are supposed to be introduced with agile methodologies. Software engineering organized by global agile methodologies in highly competitive multivendor settings risks resembling the assembly line in factory work. Is this really what we want the future of software engineering to look like?