The Ideology of Agile ("A.K.A., you kids get off my lawn")
then and now
As somebody who graduated from high school at the turn of the millennium, there’s a very clear distinction between “then” and “now”. It’s so jarring, in fact, that sometimes I forget about it until I’m reminiscing with an old friend, and we suddenly realize some key element of the story like :
- nobody had cell phones
- nobody had social networking
- when people moved away, they were just GONE, usually forever
- we wrote a lot of things with our hands
… or something similar. Then we laugh about how old we’ve gotten, and move on.
What I’m talking about, though, is bigger than just old stories from old friends. There’s actually a pretty clear distinction between “then” and “now”, if you consider “now” to be a world where almost everyone is effectively online at all times, and “then” to be the prior world, where almost no one was ever online at all.
To my parents, this is easy to forget — the internet is just one of a long list of wild changes to life they’ve experienced over more than half a century, and it’s trivial to lose sight of social networking when you realize that your mortgage from the 1980’s had an incomprehensible interest rate of like, 25% or something.
Still, a lot of the changes people that age may lump in with internet culture weren’t really as transformative as they feel — they were evolutionary, instead of revolutionary. At a high level, for instance, the music industry in the 1990s was just a bigger, louder, more international version of the one from the 1960s. That’s true with grocery stores, banks, doctor’s offices, publishing… the list goes on and on. By the time I was in high school, things were certainly different for my parents than they had been growing up, but other than a reduced threat of total annihilation, the main difference was that they were just BIGGER.
the difference is…
So what’s this other difference? The kind that makes industries from the 1990s look — by comparison — as quaint as ones from the 50s and 60s? Is it connectedness? Narcissism? Sheer volume of information? Democratization and the elimination of traditional gatekeepers?
All of these are real things we’re dealing with, but I don’t really think any one of them permeates everything. Here’s what does.
Just about everything is faster these days, for better or worse. I don’t really think I need to talk about the “better” part of that, because we all experience it every day — faster payments, faster deliveries, faster entertainment, faster development of alternatives, faster communication. All of these things are generally just better, and most of us would be horrified if we had to actually return to a world where not being able to find the friend you were supposed to meet at the restaurant meant you just had to go home and call it a night, or sit at the bar and talk to strangers. For all of our time spent running into parking meters while we read inane Facebook statuses, there’s still a remarkable amount of inefficiency cut out of modern life, and even fairly determined luddites are getting used to it. Hooray.
I also don’t feel like I have to address the really obvious downsides of speed, which anyone older than me seems to constantly be bitching about. “Too many things are happening!”
Well, technically, roughly the same number of things are happening as before — it’s just increasingly difficult to remain unaware of them, which can be disturbing. It’s admittedly fatiguing, distracting, et. al. We get it.
No, the particular bad part of speed I’m talking about is the increasing demand for immediate return on anything and everything we do. There are a couple big factors I can think of that contribute to this, but here are a few :
- data — we have tons of data, and we’re starting to think we can prove or disprove anything, from whether people think we’re funny to whether something is worth investing millions of dollars in
- distraction – there are so many ideas available to us now that it’s easy to always be drawn towards the next shiny object you find, and just as importantly, away from the details of the last one
- visibility — we share everything, so our work is constantly being assessed; we don’t feel like we can afford to be wrong, and we assume that everyone is aware of what we’re doing
I don’t know if any of these things matter more than each other, but they’re all relevant, and together they create a perfect storm of (a) impatience, and (b) the ability to change course in response to that impatience.
two poles and a brutally mixed metaphor
To be honest, I don’t think this kind of thinking is actually caused by the internet. I think it’s really a reaction to literally decades of slow-moving, leviathan-type projects, and that this reaction is simply enabled by the internet.
Let me put it this way. As a non-developer who has spent his entire life living and working with developers, I have just enough knowledge about development methodologies to be dangerous. And in a nutshell, there’s two major poles on this philosophical spectrum.
(Come to think of it, I don’t think spectrums have poles. Sorry, Dad.)
On one end is waterfall development. The very basic premise behind waterfall (if this kind of thing is new to you) represents much of life as anyone currently in their 30s knew it growing up. You decide that you’re going to make something, and “the process” begins. Everyone climbs into a big hole together somewhere, with all of their thoughts and necessary tools, and when they’re done, that thing comes out, whether it’s the F/A-18, a Led Zeppelin album, Star Wars, or the Macintosh. Ideas made this way, when done poorly, are often huge disasters — stupid concept albums, horrendous movie blockbusters, concept cars, New Coke — but when they work out, they’re the kinds of things we dissect for years. What really went on in there? Who suggested what change to who, and when? Would such and such a character exist if that pizza had been delivered to the right house on that fateful night in 1981?
If there’s anything the internet enables at all points of our life, it’s the opposite of this — agile development, where you build something functional as fast as possible, and then just start adjusting and adding to it from there. We can send early versions of literally everything to audiences of all shapes and sizes in seconds, whenever we want. Kickstarter allows millions of people to watch not only products, but businesses themselves be assembled in near real-time. Our software (which is increasingly how we interact with the world) is patched so often, and so quickly, that eventually the operating systems behind them start asking us to just stop paying attention, and allow them to patch themselves while we’re sleeping, or ordering a burrito. Everything is good enough, and at the same time, never actually done, all the time, forever.
Before we had the internet, almost EVERYTHING was built waterfall style whether it made sense or not, simply because of the logistics involved. So naturally, once we had an alternative, agile-thinking started immediately supplanting tons of established methods, procedures, and industries.
Most of the time, it was hugely effective. Partially it was because many things were simply better when built this way; basically anything that benefited from audience feedback, or post-release fixes. It was also because for so long, we had been stuck with big, clunky waterfall productions our entire lives, and agile thinking gave us new, exciting improvements all the time. Once it became rooted in enough industries, there were multiple new things for us to see… each day, every day, in gloriously theoretical perpetuity.
Today though, we need to make a tougher choice. The logistics problems that prevented agile thinking are largely gone. If anything, our inability to disconnect has actually made true waterfall thinking impossible; creating a “hole” for people to crawl into that prevents builders and designers from getting immediate feedback is increasingly difficult.
That means we can’t just default to agile because it’s there. We have to start deciding if it actually makes sense.
the new finite resource
We used to build everything with waterfall thinking for a specific reason — we often only had one realistic chance to deliver things. Putting a lot of time into things and getting them exactly right (at least according to what the people in the room thought) was a necessary response to a scarcity of distribution resources. When you have to print a million boxes and ship a million 3.5 inch disks to get your project to your audience, you better make sure you get everything in there the first time, or else most people will probably never see it.
Like I said, those particular resource constraints are gone now. But there’s a new restraint that’s easy to miss — a lack of focus and attention on the part of increasingly burdened audiences. You see, agile creative projects are a deal with the people they’re built for, whether said people have agreed to such a deal or not.
Here’s the deal:
- the builder will provide rapid, constant improvements post-release
- the audience must interact with lots of versions of the “finished” project that may or not be any good/what they thought they were getting
- once you pay for the project, it’s up to the builder as to whether to keep iterating (unless you want to go to court)
If your whole world revolves around building this project, you probably aren’t thinking about the audience end of the deal. To you, the most important thing is getting the project done correctly, as fast as possible, and more often than not, an agile process is the best way to accomplish that.
But what about the person you’re delivering to? Is this the most important thing in their life? How many other “not quite there yet” agile products are being delivered to them every day? How many patches are they installing every day? How many bug reports are they supposed to file? How many minimum viable products are they supposed to deal with at a time? And how much bigger are all these numbers than they were two years ago, or ten?
I have a Playstation 3 that I only play every couple of months these days, because I’m 32 years old and I don’t really have the time anymore. But when I do decide to fire it up, guess what? The PS3 happily awakes, and before I can play a silly basketball game for half an hour, I have to update the system software. Whether it’s to add a new feature I probably don’t want, or fix a problem that Sony didn’t catch before I bought the PS3 (or in the five years since), I don’t get to play my game. I get to watch Sony do a little more agile development at my expense.
The average person isn’t completely used to this way of interacting with products, businesses, and the daily routine of life, so they rarely even realize the tradeoff they’re often required to make. They just get frustrated and stressed out, and often feel like no one is taking their lack of available time and focus into account. Because fewer and fewer people really are.
In fact, this way of making things for other people is so widespread, that the entire era feels increasingly needy and intrusive. Nothing seems to work on day one. Everything is always in beta. Many products are abandoned before they ever really reach their stated goal. Anything I buy seems to be some kind of weird “partnership” between me and whoever I’m buying it from, when all I want to do is get what was advertised to me.
That’s why I don’t think it’s really millennials themselves who are so hopelessly self-absorbed; I think they’re just starting to map the world they grew up in to the things and services you interact with every day, as they’re increasingly put in charge of, or made responsible for them. That world never sleeps, is always on, and may or may not be completely exhausting to live in. But millennials didn’t make that world. They just inherited it.
so… what happens now?
We’re obviously not going to go back to the 1970s (whether we want to or not) because the 70s existed in a world where today’s agile options didn’t exist. We didn’t make better decisions; we made easier ones. That’s why I think the right kind of agile will continue to become a standard best practice in most environments, as it’s been doing for years. It makes too much sense not to.
The real opportunity for improvement lies in figuring out the new kind of waterfall; where it makes sense to use, how to minimize its inefficiencies, and how to actually execute it in a world that expects early access and constant iteration even when it subconsciously drives resentment. I’m a huge advocate for this in my professional life, and even as I’ve grown up reaping the benefits of the agile world, my most successful projects have all been big deliverables I deliberately kept under wraps longer than a purely agile mindset would have recommended. Did I often do a “v1.1 release” for these? Of course I did — it’s 2014. Nothing is ever done, and waterfall as a stiff, unyielding ideology is just as impractical and irritating to recipients as the religion of eternal beta is. But what mattered is that I took the time to build the vast majority of these things like I wasn’t going to get a chance to improve them later. Because many times, regardless of the best intentions of you and your audience, you don’t.
That’s my advice to anyone who builds. It sounds simple to take the needs of your audience into account, but it’s just so easy to get wrapped up in what benefits you as a builder. Customer short-term happiness is one of those things, and agile development is often the sugar high of meeting customer expectations. “Yeah, but wait until you see this with next year’s version of Android! You’re going to love it then!!!”
Don’t fall for it. Take your time. Think about the medium term experience people will have dealing with whatever you’re putting out there, even if they refuse to think about it themselves. If you protect people from their own unrealistic expectations, from their own inability to adapt to a world where they have to respond to everything, immediately, forever, over time they’ll grow to love you. Even if they don’t really know why.