How do you integrate UX with Agile? This question comes up all the time, and I'll be working through it in future posts. First, though, let's have some fun and deal with a problem that makes the entire question beside the point. That problem is bullshit Agile, or, as I've hereby named it, Bullshit Bad Agile, or bAgile (copyright 2016 me). No amount of UX “integration” will improve your products if you are practicing bAgile. So let's start hashing this out.
From the Agile Manifesto site:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
“Everybody check it out! With Agile we just start coding and figure out the requirements later!”
The desired result is quick, adaptive iteration, responsive to the real-world needs of the customer. The actual result? Practitioners of bAgile will read the above statement and ignore other Agile principles that require work and discipline. Product owners, other stakeholders, and developers proceed to take it as permission to make the requirements up as they go along. The business analyst is reduced to a typist who writes down what was decided in this morning's standup. The actual result is constantly growing scope and constant rework, which is not the same as frequent iterations. Timelines are pushed out. Shared resources, like designers, database admins, and business analysts, are constantly holding off other projects because this one won't stop growing and morphing.
With bAgile, you go from minimal viable product to maximal possible product in no time flat. There are no brakes: Every what-if, how-about, and wouldn't-it-be-nice-if brings more complexity, more features. Nobody has an incentive to say, “No, stop. We don't need that.”
Think of it this way: What sane, reasonable adult ever proposed drawing the blueprints for your house and building it at the same time? Picture the developer, standing there on the concrete floors, surrounded by framing, saying, “Hey, I want to add a toilet here in the kitchen, in case the buyer feels they might need to go while they're cooking. It could happen, right?#&8221; Or, can you picture auto designers drafting, designing, clay-modeling and wind-tunnel testing models at the same time engineers are building the actual car? “Hey, we just decided this sedan is also going to be a pickup, and we want all four wheels to turn independently.” Of course it's insane. Yet, that's what is happening all over the place in IT.
How does this happen?
If you're building a house, you have an incentive to put the brakes on because the longer it takes and the more you add to it, the more money you pay. (Except if you're a drug kingpin and money is no object. Tony Montana would not have a problem with bAgile.) Doesn't the same apply in IT?
Add more features! It's totally Agile.
Often, no. Inside the corporate cocoon, the incentives are turned upside down. If you have a stake in an application, Web site, or software product, you're worried about leaving something out that you hadn't thought about. Nobody is held accountable for adding too much, which is why we're surrounded by bloat. In the corporate bubble, time and resources are just funny money to most participants in the process, so people start imagining horror scenarios wherein the CEO asks why there's no button to do that one thing in that one scenario that one developer thought of one time. It's CYA time: Add everything anyone wants, at all times.
There is plenty of irony to this. The admirable idea, to bypass red tape and launch tight, lean tools quickly and with a minimum of fuss, leads to an undisciplined free-for-all where everyone throws features into the product and nobody is accountable for timelines, which is the problem Agile (and also every other methodology) was intended to solve in the first place.
How do you know you've got bAgile?
There are a couple of lines of bullshit that alert me that what we're looking at is bAgile. These should be red flags for you as well:
Bullshit Red flag line #1:
Requirements won't ever be complete anyway.
This is said as one scenario after the other turns out to have been missed, and people keep coming up with more and more features that are supposedly totally necessary. How did you miss these requirements, causing us to redesign and rework over and over? Why, because requirements will never be complete, of course!
What really happened is everyone got lazy. The requirements on which everyone estimated work were really just a small collection of the obvious: “As a user, I want to search widgets. As a user, I want to sort my search results. As a user, I want to select a widget. As a user, I want to edit/add/delete a widget.” None of the work of thinking through alternate and exception scenarios was done. None of the demanding work of determining exactly who this is for, how they'll use it, and when. You know, the stuff you need to know to make good software as opposed to throwing merde at the wall.
The primary reason this is bullshit a red flag, however: Rarely if ever were any of these changes in requirements caused by actually working with customers and end users. If you define the business as your customer, then, yes, having the product manager tell you “I want a button that turns all text upside down” counts as collaboration with customers. What you should be doing, however, is working with the real end users and/or purchaser of the product. For example, by testing with actual users. That is what should be driving changes, not the project team guessing their way through an endless series of what-ifs.
Bullshit Red flag line #2:
“That's just how Agile works!
I'll wager a bet with you: Whatever “that” refers to is not at all how Agile works. More likely, it's meant to deflect blame when it turns out that the project is churning, getting more bloated by the day, and your developers and designers are groaning under the strain of constantly redesigning and recoding.
Agile is loosely enough defined that you can call just about anything “Agile” and say that's just how it works. I used the Agile process to fix myself a bowl of cereal this morning. Rather, I can say I did, and I could probably find something in the Agile manifesto to support it. That doesn't make it Agile, and it certainly doesn't mean it benefits your business. You've got as much scope creep as you ever did, only now it's sanctified because we called it Agile.
All aboard the bAgile Bus!
Don't let bAgile happen to you
Say your company were building a plant. You've got some basic needs on paper, but you agree with the builder to go Agile. Every day, the plant manager and project coordinator are down there on the construction site, working with the builders to decide where the walls and plumbing go, what machinery you need. They're wiring and rewiring the electrical. Putting up and tearing down walls. Laying floor and taking it back up. New additions are identified and added every month. What if 20,000 people showed up at once and we needed bathrooms and kitchen facilities for all of them? Add that. Air strip? Blimp hangar? Flux capacitor? Cooling towers for the flux capacitor? Force shields in case of alien attack? Self-destruct mechanism? Self-destruct cancellation mechanism? We might need them all! A year later, you're not even close to completion. But, hey, it's Agile!
Of course not. Heads would roll, because that's bAgile, not Agile. Don't do bAgile, and don't misuse UX resources by asking them to participate in bAgile.
