The authors of The Agile Manifesto I think agree more with you than with many of the process zealots selling books and classes about agile development. There has been a follow-up saying they never intended the formalization of their people over process rant into such strict processes, which makes sense.

The actual processes are largely inspired by Japanese manufacturing techniques. They get labeled "agile" mainly because that's the hot word and the original manifesto authors didn't trademark the word to sell books and classes.

I'm still unsure what part of any of this situation encourages you to keep saying that people who do test-first development or who have daily fifteen-minute status meetings are absolutely and definitely replaceable cogs who can't develop code and need to "code by numbers". That seems like one hell of an unsupported claim.

I'm still unsure what part of any of this situation encourages you to keep saying that people who do test-first development or who have daily fifteen-minute status meetings are absolutely and definitely replaceable cogs who can't develop code and need to "code by numbers". That seems like one hell of an unsupported claim.

Um; I never mentioned (anywhere in this thread) test-first development.

1. <cite>Daily 15 minutes status meetings:</cite>

   The following is a from-memory precise of a report I wrote over 20 years ago and presented at a "weekly cascade meeting" one of my clients insisted I attend:

   <Reveal this spoiler or all in this thread>

   In the short term, I was excused future attendance -- I had no need or interest to be keep up with the changes in the site maintenance schedules; company pension plan changes; corporate wide managerial promotions; or retirements. I was a contractor.

   Why was I ever required to attend? Because the employees felt it was unfair for contractors to be excused the drugery of attending, when they had to.

   In the longer term; it actually triggered a sea change on that site; that spread to others.

   It wasn't all my idea. The original moans were mine to my PL (same guy mentioned earlier) and the write up was all my own work; but it was him that suggested I should bind copies and hand them out in the meeting. I was his stalking horse to effect change on several occasions.

2. <cite>absolutely and definitely replaceable cogs who can't develop code and need to "code by numbers"</cite>

   First. Nothing I've said implies anything about the programmers subjected to these methodologies.

   The statements are about the goals of the methodologies (as sold to management in private by the purveyors of the branded methodologies.)

   These methodologies are essentially public domain, free for any company to use.

   So why do so many of them spend money on consultants; training courses and certifications from branded versions?

I obviously don't know how things go in every company; so I can only talk generically; and as I'm trying to make supporting argument for a position; it is natural that I will tend to the extreme that support that position.

Its neither personal nor accusatory.

And remember; I've nothing to gain or lose by what you or others do. Especially if they choose to do things that work for them.

But the single most frustrating thing as an "old timer" is watching younger generations making the same damn mistakes I made; and doing so willingly and enthusiastically.

If my posts in this thread have caused any one young guy or girl to step back and consider their work situation with a broader, more skeptical eye; they've been worth my effort.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked