Agile Software Development

Post Reply New Topic

I've been on programming teams that called themselves "agile" for a few years now, and I finally got around to reading up on it myself. I hadn't bothered before because my experience has been that different shops put their own spin on methodologies to begin with and all you can really go by is what your boss wants you to do, not what some book tells you he should want you to do. But, in retrospect, I should have looked it up the second time I heard "agile".

Anyway, I took a look at the "Agile Manifesto" and recoiled in horror at a couple of points:

Um, seriously? Well that explains why task assignments, task details, and important technical decisions are only accessible through what I like to call the "rumornet"... and my connection ain't all that good.

Plus... do they expect everyone to remember everything they hear? If they send it to you in written form, it's not going away.... you'll always have it to refer back to later.

Agile shops go so far as to remove cubicle walls and have everyone within each other's direct line of sight at all times - and therefore compelled to be on "public behavior" every single minute we're supposed to be working. And when people need to work without distractions, headphones should clear that right up. Ummmm, yeah.

Also:



What this boils down to is that the team as a whole reaches consensus on who is supposed to do what. "Naturally"... i.e., nonverbally. Uggh... that explains the distinct lack of explicit assignments and the way I kept thinking I was supposed to be working on something that other people were also working on without me knowing it.

All of this has the effect of taking one of the most spectrum-friendly jobs on the planet and systematically making it far less so. If I were paranoid, I might suggest that that was the intent

Well, Agile Software development does attempt to formalize these human interactions so that rumournet (great term, btw) is less relevant.

I guess that didn't make it into the local implementation of agile. Sigh.

Still, can information be said to be "conveyed" when much of it is forgotten and not written down?

I suppose I should look into high-quality portable tape recorders. Maybe an android app can transcribe it while it goes. Of course I'll draw a bit of attention to myself with that...

I use a notebook to write down what I need to remember during conversations. When talking it is common to use the whiteboard for diagramming or CRC cards and you can take pictures of these if you need to.

The Agile methodology is for Web-style projects where the requirements are unknown, designs are figured out just-in-time, and rapid feedback is key. Due to the rapid change, communication is important.

If you don't like these environments, try to work for on an in-house software team where everything is more Waterfall. Requirements are specified ahead of time in detail. However, you are more likely to run into pointy-haired bosses, deadlines, and tons of really bad code in these environments.

Oh I don't doubt that communication is important. I don't object to communication at all... just wish that there wasn't such an emphasis on spoken, face-to-face communication.



I know... I've been there. Agile has a lot of advantages.

Maybe I just don't see all the ways that they leverage verbal communcation because I'm not NT and miss a lot of what gets exchanged that way. Maybe it really does work so much better for them that it's better for them to do without me than to do without the constant verbal communication. Guess it's up to me to do the adapting to them...

Or maybe the agile guys don't have this part quite right...

I guess try to stick to email whenever you can. Personally, I like face-to-face when I need to resolve a requirement problem where I can just point to a few screens or sketch it out (I'm going GUIs) and ask rather than trying to explain in a long series of emails what I mean. If conversations are too loud I put in the headphones, it's really not that bad, I've grown to enjoy programming with music now.

Also, keep in mind good programmers are pragmatists. If you start writing down requirements, sketch design documents, use task management tools, these are agile also so long as they make you more effective. Bad Agile is the evangelical kind that doesn't recognize the unique skills and limitations of different people. If your team has members doing the same work or wrong work because nothing is written down, this is bad Agile.

I think programming is one field where Aspies excel compared to NT.

I did a series of Blog posts specifically analyzing Agile and ASD if you are interested: Round-up of the four part series on Agile and ASD