Summarizing increments for the review - when and how?

For example I read that in case of complex software coding projects it`s often not possible to have/present a "deliverable" increment after *every single* sprint as it requires several more sprint`s newly added functionalities to create a reasonable release.

Be careful of what you read. A complex challenge is precisely the situation why at least one usable Increment ought to be delivered each Sprint. The leap-of-faith being taken, before obtaining an empirical outcome, would be too great otherwise.

Nothing is presented in the Sprint Review. Instead, the work that was accomplished is discussed with the stakeholders so that valuable feedback can be obtained for any type of course correction that might be needed. 

The increment(s) created during the Sprint do not have to be releasable.  They do need to be usable.  Usable can mean many things.  It could be usable to the Developers because it creates a foundation upon which to build.  It could be usable to the stakeholders to perform activities if they choose to ask for it's delivery.  It could be usable to foster conversation about possible options for solving problems.  It could be usable as proof that an idea isn't feasible. 

The Sprint Review is not a presentation. It is an opportunity for the Scrum Team and stakeholders to discuss the progress and collaborate on a plan for further progress.  It is not a formal meeting, it is an event where people gather for a purpose.

I encourage you to read the Scrum Guide multiple times in it's entirety.  Once you start to understand the true intention, it will be easier for you to form your own opinions and to spot those opinions of others that aren't in line with Scrum's intentions.

I do think that it's true that, in some cases, it may take multiple Sprints worth of effort to get something that is worth deploying into production. However, that doesn't mean that you can't deploy the work more frequently to a lower environment to get feedback from key stakeholders and make decisions about next steps so that when you do deploy into production, it's a useful product.

It's very important to keep in mind that Scrum - and, more broadly, agile methods in general - are about feedback loops. Summarizing or presenting work isn't an effective way to get feedback. Keeping your product in a working state and getting feedback on that working product is the most effective form of feedback. There's nothing that says that feedback has to come from your production environment, though. Working product in a test environment is just as useful. Working product and hands-on usage from key stakeholders is key, though.

Agree with everything Ian, Daniel and Thomas have shared.

Regarding...

For example can we use click-through-prototyping-surfaces instead, in the software example - or would that violate the definiton of "increment"?

A prototyping-surface is not the same as useable product, it a facsimile or representation of how the product may function. I guess you could say it violates definition of increment in that it would not meet the Definition of Done which is the commitment for increment. 

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Demonstrating un-done work gives the impression that the work is done and usable. Imagine stakeholder disappointment when it takes another or perhaps several more Sprints to complete the work that was shown, and assumed to be done. Trust is sure to be damaged by this.

Thank you all, but I have a re-question concerning the prototype topic.

I recently discussed the use of scrum with a guy who works in the producing industry and he argued that it is nearly impossible to have an increment in that "hardware world" - his arguments were like:

Until the product is actually usable for THEIR kind of customers, material would have to be ordered and usually a production phase lasting several weeks would have to be run through. Before the production of the "increment" could be started, at times even special tools would have to be manufactured or the production system would have to be configured for this.

He said it simply would not make sense to run through this elaborate process in every sprint. Therefore he interpreted the requirements of Scrum - in his understanding and in his special company ecosphere-adaption - - to mean that the "increment" must be an object of value that is one step ahead in terms of the product to be created.

In hardware development, this to his mind/understanding would include not only prototypes of components (e.g., from the 3D printer) but also drawn design concepts and test reports from the lab for specific build variants. These he said could definitely be discussed with the product owner/stakeholders/customers during the reviews, even if these kind of increments are not "directly usable" for the customer.

My questions now are:

1.)

Does this use of prototypes as mentioned in my example mean that he (and no, I am not him, by the way...;-)) is in fact no longer practising scrum as defined in the scrum guide = that it is one of the many examples from business world where an organisation thinks it is acting "agile" (in the concrete case with scrum), but in fact it doesn`t?

2.)

Or does that mean his kind of work processes/products are an example of work which is not appropriate for the certain method called "scrum" (remembering the Stacey landscape...)?

@daniel Wilhite - I am confused by your following BOLD statement - 

The increment(s) created during the Sprint do not have to be releasable.  They do need to be usable.  Usable can mean many things.  It could be usable to the Developers because it creates a foundation upon which to build.  

Are you saying that the increment wont have any value for the end users/business owners and the developers can spend entire sprint working on tech. piece which they would utilise in next sprint. Please clarify on this.

 @daniel Wilhite if you dont mind I have to disagree.

Increment should meet Definition of Done at the first place, but  it also should be ready to be released and ready to use by end user.(according to the Scrum guide itself)

If it is not, that means DOD is not established properly.

Sprint review indeed isnt a presentation or gateway for increments. It is just working session to figure out what to do next.

As for original topic, usefulness of Scrum outside IT depends on the industry. Increment and actual product too. 

Does this use of prototypes as mentioned in my example mean that he (and no, I am not him, by the way...;-)) is in fact no longer practising scrum as defined in the scrum guide

How are they establishing and maintaining empirical process control in that situation?

We do not implement Scrum for the heck of it -- we do so to establish empiricism under conditions of high uncertainty. That's what the framework is for.

There's no point in twisting Scrum to fit a non-empirical environment, since the empirical outcomes would not then accrue. They are doing something else. The outcomes they get may or may not be satisfactory, but it isn't Scrum, and to pretend otherwise would reduce transparency over what the framework means.

Increment should meet Definition of Done at the first place, but  it also should be ready to be released and ready to use by end user.(according to the Scrum guide itself)

@Nicholas, where in the Scrum Guide does it say that an increment has to be ready to use by the end user?  It states that it needs to be usable by stakeholders.  But not all stakeholders will be external or even the end user.  The Scrum Guide even calls out stakeholders separate from end users when they provide a definition of a Product.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Stakeholders could be people with a stake in the product being released.  Sales, Marketing, Legal, Compliance officers could all be stakeholders.  Just as other developers could be a stakeholder.  

Similarly, the Definition of Done does not have to state that it can be released to Production.  Many times, that statement is included but it does not have to be.  I have worked with more than one Definition of Done that did not have that statement.  It is a description of the state that is reached when the Developers say that they are "done". The Scrum Guide states this.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

I see more emphasis put on the quality of the increment than I do the places to which it can be deployed.  If can show me in the Scrum Guide where it states that the increment has to be ready to release to the end user and the Definition of Done has to require that, I would be grateful because it will allow me to expand my knowledge.

@Shalabh

To be upfront, this is my opinion and may not be shared by others.  However, it is how I interpret the Scrum framework based upon my understanding of the Scrum Guide.  I have helped implement this interpretation with success.  It may not work in all situations though.

Are you saying that the increment wont have any value for the end users/business owners and the developers can spend entire sprint working on tech. piece which they would utilise in next sprint. Please clarify on this.

I am saying an increment is born when it it meets the Definition of Done and is usable by the known stakeholders of the product.  If other developers are known stakeholders, the increment is usable to them and it meets the established Definition of Done, then yes.  The Scrum Guide never says that the increment has to be usable and valuable to every single stakeholder. As long as the team is delivering an incremental step in the pursuit of the Product Goal then I see no reason that an increment usable by developers to proceed to the next step of an evolution is wrong.