Suppose someone of your development team is presenting a sprint to the customer but he is having web connection problems such that a complete story cannot be presented. For the sake of the cleanness of the presentation, do you help your colleague suggesting possible solutions and try to fix it in the moment? Or is it kind of messy?
May be the customer (who is "part" of the team) will understand? Why?
If the presentation is important for you you should do whatever possible to be prepared for extreme situations. What you can do?
Even in such case the presentation sometimes goes wrong. You cannot fight yourselves quality of your infrastructure and tools available to show customer result of your work. If such problems are regular your Scrum master should escalate them and they should be solved by management (increasing quality of infrastructure, providing better mobile internet connection or whatever else).
If the problem happens rarely customer will most probably understand (unless relations with customer are already in bad condition). It will result in postponing the meeting or replanning the meeting to another day (as soon as possible). This is bad but it is not as bad as skipping the whole meeting. If this happens often customer will not be so kind and it will negatively affect your partnership.
If the problem is in device configuration you should solve this before customer even comes. Messing with computer and trying to connect to your VPN while customer is already on the meeting doesn't look good.
May be the client (who is "part" of the team) will understand?
Client is usually not part of the team. Even product owner is usually not considered as a part of the team and sprint review is not (should not be) for product owner. Product owner should participate with team during whole sprint so she should already know what has been done. Moreover she should be the one who say that feature / user story is done and can be presented on sprint review. Sprint review is for customer representatives, stakeholders / managers and perhaps also for selected end users, etc.
No, I wouldn't try to fix it in the moment as a general rule. I'd rather schedule a follow-up meeting and between then and now figure out how to fix what went wrong. Something to consider is how well do you want your customer seeing what it looks like for a pair of you to struggle here. Depending on how formal and professional the presentation is, I could see some rare cases where I'd work around it though those are where I'm working with people where 99% of us would agree to try to get to the good part quickly and that we have enough knowledge and control over the issue that it could be resolved in 5 minutes or less.
While the customer may say they understand, I'd wonder what kind of reputation are you creating here. Do you want to have that kind of reputation where things go wrong and you have to rush and fix it during the presentation time? What someone says can be quite different from what he or she thinks.
Since you're using Scrum, by Sprint Presentation, are you talking about the Sprint Review? All members of The Team plus the PO and ScrumMaster are part of the Sprint Review, so you could and should step up and help with his part of the review - plus present your participation in the Sprint.
When you say the client is "part of the team" - is he actually doing development as part of the team, or is he the Product Owner?
If you and the customer(your teacher) are at the Sprint review meeting and you are demonstrating the working product but the product cannot be shown to work then it's not done.
Having said that, if the product owner (your teacher?) and developers have been working as "part of team" then they probably already know that it's working and may even have tried the functionality themselves. In that situation, the product owner could decide that the story is done.
So, I would say that if everyone "really" is working together, skip the demo (your presentation). If the demonstration is what determines done or not then you need to balance the cost of keeping the team longer at the meeting or moving the story to another sprint.
