someengineer

One thing about Agile that I don't see mentioned much is that it provides a way for bad managers to marginalize the effects of low performers among their groups, though at the expense of high performers.

Every company has "cowboy" programmers who break shit and ruin their coworkers' lives with massive 1am check-ins, and a lot Agile seems designed specifically to put up road blocks to prevent this from happening. Managers love it because it provides an escape from dealing with problem employees directly. Most of the vehemently anti-Agile people I've worked with were grossly overconfident in their abilities and difficult to work with, which I think supports this idea.

Unfortunately, the only way for this non-management technique to be effective is to do it dogmatically with no deviations (otherwise the cowboys will always have some excuse for why it shouldn't apply to them), and this is where things start pissing off the actual talent.

A common pattern in embedded C is to use something like "goto fail" instead of assert, wrap your function calls in this sort of macro, and then do error handling in one place at the end of the function.

Apparently Apple is unaware of this technique...

I don't suppose there's any plans for a Word export feature, is there?

Unfortunately, a lot of consulting jobs require all docs to be in MS Word format... Infuriating I know.

The point the article is making is that all the problems the anti-agile crowd complains about are less related to agile and more to a dogmatic adoption of specific tools. I think the point the author misses is the irony of the whole thing. The anti-agile people get annoyed at something like religious demands for 100% unit test coverage, so they instead adopt their own extreme, narrowly focused rules like refusing all TDD. This is how flame wars work.

I've seen agile methods be most effective at companies where software developers are a minority. Scrums and sprints can be very useful when you've got many outside interests hammering at you for various feature requests and bug fixes. Done right, it keeps the software group's priorities aligned with the company's.

Totally agree. His reply is an overly polite response to a rather snarky rant on why the Linux devs should just shut up and accept the author's massive merge. Giant projects like the Linux kernel just don't work that way.