Some Free Time

Fri Feb 19, 2010

I finally have some free time to write.

It's been hard to come by; I work at an office where the Agile Mafia has taken over, and the only result I've observed is that there's less free time and more shitty, un-maintainable products. It's weird, because looking around at real tech companies, you'd get the impression that Agile was dead (or at least, restricted to the less ridiculous aspects). I'm here to tell you that if you're at anything other than a tech-focused company, you get to put up with all the annoyance of "weekly sprints", "daily scrum" and "tighter scheduling" without getting any of the real or imagined benefits.

Here's the result, from someone at ground zero:

  1. You're always forced to over-commit.
  2. You're held to your commitments, and missing a deadline (no matter how unreasonable) is seen as a failure on your part.
  3. Bug fixing and testing is expected to go on for 1/4 as long as development.
  4. When there are issues on live, you are expected to handle those, then work overtime to catch up with your actual work (because the plans are always made on the assumption that this time nothing will go wrong).

Number 1 means that there's never enough time to get everything done. Number 2 means that it's actually better, from the incentive perspective, to half-ass everything you're tasked with so that you can call it "done", and tell yourself and your peers that you'll fix it later. Number 3 means that in any given release, half or more of the major issues get pushed out onto our clients (who promptly complain about those issues and cause number 4). Finally, number 4 means that there's never enough time to fix the defects introduced in numbers 1 and 2.

Ironically, number 2 also means that if performance is measured closely enough and used as a gauge enough times, anyone that tries to point out and/or work against the negative re-enforcement loop gets canned.

In other words, I have observed that the Agile process, used as it is at my company decreases the number of competent developers/designers, decreases the quality of work done, decreases the number of working features present at any given time and (if I can imagine their viewpoint for a moment) erodes client good-will. This sounds like it's bad.

I don't even want to think about a general case though. I'm thinking right now. A feature I'm working on is languishing. It doesn't get attention because it's really only been requested by a couple of clients, and because the rest of the dev team though it would be trivial. It wasn't I've watched the programmer responsible struggle the entire way through. Hell, the flash side alone was struggle enough. The back-end accounting logic for this thing must have been monstrous. We're at the last day right now. Tonight. As I write this, it's 11:45 pm on the Friday before release, and I know it's going out on Monday, come hell or high-water.

The process we're using, and the assumptions we've internalized combine to mean that I can't fix it. That if I try and succeed, I'll get a talking to. If I try and fail, it'll just re-enforce the perception that the process should not be deviated from.

Superstition is infuriating in others, though I realize that it must affect me at some point as well.

Creative Commons License

all articles at langnostic are licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License

Reprint, rehost and distribute freely (even for profit), but attribute the work and allow your readers the same freedoms. Here's a license widget you can use.

The menu background image is Jewel Wash, taken from Dan Zen's flickr stream and released under a CC-BY license