Yes.

Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.

Agile, being about "Individuals and interactions over processes and tools" is specially good at that.
The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.

"Because it sounds good?"

No. Because it is about individuals, not unfaced meatballs.

"By definition, if can't fit into a single Sprint, then you cannot do it"

That's right.

But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.

Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.

"The report is required to be done by Dec 1"

That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.

This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.

"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."

You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold:
1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be.
2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.

"Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally."

Agree on that. At the very least, a developer-opened task would have to be agreed first with the customer or even created by the customer himself upon the developer's request.

"I came back 6 months later once only to find out..."

Your fail. If you had come back two weeks later instead of 6 months, you would have found much earlier. You know, "agile" is a burden for the customer as much as for the developer. You can't have "agile" without both of them.

"the bugtracker agile system."

You yourself say it afterwards: just call it "the issue tracker system" and you are done.

And, yes, it probably would work better than the average "agile in the forms, old school everywhere else" because, since most of the problems about agile come from people and culture clashes than anything else, having a simple and easily understandable means to produce a queue and track its evolution makes for a perfect start point that it is certainly fully aligned with the "agile manifesto".

Taking the first day's morning to explain the customer what "agile" entails, specially for him -and agree with him on doing it that way (or not, but then you are fred to go waterfall or anything else that better suits the scenario), and the evening to explain both customer and the internal team what DONE means, and a Redmine site for tracking customer-opened issues and the internal team-produced documentation should be more than enough on most cases.

But this is just too cheap and logical to gain traction.

"I end up being unable to do the tasks (stories) assigned during the development period (sprint)"

Bzzzt! Error!

Stories are not *assigned* to the sprint, they are *queued* for the sprint. It might look like splitting hairs, but it's far from that.

Part of the reason d'etre of agilims is that you don't have a crystal ball to see the future. Maybe your team's velocity is not well stablished, maybe you missed the complexity of the task... when planning a sprint you are not *commiting* to complete, say, these five stories, but agreing with your customer that these 1, 2, 3, 4, 5, 6, 7... stories are the most interesting right now and in that order, and that given your current knowledge about yours and your team's abilities and the complexity of the stories at hand you *probably* will be able to fulfill 1,2,3,4 and 5 of them by the end of current sprint.

Once again, the old problem: agile "processes" put on top of the old mentality -like trying those new dancing steps from charleston over the same old waltz. Funny results guaranteed!

"The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states"

Wait... what!?

You obviously don't know what you are talking about.

Why do you think "velocity" is not interchangeable and it is instead tied to a given group if people were interchangeable? Why do you think "velocity" evolution needs to be referenced just to a given team's history if it could be stated in advance?

"Individuals and interactions over processes and tools" is the first basic tenet of agilism. Why do you think "individuals" is the very first word of it if people were interchangeable and, thus, out of consideration?

"See? None of these involves requirement changing. How you can do waterfall in large projects worth millions is beyond my imagination..."

I see your point but I can't see its relationship with anything agile vs waterfall here. Nothing you talk is about your application's functional requirements so it doesn't even enter the agile realm.

"There is nothing about waterfall that requires you to make ironclad decisions at the very start"

Of course there is. Once the requirements phase is closed, it is closed. You can have iterative waterfall, but you need to wait for next iteration to alter requirements. You can have overlapping waterfall, but overlapping shouldn't make more than 10-20% of your gantt, and even then, at the cost of increasing at least on the same proportion your allowed cost/deadlines variances. In fact, the only guarantee for deliverability on waterfall comes from the fact that when a phase is closed, it's closed and you can't go back to it, which would add uncertainty to the process.

"The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly"

It is, but that's the case because of the way companies are organized since Ford days: hierarchies, functional and responsability clear niches and boundaries, processes and bureaucracy, while agilism is about team playing, empowering people, planitude and results over processes and paper trails.

Agilism looks hard for too many companies the same way chess looks hard when you try to play it on a tennis field and with tennis rules.

"You are basically just saying that agile is more *fr*agile than waterfall"

It is, but then you need to add context to see what that really means.

Agile was always about empowering people over process and bureaucracy. If you are process and paper trail centered you are not doing agile. Full stop. Please, take your time to rumiate this.

Now let's imagine you really are embracing agile and let's think about your team's members (not only developers but management and even customers): is it really advantageous to empower them? Or is it like giving a loaded gun to a monkey? For one obvious thing, taken right from the agile manifesto "Customer collaboration over contract negotiation", will your customer abide to collaborate or will he want a full contract with all things strongly tied -costs, deadlines, features... by day one? Because if it's the latter, you can forget about agile right on the starting line, you see...

Now, on waterfall: of course it is more solid and efficient than agile... provided the customer (be it internal or external) perfectly understands his needs, is perfectly able to transmit them, their needs are perfectly understood and expressed formally on paper, they are agreed back by customer and you have an experienced enough team all across without a hidden agenda.

Failing anything in the list above, waterfall not only tends to quickly fall apart, but doing so in very expensive and notorious ways that agile mentality (in any of its incarnations) provide checks and balances against (but first you need to take the time to understand what is all this stuff about).

Now that I reread what I wrote, find it similar to the republic ideal: it works because its checks and balances, but obviously they only add more moving parts (thus fragility) and unefficiencies... if only everything worked as hoped.

"I've been learning to appreciate older stuff as I've gotten older"

Good. By the day you get retired you might reach master Monteverdi.

"still most music is base on repeating over and over again."

I know what you mean: Wagner -> Mahler -> Bruckner

"Of course, we're not going to do anything about the problem. Of course not."

[ironic]
Well, I used to be a denialist that thought there were nothing needed to do, because there was no problem.

But now, I'm convinced: there is a climate change and it is pushed forward by humankind.

Unfortunately, it's too late to avoid it, so I'll do nothing either.
[/ironic]

"It is called support service"

No, it isn't. Adding functionality to a new environment is not support.

"While I understand that perpetual support for older devices is not viable"

And then, wrong again. Given support for what it is, the ability to substitute broken parts and correct what was not working from the very begining should be supported basically forever, much more so for software, since software doesn't have wearing parts.

Heck, I have no problem finding parts for my 15 y.o. car but still my printer can't be the same?

"With both data collection and a restore function, Windows will just set up again from an installation image"

Yes, one that will put the user a few gigas back the times and open to vulnerabilities till upgraded -not to talk about the inability to use the computer for some few hours.

Nice.

"The blame goes where it belongs, and the consumer will buy a new printer."

Surely will. A perfectly working system stops working because Microsoft singlehandledly changes the system but still the blame is for a third party and the solution is me expending more of my hard earned money?

Ubernice.