Lots of people seem to focus on whether agile has failed. Or whether it’s dead. Or whether it’s a methodology. Or a process. What you end up with is something akin to Edmund Burke’s denunciation of political factionalism: “tessellated pavement without cement.” In the testing world this is even more so the case given the oft-used phrase “agile tester”, which any test specialist should be against. So let’s talk about this.

Agile is a Mindset

Agile, to me, is a mindset. The two ideas that guide my work in any sort of agile environment are simply these:

• Get little things done often.
• Allow people to make better decisions sooner.

These statements are, what I think, most important regarding any mindset in an agile context, however your company happens to define and/or practice agile. I could end the post right here regarding my thoughts on this. But bear with me as I go a little further.

Agile Is Moving Fast?

Some people equate “agile” with moving nimbly, adaptive to change, and so on. But let’s face it: business really tends to reduce this as being “the ability to move fast.” Whether that’s accurate or not from your perspective, let’s just go with it for a second.

• Moving fast in the short term is not possible unless the shared understanding of quality is under control at all times. So what this means is that a testing strategy is needed that says testing is a design activity and automation is a core part of the strategy.

• Moving fast in the long term is not possible unless the quality of the design and of the understanding of the business domain is under control at all times. So what this means is that an executable source of truth strategy is needed so that it’s possible to reason about the system at all times.

Again, I could end the post here. But I’ll plod on a bit further.

(Re)Frame the Problem

We have to reframe because the terminology can be confusing. We get “agile”, we get “lean”, we get “scrappy.”

Sometimes we even get a little more obtuse and say we’re “shifting left” or we’re “adopting a DevOps culture.” But I’m going to argue that what we really want is simply to make better decisions sooner.

So a large part of the question is: how do we do that? I think a large part of this is simply recognizing that we want to sustain development and testing so that better value is delivered and deployed on a consistent basis. Alright, so how have we done that in our brave new worlds?

The Continuous Continuum

Well, we’ve put an emphasis on ”begin continuous”. And then we create a continuum of this.

We often call this ”being agile.” We talk about continuous integration, continuous delivery, and continuous deployment. Yet we sort of have a waterfall.

Now, hold on! Don’t crucify me just yet. Yes, I realize anything can be drawn out in a sequence and be made to look like a waterfall approach. But I think it’s true, given all the focus on “is agile dead”, that it has started to feel like we’re really just doing the same things we’ve always done … but a little faster and with different technology.

Consider the challenges

So now let’s consider a few of the challenges the tech industry has been facing.

• The pace of innovation

• The shifting tides of culture
  • … attention span
  • … usage across digital channels
  • … brand engagement / loyalty

• Technology …
  • … proliferation
  • … variability
  • … sensitivity

These require an emphasis on continuous discovery and continuous exploration. Those are two aspects of “continuous” that you don’t often see employed. And that get’s people nervous because it looks sort of like this:

It looks like a thing you can’t control. And, even in agile contexts, that worries people.

The False Dichotomy

So what we end up with is Waterfall and Agile often put in opposition to each other.

This is often based on the mistaken assumption that we’re talking about removing controls to our process versus adding them. Yet all methodologies or processes or approaches are attempts to gain some level of control, usually by an attempt to manage complexity and uncertainty. In this Agile is no different than Waterfall. When we don’t recognize that, we place our approaches in extremes.

And then, those extremes being established, we count on this nebulous thing called “culture” to bridge the divide. We say we’re “being Agile” or that we’re an “Agile shop”. And that’s a key thing to understand about succeeding with “Agile” approach … it’s a behavioral and conceptual shift; which eventually leads to culture shift. The problem is starting with the culture and assuming the concepts and the behavior will follow.

Beware Levels of Control

Here’s what I would argue. The problem is not so much control. The problem is when the level of control requires multiple sources of truth, when more and more artifacts need to be created, when traceability has to be artificially woven between with those artifacts, when testing is treated only as an execution activity and not as a design activity. This means Quality Assurance is treated solely as a team rather than a distributed function among teams.

Beware Intransparency

A key challenge of being continuous is being incremental with minimum viable products and the reduction of intransparency. Intransparency is forever the enemy of quality. We’ve all seen this in the horse image.

There is a lot of intransparency between what we started from and what we ended up with. And we don’t want to “over-specify” — because that would be too much like waterfall, right? So we leave in room for interpretation. Which actually leads to further intransparency. And since we’re now moving faster, that can actually magnify the problem while at the same time masking the problem.

So we try to solve this by reducing scope. We do “the smallest possible thing.” The problem is often that the user gets something they can’t use until the last release when they get something they finally can. Even if you are talking about very small increments, this can still hold true.

That means you can’t just scale delivery because you are being “continuous.“ There’s more to it than that. What you have to do is incrementally add value in a way that understands how humans will use or consume what you are providing them.

Notice that, along the way, you may have been discovering new users who would be satisfied with a very different type of experience.

What Are We Truly Scaling?

But to do this in any sort of realistic way — and this is probably the most important point to me — you have to scale communication and collaboration, which are the drivers of discovery and exploration. And discovery and exploration are the drivers of quality.

You reduce sources of truth; you utilize human conversation and collaboration. And only encode a source of truth when it can serve as a test artifact: both for humans and for machines. This means tests are not just there to detect changes in behavior. Instead tests are to specify and elaborate on the behavior. And they are backed up by automation that serves as a form of executable specification.

If there is any sort of definition of “agile testing” then what I just said is it, at least for me, particularly when I treat agile as a mindset.

Agility in Testing; Not “Agile Tester”

The main challenge in managing scope is not to eliminate uncertainty by defining and locking down requirements as early as possible or even to reducing those requirements to smaller and smaller iterations. The main challenge is to manage this uncertainty in a way that will help you progressively discover and deliver an effective solution that matches up with the underlying business goals behind a project.

But how? I’ve said it before. You treat testing as a design activity; an activity that creates a shared understanding of what quality means. Your culture adapts to use conversations around concrete examples of behavior to understand how features will provide value to the business. And then you encode that understanding so that elaborated requirements and tests become the same thing.

If there is the concept of an “agile tester,” that would be it. But I would also argue you can do that in non-agile contexts as well. Which is why I don’t like the term “agile tester.” It can mean anything or nothing, just like the term “agile.”

Back Where I Started

So I started off with this:

• Get little things done often.
• Allow people to make better decisions sooner.

That mindset can then be utilized in various approaches. And I think that’s important because neither of these mindset statements necessarily require “agile”, per se. For example, the same approach could be achieved with “lean” or even the newer “scrappy.” And, yes, even in waterfall variations. An important point, however, is that “being agile” does not in any way guarantee that you or your team will have this mindset or act on it, even if you do have that mindset.

That, to me, gets to the heart of why we keep having discussions about whether “agile sucks” or “agile is harmful” or “agile is dead.” Lots of people are talking about different things but using the same term to describe them all. Thus we get descriptive parallax. And many of those same people are entirely conflating the mindset with the idea of a process or a methodology.