Sparked by the publication of Harry Braverman’s now-canonical Labor and Monopoly Capital, Marxists and other leftists mounted manifold criticisms of capitalist work regimes throughout the 1970s and 1980s. These discussions, later dubbed the ‘labour-process debate’, primarily focused on the thematic of Taylorism – the influential and enduring set of organizational principles developed by Ur-management consultant Frederick Winslow Taylor, who sought to synthesize industrial workflows by decomposing tasks, standardizing procedures, eliminating waste and siloing labourers. Though many of the labour-process analysts considered the extent to which Taylorist maxims had spread beyond the shop floor – impressing themselves upon so-called ‘white-collar’ work in administrative, clerical and service sectors – there was one nascent field that did not elicit any particular interest: software development. Still predominantly a military endeavour, it was occluded by a focus on workplace automation in general.
Much of the working culture of software communities appears collaborative by design. The labour and knowledge indexed by discussion forums, listservs, how-tos and public code repositories stand in contradistinction to the bureaucratic rationality of industrial assembly lines. Yet, as we shall see, two managerial strategies have thus far prevailed in software development’s history. The supremacy of one of these strategies over the other – Agile and Waterfall, respectively – is cognate to a broader structural renegotiation that took place between capital and labour in the twilight of the twentieth century.
Beginning around 1970, in response to what several NATO Software Engineering Conference attendees had diagnosed as a ‘software crisis’ – wherein unwieldy, difficult-to-manage initiatives routinely exceeded their allocated budgets and timeframes – attempts were made to mould computer programming in the shape of the scientific-managerial doxas then in vogue. Various methodologies were suggested to solidify the field; one – the Waterfall model – was eventually victorious following its adoption by the US Department of Defense. The intent of Waterfall was to systematize the often ad-hoc activity that comprises large-scale software production. Among the features that enabled Waterfall to conquer rival methodologies was its division of software development into six sequential stages: requirements, analysis, design, coding, testing, and operations.
The familiar features of the Taylorist factory floor are here transposed from industry to information technology: each stage corresponds to a dedicated department of specialists, who mechanistically repeat their métier ad nauseum. In Waterfall, work cannot begin on any one stage until work on the preceding stage has been completed and its quality assured, with the only necessary coordination between stages being the assurance of ticked checkboxes. Participatory input is discouraged; requirements provided by managerial strata in the first stage chart the full course for the following five. Improvisatory exploration is suppressed; formalities such as contracts, approvals, specifications and logs abound.
In the last decades of the twentieth century, criticisms of Waterfall in software engineering meshed with a new wave of criticisms of work erupting throughout the Western capitalist world. These expressions of popular discontent did not just take aim at the familiar target of exploitation, as conceived by the trade union movement. Rather, they emanated in large part from a relatively affluent subset of the younger working population, disaffected with the heteronomy of work, and emphasizing affective-existential themes like boredom, dehumanization, inauthenticity and meaninglessness. Marking a shift from quantitative material demands for wage increases, employee benefits and job security, this qualitative critique of working life resonated with the vocabulary of urban intellectual and artistic circles. This is what Luc Boltanski and Eve Chiapello refer to in The New Spirit of Capitalism as the ‘artistic critique’: an attack on bureaucratic calcification and hierarchical segmentation, on infantilizing work routines, stern schedules, and a sense of futility under the rubric of Taylorism.
The artistic critique instituted something of a paradigm shift in managerial literature during the 1990s, as new organizational forms were required to render capitalism seductive once again. The rejection of once-sacrosanct bureaucratic-rational principles of twentieth-century scientific management was so pronounced in this literature that Peter Drucker, prominent management consultant and prognosticator of ‘post-industrial society’, termed it a ‘big bang’. These texts – drafted by business managers, organizational engineers, industrial psychologists and the like – were a laboratory in which a properly twenty-first-century capitalist ethos was concocted: a new ‘spirit’, based on cultures, principles, assumptions, hierarchies and ethics that absorbed the complaints of the artistic critique. What emerged was a novel social arrangement, fashioned especially for skilled workers and the children of middle-class cadres, whose regulative principles were employee autonomy, participatory exchange, temporal flexibility and personal self-development.
Boltanski and Chiapello call this arrangement the ‘projective city’. In the projective city, the vertical command-control structures of the Taylorist factory are supplanted by the horizontal ‘network’, whose absolute and ideal amorphousness comes to dominate life both inside and outside the firm. This transformation imposes new operative compulsions, hierarchies of status, intra- and inter-firm politics, and affective states on wage-earners. In the projective city, the central locus of daily life is the project: the determinate activation of a discrete subsection of the network for a definite period and toward a specific goal.
The project – and its regime of continuous activity, the proliferation of which forms an end in itself – becomes the precondition for the connections between agents in the network. Agents cohere into teams which then disperse once the project’s common endpoint has been reached; success on one project is measured by each person’s ability to make it to the next. Rather than a career spent dedicated to a single specialty within the protective environment of the large firm, agents in the projective city are encouraged to multitask, collaborate, adapt and learn by forging interpersonal connections through successive projects. These agents can then incrementally leverage the skills and connections attained on past projects into more interesting, diverse, and – what amounts to the same thing – prestigious future projects, the very heterogeneity of which becomes their primary mark of esteem.
In the aftermath of Y2K and the bursting of the dot-com bubble, a new workplace methodology called Agile emerged as an attempt to sow these principles in the technology sector. Agile’s manifesto – drafted by an alliance of 17 software developers at a Wasatch Range ski resort in 2001 – consists of a mere four lines and 24 words, outlining grammars of action heretical to the Waterfall bible:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
Agile is everything that Waterfall is not: lightweight, incremental, fluid, encouraging plasticity with regard to tasks, roles, scheduling, and planning. Whereas initial stakeholder requirements in Waterfall are binding – often the product of months-long planning – Agile’s recurrent testing of products in-progress allows for feedback, reevaluation, modification and pivoting. So-called ‘lean’ teams are released from their individual silos, pushed toward an ideal symbiosis via an endless ascesis of observing, listening, and questioning. Face-to-face interaction and exchange become conduits for learning and self-development. Team members are interchangeable, picking up variegated tasks as needed by the project, countervailing Waterfall’s tendency toward increasing atomization and autonomization of spheres. Here enters the figure of the Project Manager or Team Lead – whose responsibilities can overlap with the Product Manager or Product Owner, depending on the environment – who acts as a facilitator: connecting individuals, redistributing information, unifying energies, routing vectors.
Today, these values congeal around a set of shared terms and best practices. Much of the vernacular antedates Agile, inherited from previous collaborative workplace methodologies like Scrum, Extreme Programming, DSDM or Crystal – but all have now been absorbed into its lexicon. In the Agile firm, the temporal unit of measure is the sprint, so called for its brevity and its intensity. A sprint ranges between two and four weeks, instilling a sense of urgency in the sprinter. While the activity that takes place within it is not strictly scheduled, a predetermined chunk of work must be completed by the time one reaches the finish line.
On desktop, the sprint is visualized two-dimensionally as a horizontal tableau of epics, stories and tasks. Epics correspond to projects, subsuming several stories and tasks. Stories are kept intentionally vague, merely denoting a single functionality that the finished product must support, in the format of: ‘as a <type of user> I can <action> because <intent>.’ While multiple individuals are assigned to a story, single individuals are assigned to a task, which is the smallest byte of work in the project. In the same vein as the sprint, the stand-up or daily scrum keeps team members on their toes; at the start of each working day, programmers assemble and serially recite the tasks they have achieved since yesterday, and which tasks they intend to achieve before tomorrow.
Agile has now not only usurped Waterfall as the dominant paradigm of IT, it has also spilled into areas beyond software development, including finance, sales, marketing and human resources. In recent years, a wave of gargantuan firms in legacy industries – Barclays, Cisco, Wells Fargo and Centene to name a few – have undertaken company-wide ‘Agile transformations’, plucking ‘coaches’ from top business schools and the Big Four consulting firms, and at the same time creating a vast market for productivity software suites made by big-cap companies like Microsoft, Atlassian, ServiceNow and SAP.
The question that nags is: why are employers across sectors willingly, even at considerable expense, instituting changes of this nature? Only one of two possible answers can suffice. The first is that these concessions are plain acts of benevolence on behalf of executives and shareholders, who aim to placate the legitimate malaise voiced by the artistic critique. The second is that a silent bargain between capital and wage-labour has occurred, with capital steadily shedding impediments to accumulation, and wage-earners forfeiting hard-won security in exchange for putative freedom.
It is clear that Agile dissolves many of the more visible features of hierarchical managerial control. But it does so only to recontain them in subtle and nuanced ways. For one, the self-organizing strategies of teams allow for certain workplace disciplinary mechanisms to take the form of normative compulsions rather than explicit instructions. Here, the complex interpersonal modalities of ‘sprint planning’ are illustrative. At the start of the sprint, teams convene to assess the tasks they’ve prioritized. One-by-one, the Project Manager identifies each task, describes what it entails, and asks if the criteria make sense. The goal is then for the team to map story points to that task, which is a number that defines its level of complexity. The team cannot discuss the next task until all team members have mutually agreed upon the current task’s number of points.
In hardline Agile firms, a device called point poker is used. In this game, team members blindly impute a number to the task – they ‘point’ – and then the Project Manager ‘reveals’, showing the level of complexity that each team member believes the task to be. There is an element of motivation psychology here: no programmer wants to be caught assessing a task assigned to them as exceedingly difficult, an anxiety that exerts a consistent downward pressure on the number of points assigned to tasks. Because points can be doled out until the sum of points reaches the velocity number – the maximum of points that the team can reliably handle before the next sprint – pressure is exerted upon individuals to shoulder a larger workload.
The homeostatic regulation of the Agile team accrues additional advantages to capital. Its internalization of discipline renders redundant much of the managerial and supervisory strata of Waterfall. This is also the case with the necessarily transient nature of the connections between agents in Agile: links to product owners, leaders, managers, teams and outside firms can often last solely for the duration of a single project. A project-centric culture, coupled with the premium placed on lean teams and fungible team members, encourages wage-earners to move freely not only from project to project, but from firm to firm. Hence, we see the proliferation of recently devised hiring instruments like temping, subcontracting, outsourcing, zero-hours, freelancing and permalancing, forming part of the basis for what has come to be known as the ‘precariat’. In this way, through the mores and rhythms of the work itself, relationships are rendered tenuous, and employers are freed from the commitment to long-term employee well-being.
The virtue most venerated in the Agile environment is autonomy – which, in practice, amounts to a cult of individual performance. All are engaged in a constant battle with ossification. Ceaseless self-education, self-training and self-improvement is required. Workers must practice both the one-upmanship of accruing more responsibilities on projects and the continual anticipation of future competency needs. Threatened by what Robert Castel calls ‘disaffiliation’, an anxious self-consciousness pervades the projective city. Make yourself useful to others – or die. Boundaries between work and non-work disintegrate, not least due to the voluntary labour one must perform to extend one’s network socially. Underlying each project, the long-term personal meta-project is employability. For that, it is not enough merely to complete the task: one must distinguish oneself.
There are also the more familiar corporate control mechanisms that Agile’s progenitors claim no longer exist. Principles of self-determination clash with technocratic implementation. In today’s corporate pantheon, the Product Manager or Product Owner is a kind of hybrid entrepreneurial-aesthetic visionary, embodying the qualities previously associated with the artist of high modernism. The software product is the outcome of his creativity and ingenuity. While his co-workers are not figured as employees, but as formally equal teammates or collaborators, behind this façade the Product Manager enforces an ever intensifying work regime: ticketing systems to monitor activity, daily stand-ups to create accountability, deadlines to meet quarterly revenue streams. By breaking down his reveries into actionable assignments to be fulfilled in the span of days, the Product Manager controls the pace at which technology is created. Decision-making rests upon his word; deploying the product as quickly as possible is his objective. Under this despot cloaked in a dissident’s garb, the Taylorist separation between conception and execution reappears in the projective city: as if Agile has itself succumbed to the rationalization it pledged to banish.
Read on: Rob Lucas, ‘Dreaming in Code’, NLR 62