I'd like to write about my experience about Scrum and some recent insights into it. A few years ago I first discovered Scrum and was keen to use it in my daily practice. I started from scratch and my initiative was well received by the management.
I became a scrum master in the company I was working for. Almost all the rituals and artifacts were adapted with ease - like daily standups, sprints, burndown charts and more. We even started using planning poker in our estimations. I remember how hard it was to explain(for myself too) why we should use abstract points instead of hours. There were four development teams in the company and Scrum was accepted by all of them.
But not all was so great. There were a few drawbacks and imperfections in our processes. I will analyze them or do retrospective a little bit later.
Time passed and I moved to a few other companies - one of them was a tiny startup and the other was the largest Russian private bank. In both places Scrum was adopted in different ways. Anyway I've got a lot more information and experience and I am able to compare.
The most important thing in Scrum, in my opinion, is the demo at the end of the sprint. If you don't have demos then it's not really Scrum - it is the imitation. Why is the demo so important - it's because the team delivers business value repeatedly and as fast as possible. So the demo is a kind of evidence that the main aim of Scrum has been performed. The team needs to prove that they have done something. Without public demonstrations it's quite vague. You can read more about the importance of demos somewhere else in more details. Let's go on.
The other point that matters is having an independent scrum master in the team. It's fun when the role of scrum master is played by other members. If it's played by a developer then the backlog will contain a lot of technical tasks, refactorings, test covering and other stuff that technical people like and consider important. Of course, they are important but it has to be in balance with other types of tasks. If scrum master is played by product owner then the backlog is full of business features. The problem is that the technical debt will grow. So that's why in classical Scrum there is such a role as Scrum master - the guy who supervises the process.
Another role that is musthave in the team is Product owner. Without him the team starts skidding and doing unimportant things. Also the team is not protected from stakeholders wishes.
The last thing I'd like to mention is grooming. When I tried to be a scrum master we were estimating user stories in the planning meeting and that was so time-consuming and energy zapping that everybody hated these meetings and tried to avoid them. Another drawback of lack of grooming is that you cannot predict how much time it will take to complete the project because you don't have an estimated backlog. So the aim of grooming is to divide estimations, make an estimated and prioritised backlog - so the planning meetings become shorter.