(2020-02-08) Taylor Agile As Trauma

Dorian Taylor: Agile as Trauma. The Agile Manifesto is an immune response on the part of programmers to bad management. The document is an expression of trauma, and its intellectual descendants continue to carry this baggage

While the Agile era has brought about remarkable advancements in project management techniques and development tools, it remains a tactical, technical, and ultimately reactionary movement

In order to begin to heal, it is important to place Agile in a wider context. Many of the substantive ideas associated with Agile predate it by between about 20 and 30 years

you are bound to recapitulate these patterns eventually

• Incremental development
• Iterative development
• Cross-functional teams
• Fixed time, variable scope
• User involvement

To the extent that trauma is by definition something you don't get over, and only eventually come to understand, I submit that the Agile-o-sphere continually relitigates these issues at the expense of solving other, potentially more fruitful problems.

What We Hear Suspiciously Much About

Collaboration! So much effort goes into writing and talking about collaboration, and creating tools to facilitate collaboration and telecollaboration, with the tacit assumption that more collaboration is always better.

To quote Fred Brooks, the more collaboration the better is far from a self-evident proposition and certainly not universally true.

what you actually want is as little collaboration as you can get away with.

One way all this lavish attention to collaboration makes sense, is that your team dynamic is something you can always affect, even if you have no meaningful influence over the major strategic decisions of an organization.

What We Don't Hear A Lot About

Anything higher up the chain than project management... This is important, because failures to implement Agile principles are often easily diagnosed as side effects of the constraints of antiquated procurement and contracting practices. (see Agile Contract)

A specificity gradient

Software is unprecedented in its low cost of development—when compared to hardware. Code, however, is arguably the most expensive medium for expressing ideas

software isn't like a car at all: if anything it's more like a university campus, where different buildings are complete artifacts in their own right but loosely couple together to form a unified service. It is perfectly reasonable for some parts to be undergoing construction while others are being planned

Conceptual friggin' integrity

The one idea from the 1970s most conspicuously absent from Agile discourse is conceptual integrity. This—another contribution from Brooks—is roughly the state of having a unified mental model of both the project and the user. (alignment)

Without conceptual integrity, Brooks said, there will be as many mental models as there are people on the team. This state of affairs requires somebody to have the final say on strategic decisions.

furthermore requires this person to have diverse enough expertise to mentally circumscribe—and thus have a vision for—the entire project in every way that was important, even if not precisely down to the last line of code.

Agile vs. Waterfall is Kayfabe

comparatively few have actually read the 1970 Waterfall paper. If they had, they would learn that what they had experienced—or more likely, heard about—was what the paper's author asserted was the wrong way to manage a software project.

There is the story that so-called big design up front—another Agile shibboleth—was more of a necessity in the past because: available computing resources were a minuscule fraction of what they are today, and thus required more planning...

There is furthermore the argument that the product in question must get to market as quickly as possible to secure the first-mover advantage, or perhaps in its gentler form, the idea has to be tested in the market right away to make sure it's something people want. None of these statements are false, but they aren't the whole truth either.

In particular, not all software is a Web app. Indeed, a sizable fraction of software is not a consumer product, or not even a product at all. We discount the volume of, for instance, embedded systems and one-off infrastructure.

The story that things were slow and now they're fast—technology and market forces alike—is not sufficient to explain the pervasive adoption of what has come to be called Waterfall. The story is especially ill-fitting considering preeminent figures in software development had been advocating incremental and iterative development with feedback from users, up to and including the original 1970 Waterfall paper itself. ((2003-06-30) Iterative and Incremental Development: A Brief History)

I want you to consider instead the possibility that Waterfall came to exist, and continues to exist, for the convenience of managers: people whose methods are inherited from military and civil engineering, and who, more than anything else, need you to promise them something specific, and then deliver exactly what you promised them, when you promised you'd deliver it. There exists many a corner office whose occupant, if forced to choose, will take an absence of surprises over a substantive outcome. (management, dark agile)

My final remark on this subject is that the rhetorical framing around design as something inherently belonging to Waterfall, and thus bad and an impediment to shipping product. This is little more than a goad, perpetrated not so much by professional managers, but anxious startup founders worried about their money running out before they start earning any.

Software development, again, is about answering thousands of questions. Some of those questions can only be answered with code; others can never be. There is nothing preventing these operations from being carried out in parallel, except when one genuinely depends on the completion of the other. ((2011-04-20) Lean Agile Production Vs Theory Building)

Goodhart's Curse (see Goodhart's Law)

Features work as a management control (metric) because they manifest in the final product, and their relationship to programmer-hours is about as close to linear as you're going to get.

Features also work for marketing. Since nobody can deny a feature exists, a convenient tactic is just to count them

Features don't work, in the sense that they can be easily gamed.

This also makes features a spurious basis for comparison in competing products because you need to seriously examine them to determine the extent to which they are any good.

We use the term feature factory as a pejorative to designate companies addicted to adding features, while accumulating incalculable so-called technical debt.

I suspect Agile processes are constitutionally vulnerable to this kind of compromise.

There is, however, another objectively countable phenomenon associated with software development, and that is behaviour. The question does the product do X, optionally under condition Y?

Programmers should be familiar with this pattern; it is exactly how test suites are written.

Behaviour has an advantage over features in that you can describe any feature in terms of behaviour, but you can't describe behaviour in terms of features.

the presence of a feature can only indicate to a user if a goal is possible, behaviour will determine how painful it will be to achieve it. (bad-ass)

The final advantage of behaviour that I will discuss here is the fact that it blurs the line between fixing bugs and building features, and coalesces the two into a unitary process of sculpting behaviour.

The feature count may not go up as quickly, but the product's behaviour will increase steadily in subtlety and fit

When is a Sprint Really a Marathon?

Like any other creative endeavour, software development can't be sped up as much as we can eliminate the phenomena that slow it down

Even in a world after programmers, there will still be the work of figuring out—albeit no longer in code—just what you want to tell the computer to do for you—how you want it to behave.

If you eliminate the decisions that involve getting the artifact to work at all, the remaining decisions are going to involve whether it works better one way than another. Most of these decisions are going to be the result of trial and error, and a sizable chunk of those are going to involve feedback from users.

A development paradigm that can be construed from the outside as setting great store by speed—or, I suppose, velocity—is invariably going to be under continuous political and economic pressure to accelerate. It isn't clear from the literature that this was anticipated by the Manifesto's signatories. If instead you asserted that the work amounts to continuous discovery, it happens at one speed, and could potentially continue indefinitely, you might be able to pace yourself.