Reframing Agile

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.

Share

About Jeff Nyman

Anything I put here is an approximation of the truth. You’re getting a particular view of myself … and it’s the view I’m choosing to present to you. If you’ve never met me before in person, please realize I’m not the same in person as I am in writing. That’s because I can only put part of myself down into words.

If you have met me before in person then I’d ask you to consider that the view you’ve formed that way and the view you come to by reading what I say here may, in fact, both be true. I’d advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.

This entry was posted in Testing. Bookmark the permalink.

2 Responses to Reframing Agile

  1. Thank you so much for this amazing, thoughtful post!

    If you were to ask me to play the perfection game (see Core Protocols), I’d rate this performance at a 7 out of 10.

    What made it a 7:

    Clean
    Concise
    You told the truth about what an Agile mindset really entails
    You showed us a way to break out of the “us vs them” mentality in the false “Agile vs Waterfall” war
    The 2 main points were quite memorable, pithy, and thorough.

    What I would add to make it a 10:

    The formulation of the two points might cause folks to latch onto “make better decisions sooner” as an excuse for saying bad decisions are.. well.. bad. 🙂 This could, potentially, lead a culture to a local maximum, because they would continually drive towards what they already know, relying on existing habits, instead of breaking out of those patterns periodically and taking risks that could lead to game changing discoveries.

    So, I’d add two more points to help people understand that “better” could mean “worse,” or even “off-the-wall.”

    Instill a culture of “no mistake.”
    Integrate wisdom from unexpected places.

    One might argue that these points could simply be contained within “better decisions sooner.” In a sense, pretty much everything in the world could be. However, the issue with containing basically the whole universe of conceptualization is that it becomes difficult for people to hold the whole meaning in their minds. And so, for some it could become yet another weapon in their toolkit to be used against others who are not making, from their point of view, “better decisions.” For others it could be a way out, a defense that they were trying to make a decision “sooner.”

    And so, a culture of “no mistake” acknowledges that very often we can’t actually know what the better decision is (we are talking about complex human systems here), and so we simply need to try something, and fail. On the flip side, we need to mine our failures for new wisdom, escaping our pre-existing biases.

    In a sense, the four items together seem quite balanced (from a Taoist perspective):

    Earth / Practicality

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

    Heaven / Virtue

    Instill a culture of “no mistake.”
    Integrate wisdom from unexpected places.

    Hope this is helpful! 🙂

    • Jeff Nyman says:

      Very helpful and a great comment!

      Some of what you describe I have talked about in terms of “fail-fast” and “safe-to-fail” environments (http://testerstories.com/2017/05/testing-as-experiments-around-project-forces/). So, far from a culture of “no mistake” I prefer a culture that embraces mistakes.

      What I try to do is show how you want the cost of mistake curve to be as short as possible. Meaning, it’s not a matter of how many mistakes you make, it’s how much time there is between when the mistake is created and when it is found. If you can tighten that feedback loop, you are in effect allowing people to make better decisions sooner — but without necessarily precluding making mistakes.

      Mistakes are powerful drivers of our own adaptability in the face of uncertainty.

      Regarding integrating wisdom from unexpected sources, this is a nice way to describe what I’ve talked about as being cross-discipline associative. (http://testerstories.com/2013/06/testers-should-be-cross-discipline-associative/). I’ve tried to do the “Testing is Like…” concept (http://testerstories.com/2016/10/testing-is-like/), drawing in inspiration from different sources, like history, cartography, archaeology, and so on.

      This is an area I’m still exploring and I greatly appreciate your comment as it shows I have further exploring to do to really hone in on these ideas.

Leave a Reply

Your email address will not be published. Required fields are marked *