Making a Scrum Master redundant?

As published on LinkedIn Link

Every now and then, discussions come up as to how should one measure the efficiency of a Scrum Master? Is there a criteria based on which we can measure their performance? Does it depend on the number of impediments they help resolve? Is it related to the number of teams they are assigned to? Who or which department does a Scrum Master report too? And many more such questions. And then, an idea is usually floated that may be, a Scrum Master's ultimate goal is to make themselves redundant, a success criteria for a team. As pink as that idea sounds from a cost-saving perspective, it just doesn't ring a bell in my head. Probably, I'm not getting it, but here's my take on why a scrum master (even if possible) should not be made redundant (feel free to agree or disagree with my views in the comments below).

The Honey Bee Analogy

As published on LinkedIn Link

Although the first time I discussed this analogy was at a Meetup hosted at AllScripts Pune office, this wasn't the first time I had received an expected answer to my question. The question usually used to gauge the (unity in) diversity of the audience.

How many software developers do I have in the room?

Agile Days of Future Past

As published on Scrum Alliance Link

My current journey begins in August 1970, when Dr. Winston W. Royce presented his views on "Managing the Development of Large Software Systems" at the proceedings of IEEE WESCON. This revolutionary paper introduced software engineers like me to the world of Waterfall (or, as I like to call it, "what-the-fall"). But we usually skipped the part in our textbooks where Dr. Royce himself stated that pure Waterfall software development would never work. Dr. Royce stated that in order to eliminate most of the development risks, five additional features must be added to the basic what-the-fall approach.