< < back
(this essay was originally written February 8, 2024)
“...there's something unpleasant about other people's fantasy lives, and in seeing your own in them, about your own rich subjective world being basically not that dissimilar to this other guy's ongoing attempt to recreate old plotlines of naruto except with dragon people.” ~thecatamites
I.
The JIRA system functions as a shield between a team of developers and their collective desire. Productivity systems, especially software, function in general as a shield between the individual and their desire. With no shield, the individual wants to do something and then they do it, if they can. The software acts to intervene in this process. First the individual notices a desire. They enter the desire into the software using whatever tools they are provided. Then, afterward, they return to the software and take their actions back out.
The software is allowed to transmute the desires in whatever way, in the meantime. But the only necessary ingredients for it to work as a shield are time and distance. You place the desires in the system and now they are the system’s desires, not yours, and so when you later act on them you are merely acting as an agent of the system. It may turn out that later you no longer desire what you put in, or it was poorly formulated, or you never really wanted it in the first place but only thought you did. All of these problems are disavowed, either as flaws in the system or as irrelevant to the process.
Productivity tools for individuals allow someone to do this to themselves, but JIRA is intended for a collective. This changes the form of the disavowal in a few ways. One, it adds in the opportunity for blame: I was just doing what the system told me to; if there are problems, it must have been the others who didn’t do their share. Two, and more interesting, it siloes desire into compartments and thereby frees the individual from desiring outside their compartment.
First there is a producer. The producer’s desires, within the scope of the system, are purely desires of process; they have no opinion on the work. To accept this, the user of the system must take as axiomatic that process and product are independent. A process is decided and then a product emerges around it, or maybe a product is created first and the process is a recording intended to replicate the steps; either way, the two are separated.
Then there are leads. The desires of the leads are purely desires of character: their role, while they act as leads, is to shape the character of the other people in their profession. A leader of designers is intended to act as a designer of designers; they shape the process of the other designers in the system. Notably, this is a two-way disavowal. Of course the non-leads can disavow responsibility for themselves - they are only acting as agents of the lead - but at the same time, the lead disavows responsibility for the act of production in itself. The lead designer, busy designing other designers, now has no time to design a product; the lead artist disavows the production of art; the lead programmer disavows the program, and so on. If the design or art or program fails, the leads are only culpable insofar as they failed to foster “success mindsets” in the others.
There are other disavowals that might happen depending on the details of the product. For example, in a video game, the disjunction between “design” and “programming” allows for a different kind of mutual disavowal. The production of designs is kept separate from their implementation. The designer, in their silo of ideas, is shielded from the ground-level truth of computers: the for loops and abstractions and object inheritance that underlie the games they draw inspiration from. Meanwhile, the programmer is shielded from the need to evaluate their program in terms of emotional charge or personal fulfillment; it’s not their desires, they’re just middlemen. Sorry, sir, I just work here.
JIRA fosters and informs this process through the mechanisms of action items, assignment of tasks to individuals, and as a medium for the enabling of Scrum. Scrum is itself a form of collective production-disavowal; planning, production, and retrospection are compartmentalized. Consequently the individuals are freed/restrained from producing while they plan, planning while they retrospect, etc. And the production of Scrums itself is shielded from any of these things: a Scrum user is intended to plan their sprint-planning process separate from the planning of the work; duration of a sprint is separated from its content; structure of a retrospective is separated from the thoughts themselves.
More energy put into the system, rather than going towards building more desires, or more powerful programs to fulfill the existing desires, tends to go towards crafting more disjunctions. A team grows bigger, so now there is room for more leads, sub-leads, co-leads, middle managers and so on. The team gets more time, which is all the more room for planning and planning-of-planning and planning-of-planning-of-planning and on to infinity. As a result, the most important lever within the context of a JIRA system is never the amount of resources given to the team; rather, the final product - especially for creative works - is most defined by the amount of work that skirts by the process, the extent to which the machine fails to contain its parts.
II.
It is my opinion that this distance, instead of being an unwanted byproduct of the JIRA/Scrum system, is in fact its primary function and the direct goal of its use. The JIRA system is offering the collective an opportunity to disavow the desires they and the collective are indulging to whatever extent they can.
Why? What benefit does this ritualized disavowal offer the collective? The system, initially confusing under a worldview where desire is the basic unit of action, straightforwardly chased, makes more sense if desire is instead perceived as a furtive, dangerous wrench in an otherwise smooth mechanism. This is true of the team, whose collected images of the desired final product are rarely synchronized and often look entirely incoherent together. It is true of The Industry, which is nothing if not a process of perpetual tension between market forces, artistic drives, and the (imaginary? idealized?) insatiable consumer. Lastly, and most interestingly, it is true of the individual regarding their own desires spread out across time.
The JIRA/Scrum system shields the members of a collective from each others’ desires by acting as a neutral intermediary. This is justified instrumentally, as a means to divide labor by talent and interest. The producer is best at managing the system, the artists are best/happiest with a drawing tablet, the programmers can specialize in understanding the computer, etc. The individual is then freed to desire only within their chosen lane. They are freed from the burden of the whole; the system is trusted to figure out the rest.
In practice the system - including the above justification - acts as an instrument for the indefinite deferral of conflicts. Desire is heedless of what is socially convenient and is therefore dangerous. JIRA, as a storehouse of the team’s desires, absorbs all the charge and pushes conflict into itself. The desires, now inert on the task board, can be freely compromised. As long as the two contradictory desires are managed through this intermediary, it can defer a final resolution to the contradiction fueling the conflict. This deferral can continue, theoretically, until the product is shipped.
Of course, the contradiction of desire exists outside the team. In The Industry, so the legends are told, desire fights an endless war with capital. JIRA presents a productive front that allows the desires of investors and stakeholders to blend with the desires of the laborers, shielding them from their own relationship. The stakeholder asks for a task; it is added to the task board; later, when the laborers take in actions from the board, the tasks of the stakeholder are muddled together with the others. It is JIRA, not capital, that tells the team they need a new set of animated GIFs for their pitch deck (or that they need a ‘pitch deck’ in the first place). Anyway I can see you rolling your eyes back there so I’m going to cut this bit off and move on.
JIRA is built for teams, but productivity software is marketed to individuals as well; besides, the interpersonal conflicts in a group are generally downstream of intrapersonal conflicts in their composite individuals. The user might resentfully buy into JIRA as a social defense between their desires and the desires of others, but to do so wholeheartedly, to endorse the program, implies an interest in deferring desire internally as well.
Desire is both dangerous and unattractive. Examples of work produced by processes closely attached to unshielded desire: fan fiction, children’s crayon drawings, amateur pornography. The need of subjects to shield themselves from their own desires runs deep in the psyche, and grows more and more frustrating and confusing when the subject is at the same time coerced into creative labor. Hence the productivity software: a machine to churn up desires and thereby act them out while simultaneously disavowing them.
III.
They say it’s much easier to critique something than to present a plausible alternative. Well, they say lots of things, many of which contradict; nevertheless, here I will propose an alternative to the JIRA system that could be slotted into the existing college environment without needing any radical external changes.
First, I propose the abolition of hour-logging, daily check-ins, use of the JIRA task board to organize items, and any sprint planning and retrospectives. Work will still be split into sprints, but only so that there are multiple deadlines to produce playable builds before the game is complete. However, sprints are offset; programmers begin work a week before the artists, who begin work a week before the designers. There will be no producer; there will be team leads, but their only additional responsibility will be preparing the final build at the end of each 4-5 week sprint. During the rest of the sprint, the disciplines act as though they do not have leads.
The system would work like this. The programmers, without any input from the other teams, begin in the first week by making a set of tools in an engine for their preferred game genre. Each artist, starting in the second week, uses the set of tools given as a prompt to create a set of individual assets; again, there is no communication with the other disciplines, but here the artists are not permitted to communicate with each other either. Production of individual assets is done completely independently. Starting in the third week, the designers come in and create one level each using the assets and tools previously created by the programmers and artists. At the end of the sprint, the leads choose the order the levels run in and test to ensure the build runs without game-breaking bugs. They are not permitted to edit the content of the levels, only arrange them and fix problems that would PREVENT (not inhibit) the player’s progression through the build.
After a build is created, everyone in the team plays through it start-to-finish as a group. They can communicate their thoughts on the game informally, but no processes are necessary to scaffold this. Then, for the next sprint, the processes repeat. Programmers create a new set of tools, building on the previous; artists create a new set of assets; designers create a new set of levels. The initial tools, assets, and levels CANNOT BE TOUCHED. At the end of the sprint, the new levels are arranged into the existing build as the old ones were; the second build includes all the old and new levels in whatever order the leads prefer. Again, once the second set of works is produced, those works can no longer be touched. This process continues until the semester ends; the final build would likely result from three to four sprints.
Rather than attempting to synthesize the works of the different personalities into some kind of imagined coherence, this system would turn the tension and discord inherent to the development cycle into raw materials for the final product. The works produced by this method would be collages of desire; the different visions of the programmers, artists, and designers all visibly grinding against each other on the player’s computer screen. Each individual on the team exercises absolute creative freedom and can act with a direct loop between desire and output; at the same time, none of the desires are suppressed in the final expression.
The final game would probably be chaotic and incoherent, but this is true to the process and the collective desire being captured. I deny that cohesion is a valid goal in artistic creation. All appearances of cohesion in art are false. Art is not cohesive because the world art reflects is not cohesive - a collective of young adults attempting to create something that presents as the product of a cohesive, conflict-free machine is a collective of liars. The immense effort that has gone into ‘User Experience’ has only served to make products more frictionless; the end stage of this ideal is an entirely frictionless exchange with the machine, an endless User Experience, where the experience of the user is defined by their engagement with an enormous technocapital complex carefully crafted to prevent itself from producing anything interesting.
Once the need to appear cohesive dissipates, JIRA is no longer necessary. The production process described above would allow every member of the team to work nigh-exclusively in forms they find personally desirable; within this paradigm, ‘motivation’ and ‘drive’ lose collective meaning. Members of the team who create more would be, correctly, overrepresented in the final product; at the same time, any individual save for the leads can slack off and delay their work without breaking any obligation to any other individual. The final product would be able to deny the aesthetic standards of the dominant elite and provide the consumer with a much greater variety of interesting content, without any individual on the team under obligation to self-discipline, self-denial, or “crunch”.