Disrupting Agile and the Process Industry
Tonight I give you post number 5 of Developer Hegemony week. If you’d like a free paperback copy of the book, remember to sign up for the Thunderclap.IT campaign so that we can get to the sharing threshold — we’re now three quarters of the way there, but I still need your help. It only takes a second. About 25 more share signups, and I’ll do the raffle!
Whenever I hear the word disruption in the context of industry, my mind does something weird. It immediately transforms it into someone saying, “hashtag disruption” and then doing jazz hands. So you can only imagine my mental model (and, honestly, mild hypocrisy) for a title about disrupting agile. But please bear with me.
I once wrote a post about the nuts and bolts of buzzword fatigue. And, clearly disruption and agile both quality as buzzwords. Disruption as a concept originated in Silicon valley’s lexicon. From there, it wormed its way out into general, uncool industry like a rogue wave of fanny packs. By now, people talking expansively about disruption have probably never disrupted anything more than an Applebee’s by coming in for dinner 3 minutes before closing. Jazz hands.
Agile the Revolutionary Idea vs Agile the Enterprise Project Management Tool
And agile. Oh, poor agile. If the not-so-fast followers have taken the luster off of disruption, they’ve ground agile into a layer of dust by turning it from a revolutionary idea into a trillion dollar process industry. Here’s a visual of agile at its birth versus as it exists now.
Now, to be fair, this doesn’t compare apples to apples. Agile started as a philosophy and, over time, burgeoned into a gigantic ecosystem of enterprise project management. So think of it more as comparing apples to the IRS.
This, in particular, speaks to the power of the buzzword effect to dilute meanings and cloud issues. The work of the signatories of that manifesto and of their fast followers fundamentally changed the industry for the better. As far as contributions to the state of the craft and the business of automation in order of importance, I’d honestly put them up there with people like Alan Turing and Herb Simon.
And yet that original spark has somehow drowned in a sea of programs that will certify you in how to persuade people to stand up for daily status meetings. I’m now going to smash two buzzwords together in the hopes that they’ll somehow cancel each other out. The agile process industry has become ripe for disruption. So, let’s talk disrupting agile.
The Rise of Agile Formalism
I’ve wandered around over the years, poking my head into all manner of shops. These range from plenty of large enterprises, to the mid-sized organizations, and right on down to startups. And, as the years have passed, all of these organizations have shifted. Some have dived into agile methodologies wholesale, while others have held out. But, even the holdouts generally have canned excuses ready for not going agile, which serves as an excellent referendum on the state of the art.
The world has accepted agile as the right answer to the question “how should we write software?” And, taking the manifesto at face value, that’s great. It means a move away from wasteful formalism to pragmatic delivery of value. At least, in theory. In practice, many organizations seem more to have figured out how to pragmatically deliver wasteful formalism.
Somehow, agile became Agile, which became Scrum, which became The Scrum Methodology, which then got scaled for the enterprise. By the time gigantic corporations started figuring out how to “go agile at scale,” the ideas in the manifesto had “graduated” to formal project management. CIOs said things like, “yep, we know the drill because we do this every 10 years. First it was waterfall, then RUP, the SDLC, now scaled agile. Hire some consultants and whatnot and send all of our people out for certifications, and we’ll get a letter of official agile compliance. Let’s follow a plan to get a contract in place for comprehensive agile documentation, processes, and tools.”
Pre-Disruption Steady State
What does the fallout of this shift look like on a day to day basis? I painted a pretty Animal Farm-esque picture of the view from the C-suite, but on the ground you see more subtlety. People go out and get Scrum certified, and this involves actually reading the Scrum guide and reading (okay, probably memorizing) the manifesto. These people then enter the organization and socialize these lessons with the kind of pseudo-religiosity peculiar to idealist conception of corporate culture.
“Can you believe what happened during the daily standup? Harriett totally skipped listing what she did yesterday, and Joe actually leaned — LEANED — against the wall. We’re going to need to retrain.”
We’ve taken wisdom gathered by some top-notch software pros in the 90s, and we’ve kind of frozen it in amber. Since agile originated as a philosophy, its wisdom has aged well. But as we collectively elevate the movement’s tactics to rote ritual, some of those tactics age better than others.
I’ll draw a line at this point in a place that you might not expect. While I could talk about the movement’s focus on common sense, tight feedback loops, continuous learning, or business/customer partnership, I’ll look instead at its emphasis of physical presence. The ceremonies, the team dynamic, and the interpersonal interactions all demand colocation.
Skeptical? Consider some core practices that you see as part of corporate agile adoptions. Eschew digital project management tools in favor of cards, sticky notes, and painter’s tape. Have everyone stand together in front of the card wall once per day (at least). Have the developers sit in pairs, and establish core hours during which everyone sits in the “team space” or the “bullpen.”
We kind of think of all of this as timeless or wisely retro, in the same way that we think of “ancient philosophies.” We like the way it “gets us back to basics” and “humanizes things.” But look at it another way, and you’ll see a collaboration paradigm that people in the 90s could have used to develop software, back when digital collaboration would have meant 56K modems and Citrix. Look at it yet another, more critical way, and you’ll see something Silicon Valley types would call “ripe for disruption.”
Oh, don’t get me wrong. It isn’t as though no changes have happened here in 20 years. It’s just that the changes involve, as Henry Ford might apocryphally have said, building faster horses. Companies build incredibly elaborate tools to simulate physical presence in a world where physical presence presents an increasing barrier to competitiveness. Unlike the 90s (or the 00’s following the dotcom bubble bursting), limiting yourself to collaborating with those that live within 20 miles, constitutes a serious competitive disadvantage.
So how long before companies stop trying to build the faster horse of elaborate presence simulation, and opt for the car of developing legitimately innovative remote collaboration paradigms?
Efficiencers, Take Note
After the dotcom bubble burst, US companies began a race to send all of their software development overseas. As a newbie to the workforce, I remember viewing this as an existential career threat. People even suggested that I might have chosen my career poorly.
But then, “outsource everything” gradually fizzled. The sizable communication barriers (time zones, cultures, expectations, etc) proved too much. And it turns out that shipping a spec to some country halfway around the world and then asking for the resultant product 2 years later doesn’t work with software the way it might with, say, an oil tanker. So the hype ended, the jobs came back, and the pendulum swung.
But don’t be fooled. In the last decade, communication technologies have improved dramatically. When all those jobs went overseas, we didn’t all carry devices in our pockets that would allow high definition video chatting with people on the other side of the world. But we have that now. And we have all sorts of other incremental improvements that make software development a much more global game. And, on top of all of that, the US has started to enact policies that will encourage software development to migrate to other countries.
Software development is getting decidedly more global. And you can position yourself to be on the wave of that movement as it crashes over us. Why direct this prognostication piece at efficiencers? Simple.
I suggest you start brainstorming ways to facilitate remote-first, asynchronous, global software development. If you can make tools that support these new workflows, you might earn a nice living. If you come up with a means of truly disrupting agile in favor of the next big movement in software, you can write your own ticket the way the pioneers of agile did before you.
Want more content like this?
Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)