guy with poster

Them Deck Chairs Ain’t Gonna Arrange Themselves

So I’ve noticed something at the last few companies I’ve worked at, including this one. And it seems be correlated with this new movement toward “agile” methodology.

“Agile” is just one of the many “get work done” formulas companies adopt to get deliverables out the door faster. It’s a grand tradition–every few years there’s some new approach, usually peddled by think tank snake oil salesmen, promising to “more, faster, and better”. They’re like diet fads, and just as effective.

You only ever hear “agile” and “waterfall”. Sometimes “kanban” and “scrum” are thrown around, but it’s all Agile. Or at least it tries to be. See, the thing is, all I see is this phenomenom in software development that I call “arranging deck chairs on the Titanic”.

First: no company fully adopts the Agile playbook, so everyone’s doing it “half-assed”. Unless you go all the way, you don’t get the advantages of it and mitigate the disadvantages. They’re picking and choosing what they want to follow and skipping the ones that “seem too hard”. You don’t get to follow “some of the rules” in football. So what you get is managers moving their little issues around and giving them arbitrary numbers in different fields. Meanwhile the BAs, QAs, and developers are really doing waterfall (which means work trickles down to you and you do it).

Here’s what happens. The people at the top want features X, Y, and Z rolled out in Q amount of time. The feature sluices down through executives and managers and directors, getting refined and touched and manhandled until it finally gets to someone to actually do the work (read: me). And by then, everyone’s added their two cents in to which “sprint” it’s going to be in, what the priority is, estimated hours for analysis, for development, for QA, how many “points” it’s worth, what version it’s targeted for, etc. Nothing has been worked so far. Some idiot in customer service reported it and no one’s actually checked to see if it’s feasible. It’s all a bunch of wool-gathering around the issue instead of actually working the issue. There’s more metadata about it than code to fix it.

Would this work if you were going to write a book? How many pages should it be? What is the typeface? How many chapters should we divide it into? Does it count as middle grade or YA? How long will it take to write? What quarter would the book be released in? How complex do we think the prose will be? What’s the ISBN number?

Has any of this gotten words on a page? No.

Second, what is the point to it all? The whole point of agile is to be able to accurately predict when work will be done and how long an issue will take (based on past experience rather than predicting the future). But you’re still basing it on developer/QA estimates which are numbers pulled out of an ass. Development work isn’t like building a Lego structure or making a sandwich. If there were clear directions, it’d be easy to predict, but that’s not why I get paid the big bucks.

Development and bug-fixing is not like constructing, it’s fishing. You cast out your line hoping this combination of bait, line, weather, lake, jiggle, water temp, will make the fish bite (read: will fix the bug or is what’s causing the bug). If it doesn’t work, you cast the line again. You might end up barking up a lot of different trees to see why that certain file is erratically failing during SFTP transfer. I don’t get paid because I know how to solve the problem, I get paid because I know how to investigate the problem.

And to mix my metaphors further, no two snowflakes are ever alike. Telling the scrum-master when that fish is coming back to the dock is wildly impossible. I can’t see how big the fish is under the water, or know what kind of bait it likes. This doesn’t even account for the analysis-phase of any issue, code reviews or work that comes back from that, or any rework due to QA.

The point of agile is to have high quality work that doesn’t come back from QA. But that is highly dependent on the quality of the developer. I live by a different rule: good, fast, or cheap–you can have two of the three. And since my pay is out of your hands, choose between fast and good.

I understand managers want to have insight into what work is being done. They want to know how much there is to go, how much there is still to do. I know I like seeing things done. But having a burndown chart shoved in my face at every stand-up means nothing to me. If a thing gets done, it gets done, it doesn’t matter whether it was within the two-week sprint bounds or not.

Managers want to feel useful because they’re not in the trenches. They’re directing from a command post via walkie-talkie. This is why they invent cute little buzzwords like “key learnings” and “parallel path”. So when a company says they’re “agile”, what I hear is “we pick-and-choosed some procedures to make us seem current and hip, when really, it’s the same old development cycle we’ve always had”. When a manager asks for an update or remaining time estimate on an issue each day, what I hear is “When are you gonna get done? When are you gonna get done? Huh? Huh? When are you gonna get done?” It’s obnoxious. But as a software engineer, we’ve always had this problem. Anything to deflect accountability.

Eric Juneau is a software engineer and novelist on his lunch breaks. In 2016, his first novel, Merm-8, was published by eTreasures. He lives in, was born in, and refuses to leave, Minnesota. You can find him talking about movies, video games, and Disney princesses at where he details his journey to become a capital A Author.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.