Opinion: What does a good Scrum team look like?

Scrum and Agile have become popular buzzwords in technology teams, but often we can't be really sure if we're truly a Scrum team. I've put together some of my thoughts as to what makes an ideal Scrum team, and I would love to hear your thoughts too in comments please.

1. Communication: Constant communication is the key, the team is constantly talking to each other and does not wait for the daily standup call. Standup calls are important for status updates, but regular daily conversations are the foundations of the scrum meeting. When you communicate more often then you will need lesser meetings, you will have lesser blockers and you will get the work done much quickly. Have a question, ask it right way, don't wait for the standup call.
2. Collaboration: Each team member collaborates with each others all the time, they work closely with the QA/UAT team members, they answer questions and help each other out when there is a blocker. Each team member tries to help to remove any blocker another team member may have. Love and respect is important for any team, but true collaboration is the foundation of a super scrum team.
3. Self-organizing: There are no bosses in a Scrum team, you are responsible for your work and you need to work with the team to deliver it. No external force can micromanage your work. Also, there is no one man show here, everyone has a role to play and when each of the team members give their best, a great scrum team is born.
4. Scrum master is not the leader, but is the servant leader: If your team is really good, they don't even need a scrum master. A team where the scrum master does most of the talking is not really the best of the scrum teams. The scrum master is a servant leader, serving the team members. But if the team is super efficient, they will talk to each other to figure out blockers, and remove any impediments. The scrum master can just relax and go on a vacation then.
5. Sprint iterations: Are you creating potentially shippable components every sprint? Do you finish up all the planning, requirements gathering in the first few weeks, and spend the rest of the sprints in development and allow no room for changes in requirement? Then this isn't Scrum it's just Scrumfall. Scrum is open to changes and is totally adaptable to change in requirements, that's the beauty of scrum. This concept of being open to changes sounds wonderful in theory but I won't lie it is difficult to achieve, because change in requirements means change in scope of work, means additional work. But if this change is managed well in an organized and well communicated way then it can be a less painful and more gainful process.

Think about it and let me know your thoughts, is your team a Scrum team or a Scrumfall team? What other ideas can you think of, I'm sure you have many more, drop in your ideas in the comments please.