Agile as Trauma
The Agile Manifesto is an immune response on the part of programmers to bad management.
Many of the substantive ideas associated with Agile predate it by between about 20 and 30 years.
The patterns include, but are not necessarily limited to:
Incremental development
Iterative development
Cross-functional teams
Fixed time, variable scope
User involvement
Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with.
failures to implement Agile principles are often easily diagnosed as side effects of the constraints of antiquated procurement and contracting practices. 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.
This!
Our notions of iteration and incrementality therefore have to also make room for media other than code.
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, shared among all members of the team. Conceptual integrity makes the product both easier to develop and easier to use, because this integrity is communicated to both the development team and the user, through the product.
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. It 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.
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.
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.
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.
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? is also an empirical question with a yes-or-no answer.
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.
Posted on February 18, 2020