I was going to title this “The Irrelevance of Agile” but that struck me as an unfair title and not entirely indicative of what I wanted to focus on. Testers will periodically be involved in the “Is Agile Dead?” debate. Or even the “Agile is (Once Again) Dead” debate.
I’ve found these discussions to be an emotive area to wade into so I want to approach this from a different angle. This is me experimenting with thoughts rather than claiming to have any answers, so expect a bit of this to be somewhat muddy as I feel my way forward.
Agile, like most other things that provide a “manifesto,” fell victim to its own practitioners. When I say it “fell victim” here I don’t necessarily fully endorse the idea that it is “dead.” Keep in mind, the “post-agile” movement was going strong even back around 2007. So if agile has died, it was a very prolonged death.
Project Legibility
There is a distinct aspect to any discipline that suggests you can make something “legible.” This is what agile tried to do for projects, just as waterfall did.
What this notion of “legibility” means is that you make the projects measurable and hence manipulable. This is how we attempt to impose and maintain authority, and thus control, over something. So we preserve the past by making it legible and retrievable and we presume to do this for the present, which then lays out a roadmap for the future.
This search for legibility is, in many ways, an imposition of general uniformity. And that tends to diminish local diversity. Anything universally applied tends to submerge localized knowledge of how things actually work.
Granted, “agile practitioners” tend to suggest that this not what “true Agile” (with a capital A) does. Rather, the idea is that agile practices do, in fact, encourage local diversity on projects. The problem is that so did waterfall projects.
This to me is why the notion of “waterfall vs agile” was never really the true discriminant factor in whether projects succeed or fail. The imposition of any sort of methodology risks the imposition of uniformity. All of these things we do are in the interests of making aspects of our work “legible.”
Harness the Past
Just about everything discoverable for us in the past. That’s the case on any project, regardless of what method or approach you use. The future is coming into being but it is doing so on the back of the past. And that past keeps growing and growing. So, yes, everything discoverable for us in the past. The ephemeral moment of “now” is when everything is actionable for us. Here “now” is a duration that comes into being and persists for a project.
Notice that wording: “now” persists for a project. Incidentally, I highly recommend everyone read the recent book Now: The Physics of Time. It has nothing to do with our projects in the software world but everything to do with time. And time has everything to do with our projects.
Anyway, when we “map the past”, what we do is lay down a grid that can stifle particularity and privilege legibility. But it’s all done in service to the idea that we want to make the past accessible to the present and allow that to inform us about the future.
Again, waterfall and agile were both doing the same things, ultimately. Certainly they had very different localized approaches but the reason you had a post-agilist movement and a continued focus on “agile is dead” is because agile, like most such things, started being treated as a religion that mapped the grid lines of a culture. And the last people to see this were often those most steeped in the religion.
Reconstruct the Past
Beyond this, the past is reconstructed — that is to say, made legible in some particular way — with a view to constraining a certain amount of freedom in the future.
Agilists will act like this is not the case, but it in fact is. The search for a past with which to attempt to control a future is inseparable from human nature: it’s what we mean when we say we learn from experience.
Doing so, by definition, means that we want to make the future more predictable by learning what not to do. This belief becomes dangerous, just as historians have shown us, when a reconstructed past produces the belief, in the present, that the future, in order to be better accommodate the lessons learned, requires reconstructed people.
Ultimately both waterfall and agile were looking at reconstructed people.
Culture Amidst Technology
Agile and waterfall both dealt with culture and usually operating in the context of technology.
Culture — that is, people and processes acting in concert — is integral and critical to the success of any new technology deployment or implementation. That fact has been demonstrated repeatedly over the past many decades of technology evolution. We’ve had “technology revolutions” that have radically transformed our social, commercial, political, and entertainment worlds. Each of those revolutions was followed by a period of intense cultural adjustment as individuals and organizations struggled to capitalize on the many benefits created by the newer technologies.
As the collective story the group tells itself, culture drives the thinking that drives behavior.
Waterfall nor agile necessarily promoted any culture. “Being agile” is not a cultural statement.
Culture is a convenient way of thinking about patterns of behavior in an organization that aren’t hardwired by policies, procedures, or structure. Popularly, it has become a black box used to explain, in the absence of anything else, the failure of an organization to implement its strategy.
A better way of thinking about culture would be to see it as the mindset of the organization. Because our mind-set is structured as a story, culture can be thought of as the collective story the members of an organization tell themselves, driving the way they perceive the world and act as a result.
The Biography of Projects
One of the core challenges that writers of biographies face is the notion of character. And the reason this is tricky is because it can be so subjective, not least of which how someone chooses to define “character.”
You can’t go far wrong by looking at character as a relatively persistent set of patterns within an individual’s behavior. “Persistent” here means over the course of their life. Character is often what we see with people who deal with similar circumstances relatively consistently as well as dealing with dissimilar circumstances in ways that while perhaps situationally not similar are still reflective of the core consistency of how that person acts.
I would maintain that the same thing happens with projects. And not just because projects are populated by people; I believe those projects take on a certain “character” of their own. This is something neither agile nor waterfall necessarily put any emphasis on.
But the lives of people, just like the contexts of projects, are full of patterns. Which are the particular ones that constitute character? Well, John Gaddis has said that
“Biography, like life, is a matter of expanding horizons and then usually, as old age sets in, contracting them once again. And biographers tend to regard as character those elements of personality that remain constant, or nearly so, throughout.”
This actually has an interesting correlation with humans starting from our infancy. As Gaddis says, in an extended metaphor:
“[A newborn infant] is, in one sense, totally oppressed, as a result of having come into the world totally dependent. But it’s also totally liberated, in the sense of having no preconceptions, no inhibitions, no concern for anyone other than itself. We start life, thus, at the extremes, and we gradually narrow the gap between them. As we grow physically we’re better able to take care of ourselves, so that we gradually become more independent. As that happens, though, we’re increasingly enmeshed within a web of experience, lessons, obligations, and responsibilities. By the time we’ve become adults, most of us have learned at least to balance these tensions, if not to resolve them.”
Culture and Self-Similarity
But what does this mean? I do believe that, in a very real sense, the notion of character starts very early with us. It is shaped; it is honed; it has setbacks. But ultimately it forms the structure of who we are. And I do believe the same is true for projects. But, again, neither agile nor waterfall necessarily put any emphasis on this.
But this persistent pattern idea of human character and, I believe, project character has resonance from a particular idea from chaos, complexity and game theory. That idea is self-similarity across scale.
The scale, in this instance, is the widening and then narrowing sphere of a person’s life. It’s the widening and then narrowing sphere of the activities of a project. Going with Gaddis again regarding what biographers do:
“Like practitioners of fractal geometry, biographers seek patterns that persist as one moves from micro- to macro-levels of analysis, and back again.”
The micro and the macro brings up what I believe is a very important quality of our projects and, thus, a quality of people who work on them: the ability to move between polarities.
Movement Between Polarities
Ultimately whether you are agile or waterfall does not matter. That’s why, to me, it doesn’t matter if “agile is dead” any more than it does if “waterfall is dead.”
Any project has to begin with the idea that you are ultimately dealing with self-reflective, feedback-generating, information-exchanging constructs. Otherwise known as human beings. As such constructs, we have the ability, and almost the innate tendency, to react to similar circumstances in very dissimilar ways. In the words of Nassim Nicholas Taleb in his book Antifragile, this means we have the ability to “do things without understanding them — and do them well.”
This means we can move between polarities. The “agile manifesto” may seem like it’s dealing with just this kind of thing but I would argue it’s certainly not. (Does this mean the agile manifesto is dead, too?)
As a tester, agile was never a concern for me in terms of being “alive” or “dead.” It was worse: it was largely irrelevant to day-to-day activities. And that’s because it was still focused on the aspects of our projects rather than a focus on the ideas of humans that can move between polarities. In many ways, agile promoted the notion of the technocrat tester even though that clearly was not the intention.
Agile, like waterfall, has kept us prisoners of our paradigms (to use an over-used term). Agile just provided a different prison than waterfall did. Agile, like waterfall, provided contexts whereby we gave more credence to information that confirmed pre-existing views while also reducing much information that was dissonant with those views. Because the paradigms responsible for our thinking are self-reinforcing, and because we are self-reflective beings, the only way we can move beyond those paradigms is to experience the kind of dissonance that invalidates it. Agile, like waterfall, did nothing for this.
But what is this? If you have read many of my thoughts on testing, you know that I believe it is the crux of all our projects because everyone does testing, to some degree. This is what allows quality assurance to be a distributed function rather than a team. As my thinking has matured on this, I have come to the realization that what we need is an understanding of the polarities we need to move between and some of the viable techniques for doing so.
I’m not sure how much of this made sense; my thoughts are still very in flux on this. I’ll definitely be talking more about these polarities in future posts.
