Throwing Scrum ceremonies and artefacts out of the window and running the project differently; right or worng

There is nothing wrong with doing this if the team feels it makes possible for them to deliver and quickly respond to change.  That is what agility is all about. I know of many teams that will do this if the organization is not willing to change to support the Scrum framework as it is outlined in the Scrum Guide.  But as the Scrum Guide states in the End Note:

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

The Manifesto for agile software delivery does not advocate Scrum or any of the other hundreds of ways that have been offered as a means to be agile.  It provides values and principles that a group of people with varied backgrounds were able to agree upon to enhance an organization ability to adapt quickly to change. There were thought leaders from many philosophies in attendance.  It has been grossly misused and some of the signatories have stated that they wish they had never published.  If a team is able to become more reactive to change and provide valuable product to stakeholders and end users when the product is needed, then they should do so for the sake of the people that depend on the product, whatever way that dependence is derived.

I don't think you will find many people on this forum that would say those teams are wrong.  We will just say that they are not using the Scrum framework to its full potential and offer suggestions on how they might be able to do so.  But none of us are going to say that they have to stop doing what they are if they are still able to deliver iterative improvements that people want in a time frame that they are needed.

Scrum does not work for all teams and organizations.  Neither does Lean, eXtreme Programming, Scaled Agile Framework (SAFe), or Kanban.  There are a lot of places where some portion of many of them are implemented successfully.  Even scrum.org advocates the use of Kanban practices within Scrum.  The framework for that was developed with some of the leading Kanban practitioners. In fact scrum.org has this webcasted listed How Scrum Teams can Complement Scrum by Adding Practices, Tools and Frameworks. 

Scrum is not implemented for it's own sake, but to establish and maintain empiricism under conditions of high uncertainty. That's what the framework is for. So if we "stop doing Scrum", reflect on why. Is it because empiricism is no longer important? Is it because the risk and uncertainty just isn't there to be managed? Or is it because Scrum is exposing an uncomfortable truth we'd rather just wasn't revealed?

"Scrum is not implemented for it's own sake, but to establish and maintain empiricism under conditions of high uncertainty. That's what the framework is for. So if we "stop doing Scrum", reflect on why. Is it because empiricism is no longer important? Is it because the risk and uncertainty just isn't there to be managed? Or is it because Scrum is exposing an uncomfortable truth we'd rather just wasn't revealed? " 

Why here is simple-because release of the profitable product, i.e. increasing product value for stakeholder and their organization happened by changing Scrum methodology into something else.

Here we come to basic point while, Scrum, and Agile exist.

I always like to repeat, also during coaching, that unlike Prince 2 or other waterfall methodologies who were created for government or academic institutions, Agile is purely commercial instrument, which was developed for sole purpose of MAKING MONEY.

The ultimate goal of whole Agile methodology, which is reflected almost directly in most documents shaping the concept is to help people who sponsor the projects to AVOID LOSSES and INCREASE PROFITS.

In other words Agile as whole exists in very pragmatic, commercial mental framework-not for sake of science, not for sake of bettering mankind, not for empiricism as such and increasing knowledge base of mankind, but purely FOR PROFIT.

How the profit is divided is another story, but because of this approach I am always rather cautious about use of Agile in government institutions, sponsored entities and other organizations who don't exist for profit; for a same reason I am always insisting that Scrum teams I work for should be financially rewarded every time product which they develop increases value

Having said that, justification of "throw Scrum out of the window" for this particular project is quite evident-the project would be in less financial risk and would have value otherwise.

Which does not mean I will not use Scrum(impedable as it should be) for another one-as long as it helps adding value to the product.

Agile is purely commercial instrument, which was developed for sole purpose of MAKING MONEY.

I completely agree with that statement.  I have said many times in these forums and to anyone has the unfortunate opportunity to hear me rant that "Agile" (with a capital A) is a word made up by people that wanted to commercialize the Manifesto for agile software development.  The word "agile" (with lowercase a") is an adjective meaning "ability to move quickly".  The only time you will see me use a capital A in agile is if it is the first word in a sentence. 

You've seen and read my first response. I do not see any reason that your approach can be said to be wrong.  As @Ian correctly points out, there are some common reasons that Scrum is not fit for all organizations.  

I want to point out some things from the responses in this thread.  @Nicholas, you made these statements

Why here is simple-because release of the profitable product, i.e. increasing product value for stakeholder and their organization happened by changing Scrum methodology into something else.

I always like to repeat, also during coaching, that unlike Prince 2 or other waterfall methodologies who were created for government or academic institutions, Agile is purely commercial instrument, which was developed for sole purpose of MAKING MONEY.

Having said that, justification of "throw Scrum out of the window" for this particular project is quite evident-the project would be in less financial risk and would have value otherwise.

I will say that all of those statements ring true to me.  But I have never seen anything written about Scrum being anything but a way to deliver value to the stakeholders quicker and iteratively when there is a risk atmosphere around the product. But as with all things in the current world economy, money is a key driver to many decisions. In the instance where the organization using Scrum is a for-profit organization, the ultimate goal is to make more money.  In the case of the organization using Scrum is non-profit or governmental, it is usually to reduce the cost of delivery.  The same could be said for any Agile practices.  The ultimate goals are to make more money, whether that is by spending less or bringing more in. 

I haven't seen anything in this thread that I would say is someone saying any of us are wrong.  In fact, @Ian gave an excellent commentary on why many organizations do not have success with Scrum. All 3 of his suggestions can be the reasons for  In fact he even supports your arguments that Scrum is not the end-all-save-all solution for everyone. 

I would be interested in reading other people's opinions on this if anyone is willing to offer up their voice in the discussion.

I don't know enough about your specific situation to conclude or dispute that "stopping with Scrum half way of the project" was the reason for success. In any case, I am happy to hear that you and those teams found something that worked for you. At the end of the day that is what is important.

As stated above by @Ian and @Daniel Scrum is not intended to be a one size fits all framework. The Scrum Guide itself supports this calling out that you can try it to see if it fits or not...

"Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value."

If Scrum was not helping these teams achieve goals and create value, then trying something else seems prudent. I have worked with teams where Scrum was not the right fit for their situation and guided them towards other ways of delivery that were better suited.

I have also worked with teams where Scrum was identified as the issue, only to discover it wasn't Scrum at all, but how it was being leveraged. Mechanical Scrum or SINO (Scrum in name only) can be very problematic when the foundations of Empiricism, Lean thinking and Scrum Values etc. are missing. 

Agile manifesto was a point in time capture of how those 17 signatories were operating with their lightweight frameworks and approaches back in 2001. What they came to value while working with Scrum, XP, DSDM etc. and some associated principles that captured commonalities with their approaches. Frameworks and approaches like Scrum that came before that big A agile term have continued to evolve and change through experimentation and learning.

The Scrum Guide is an invaluable resource that reflects the vast experience of its writers. I can attest to this from personal experience, having been in situations where the knowledge and insights from the guide could have prevented issues.

Bill-payers sometimes make mistakes, too, even in evident non-complex matters. I have been in a situation where I warned my superiours that our backups were not in good condition. Unfortunately, after a crash, we had to urgently reinstall an application from scratch, causing us to lose one month of work. Despite having been paid for my advice and time, I still feel ashamed of being unable to persuade the right people about the significance of investing in backups.

It's essential to approach any decision to commence with, adjust or abandon Scrum carefully, considering the context in which you work. Before implementing Scrum, assessing whether it's suitable for your situation is vital. Similarly, before quitting Scrum, it's worth evaluating whether you've given the framework enough time to work effectively.

Moreover, it's crucial to recognize that your team has probably invested significant time and effort to master Scrum. I would consider the team's investment and carefully assess the potential impact before modifying or abandoning the framework. It is highly probable that the writers of the Scrum Guide have faced similar challenges and considered them when creating or updating the guide.

Ultimately, the goal should always be to help teams work more effectively and efficiently and deliver value to their customers.

Agile development is a tool for mitigating risks. Whether or not this translates to business success is a whole different story. The same goes for creating value. Increasing the value of the product doesn’t automagically increase the profits. Business and development are two different things.

Also you still didn’t give us the reasons why Scrum was ditched or why other methods gave them more bang for the buck. Or the other way round: Why did the project start with Scrum in the first place?