Agile is sort of an odd beast. It’s not a field, like UX. It’s not a framework, like SAFe. It’s more an umbrella term centered around a manifesto. The Agile Manifesto, though, is just that—a manifesto. It’s a set of values and principles. As such, it’s brief. What it doesn’t say is voluminous. What it does say is sometimes ambiguous.
Scrum is where large organizations typically turn to fill in the details. SAFe is where they typically turn to address the fact that they’re large. Agile’s legacy is difficult, to say the least. Its overarching narrative has devolved into a form of religious war, with Agilist Protestants acting like the manifesto was Luther’s Disputation of the Waterfall Catholic Church.
Despite two decades of hyperbole, there is a sense in which Waterfall isn’t going anywhere. There is still a natural stepwise progression to product work, and there likely always will be. As Norman argues in the newest edition of The Design of Everyday Things, large projects still benefit from decision gates, iteration still makes the most sense between them, and will likely always be front-loaded, diminishing as degrees of freedom are increasingly spent.
Thus, it might be time to admit the whole “Agile vs. Waterfall” thing is a red herring. It’s a distraction. After all, the reason most organizations want “Agile” in the first place is not to move away from Waterfall but to speed it up. It’s an efficiency gain, an attempt to “squeeze more water from the Waterfall”, as I recently heard Grigori Milov put it.
Unfortunately, this is often approached in an odd, cargo-cultish way, with organizations adding roles, rituals, and even complexity in attempt to “do Agile”. Such “transformations” inevitably follow Weinberg’s Pickle Principle: Organizations brine the Agile more than it Agiles their brine.
Now, becoming more efficient is important, to be sure. Also important is improving product strategy. This is where Agile continues to be rather inhospitable to the field of UX. To really understand why, we must get at the heart of what “Agile” is supposed to mean. “Agility”, after all, is more synonymous with “light-footedness” than “speed”. Agility is basically the ability to pivot. This raises a key question: Where should these pivots come from? How are we to know when to pivot and to what? This is where Agile and UX fundamentally disagree.
The ready comeback to such assertions is commonly that the disconnect is really with “Dark Scrum” or “Faux Agile”. I’m increasingly convinced this isn’t so. Few may agree what Agile is or what it means, but the one thing people seem to agree is that anything in line with the manifesto counts. Well, there is actually quite a bit in the manifesto that conflicts with UX.
For instance, the first principle of the Agile Manifesto states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” From a UX perspective, this is already suspect. Cutting through the vagueness, what exactly does it mean to satisfy the “customer” with “valuable software”?
Well, by “customer”, the Manifesto coauthors largely meant “business stakeholders”. “Value”, then, is whatever these stakeholders find to be of value. Agile’s answer to our key question above is then this: The purpose of agility, of pivoting, is to better enable stakeholders to discover what they deem valuable by giving them working chunks of what they request as quickly as possible.
As also stated in the Manifesto’s principles, developers should work daily with “the business” and then welcome the surfaced “changing requirements” as the stakeholders sample the “working software” provided. Agile’s value proposition lies in allowing said stakeholders to sample working bits of their upfront guesses and then, if so desired, to ask for something else (i.e., to pivot).
This avoids the trap of placing all eggs in one basket (or launch). Agile is about breaking large bets into smaller ones. Sounds good, right? So…where is the disconnect? Well, from a UX perspective, this treatment of “value” is circular. It’s a snake eating its tail. Filling stakeholder solution requests—even in an Agile way—does not break this recursive loop.
This take leaves design and its core function out of the picture. It sidelines the role of discovery and treats teams like they are running drive-thru windows. It overlooks the actual end-users, their goals and frustrations and, in so doing, ironically ignores what creates business value, which—spoiler alert—isn’t software.
The only way to increase value is to change someone’s behavior. Whomever that “someone” is, whether user, customer, employee, or constituent (it really doesn’t matter), there is no value created without the behaviors that create and sustain it. These desired behavior changes can and should be encapsulated in the form of target outcomes, with the “user” being the people whose behavior these outcomes ultimately hinge on.
To UX then, the only form of agility that matters is the ability to alter the behavioral outcome being produced, and this does not tend to hinge on what stakeholders happen to request. It hinges on the ultimate experience provided, on the team’s understanding of the user context, on surfacing deeper issues and meeting underlying needs.
Should teams then really focus on building software…or on meeting needs and solving problems? These are not the same thing. Software is but one way to do this. From a UX perspective, rethinking an employee’s day, redesigning a workflow, or pushing for policy changes nixing the need for some tedium are just as viable approaches as coding the next feature.
In this way, UX asks we be more consultative than Agile seems to think teams should be. It’s less about coding the next slice of cake and more about exploring the overall problem frame, zooming out, and poking at it. If a patient asks his liver be removed, this isn’t “added to the backlog”. Instead, prescription without diagnosis or discovery is to be considered malpractice.
Breaking large bets into smaller ones is well and good, but UX is more about making smarter bets; and, at its core, takes umbrage with the notion that stakeholder requests are the best signal of unmet needs (or even a good one). All too often, what people know how to ask for is not predictive of future behavior, whether these requests come from stakeholders or actual end-users.
Stakeholders are not only NOT good empirical arbiters of value, but, as Norman cautions, what they present as “the problem” is seldom even the issue the team should address. Pivots should not be driven by changes in requirements capturing requests. They should be driven by discovery, which should not be shortchanged for efficiency gains in placing poor bets faster.
Trying to speed up the Waterfall by skipping its most important parts is not a smart move. Analogies to “unclogging the pipes first” are misplaced and unhelpful. Product work is nothing like a factory. The real barrier to value is the decisions made at the top, not the ability of teams to deliver more pizzas faster. Basing performance reviews on false and outdated analogies does not prove the opposite; it just incentivizes the wrong behaviors.
This is a big disconnect but does not mean Agile and UX cannot get along. In fact, AGILE NEEDS UX. It needs something to fill the product strategy gap it left in its wake, and not because it failed at product strategy so much as it assumed it didn’t need to have one in the first place. Agile passed the buck.
To close, in most “Agile” organizations, especially in the massive ones where Agile has been “scaled”, in addition to the lower usability function UX can and should play alongside Agile teams, it must also be brought further upstream. This is where the strategic decisions are made, and it’s these decisions that are the real medium of design.
Charles Lambdin 