Why you should not do analogies with the Scrum roles
When you are explaining Scrum or teaching people about it, it tends to appear in the group the tendency to establish similarities with other roles, positions or responsibilities they already know.
«Then you mean the Scrum Master is like a Project Manager, just that she …» or things like «Then the Development Team are the programmers who…» or «And the Product Owner is like the boss of the project but …» for me the answer to all those questions is a clear no.
I know that this implies that I will find myself in the need of having to invest more time and effort on explanations, but I think it is the best way to be sure that this is understood correctly from the first moment.
Adopting Scrum (and generally with Agile) implies mental changes, paradigm changes and organizational changes. I think it is better to help people make the exercise of building a new mental schema. Without the effort of understanding roles, responsibilities and all that those imply, everything will remain as a half-made work. We should not stay just in the lazy position to just feel comfortable giving a short explanation. Changing requires effort.
The real situation on the current working and social world is really constantly changing. What I try to do is helping people do a real adaptation instead of just masking old patterns. Use the changing environment itself to promote the evolution. At the end we know change is the only constant. Rigid concepts and structures can only change towards something more agile if we understand that the new roles have their own definition, purpose and meaning and they are not just adaptations of the old traditional scheme.