A few years ago I was very excited at the possibility of becoming a Scrum master.  At the time I had been an avid XP practitioner for a little over two years.  I had read several books on the Scrum but viewed it as simply Yet Another Agile Methodology (YAAM) with a focus more on the project management.  I thought to myself that I must have been missing something.  How can something as simple as this methodology be taking off like wild fire in the corporate arena?  I figured that a Scrum Master class would shed light on this dilemma of mine.

Day 1 of Scrum Master training, typical PowerPoint presentation with lots of slides telling you how great Scrum is and different scenarios where Scrum has been applied. Still no epiphany.  The day goes on and we get to do hands on Sprint planning meetings, we emphasize the importance of the Daily Scrum. OK been there already, understand the importance feedback, still nothing ground breaking. Next we talk about value stream prioritization from the perspective of the Product Owner.  People are asking lots of questions on what do you do…etc.  Lots of dialog but still nothing earth shattering.  Next we discuss organic team composition, something that is near and dear to my heart but we spend around 20 minutes on this topic basically saying let the team self organize to gain the greatest value. On to retrospectives, very enlightening, nothing really new, there isn’t one way to do a retrospective, several books are recommended.  And this is the end of Day 1.

Day 2 we actually go though an entire mock release.  We form up into 5 person teams. Each of us assumes various roles such as Product Owner, Scrum Master, and the development team.  We go through the Sprint Planning session and prioritize a backlog with the product owner learning several techniques on how to gain insight into how the backlog is being prioritized. Now we start our first development cycle that is time boxed to 5 minutes. Team self organizes and pulls stories from the backlog to work on.  At the end of 5 minutes we do our daily Scrum.  We talk about what we did, what we are going to do and are there any impediments in our way. We go through several cycles with some of them trying to be sabotaged by the instructors with various impediments that the team manages to overcome. At the end of the Sprint we demonstrate the final product to the Product Owner (in this case it was a magazine) they make suggestions and reprioritize the backlog.  We then hold a Sprint retrospective and talk about what worked, what didn’t work, and where we could improve. On to the next sprint to start the whole process again.

At the end of Day 2 we had a feedback session about how the class went.  We talked about what we learned and ways on which to improve the class.  For me it was nothing more of a confirmation of what I had already been practicing but there was something that was missing, more on that later.

Now the scary part! Towards the end of the class we signed several sheets of paper and 30 minutes later I was awarded the title of, “Scrum Master”! What I didn’t tell you is that the class was filled with individuals with out any software development background.  Here is a list of some of the titles that where in the meeting.  Vice Presidents, CIO’s, Project Managers, Product Mangers, Developers and a Financial Analyst.  All of these individuals could now place, the title of Certified Scrum Master on their resume and wreak havoc to any organization that would give them the power.

It is not that I have a problem with Scrum so much as it is I have a problem with title, “Scrum Master”. The word “master” implies that this person has attained a level of mastery of everything related to scrum though experience, experimentation and trial.  I would have preferred the term “Scrum Apprentice” to “Scrum Master”.

Scrum is very instrumental at getting an organization to adopt Agile.  I have a post about this calling out that, “Scrum is the gateway drug to Agile”.  If you choose to adopt Scrum your organization you will gain greater insight into its culture.  This insight is not always welcomed as it will expose many of your organization process and personnel related issues.  How you choose to deal with these issues will determine how successful your project will be.

Personally speaking Scrum cannot be practiced on its own.  Scrum lacks software engineering disciplines and practices, this is where XP excels.  By combining both methodologies into one ecosystem you have a very powerful foundation to build on.

If you do decide to go down this path make sure to ask for the Scum Masters list of impediments and how they overcame them.  Also ask about what they have learned from their mistakes.  This will give you an idea on the level of experience the individual has running Scrum Projects.