Scrum | Cape Project Management, Inc.

Why Scrum “Master”? What about Scrum Apprentice? Maybe we need a Scrum Jedi?

by Daniel Tousignant | Apr 7, 2014 | Agile, Jedi, Kanban, Scrum, Scrum Master, XP

I learned the term Scrum Master back at the turn of the century (I like how that sounds). I first heard it from Ken Schwaber himself. At that point in my career, I was a true and tried project manager that had recently earned his PMP. I was a self-taught project manager, and looking back, my instincts and style were better suited for Agile, but I happened to go down the formal PM path first. After 10 years of experience, I had come to the conclusion that project management was a “craft”. I believed it then and I believe it even more now, which is why I struggle with the term “Master.”

What does it take to be a "Master" of Scrum?

I was a carpenter before I was a project manager. I was the only honors student taking wood-working classes in high school and I worked as a carpenter’s apprentice during the summer while I was in college. I had tremendous respect and even awe for the master craftsmen I worked with. In carpentry, the term Master is reserved for the likes of Norm Abram. Also, to be a union carpenter, you have to go through a rigorous apprentice and journeyman program before you can get paid as a true master carpenter.

In history, you had to earn the term “Master” to be seen as the top of your craft. Wikipedia has a good definition:

“An aspiring master would have to pass through the career chain from apprentice to journeyman before he could be elected to become a master craftsman. He would then have to produce a sum of money and a masterpiece before he could actually join the guild. If the masterpiece was not accepted by the masters, he was not allowed to join the guild, possibly remaining a journeyman for the rest of his life.”

I think the intent with the term Scrum Master is that the title should be reserved for those that have earned the title of Master, but that is obviously not the case. There is no job requirement or career path to become a Scrum Master. Most of us have had some type of career path as we developed our skills; e.g. in software engineering, there is a typical path of analyst, developer, designer, architect or in project management: project coordinator, project manager, senior project manager, program manager.

So, how does someone earn the designation of Scrum Master? Until recently, it was just take a 2-day class. Now, at least there are exams to test your knowledge of Scrum. It is surprising how we have come to a place where the term Master can be designated without any true effort or experience. Most of us have had to show both experience and knowledge to get the certifications we have. PMI, for example, requires the PMP and the PMI-ACP designation be based both upon experience and knowledge.
I am not sure if there is a way to backpedal to introduce qualifications for Scrum Master, so maybe we need a new term that actually requires that someone has proven themselves. How about Scrum Jedi? Just a thought… All I ask is that I get credit for the term when it goes viral…

Dan Tousignant, (long list of acronyms usually goes here, some hard earned, others...)

@ScrumDan

BE AGILE.®

The Agile Success Algorithm

by Daniel Tousignant | Mar 26, 2014 | Agile, Kanban, Scrum, XP

al·go·rithm

algəˌriT͟Həm/

noun
1. a process or set of rules to be followed in calculations or other problem-solving operations
Those of you reading this are more than familiar that Agile is all the rage. Executives like to say that their organization is going "Agile". They throw out terms like Scrum and Kanban without truly understanding what they are getting involved in.
In order for Agile to be implemented successfully, I have created the following simple algorithm. Embrace Change + Learn from Mistakes = Agile Implementation Success.

Input 1 = Embrace Change

The primary risk with implementing Agile involves the ability your organization to embrace change. You need to answer the following questions about your organization's culture and your leadership team before you can successfully implement Agile:
How does your organization respond to change?

When was the last time your organization underwent any major changes?
Have they been through major layoffs? Have they introduced new leadership?
How long have they been in business? Have there been major new product introductions?
Have they been acquired or merged?

How did these changes go? In this case, past performance often dictates future performance. If your company struggles with change, then they will have trouble introducing Agile. Agile introduces change in so many ways:

Changes in roles, title and responsibilities. Just look at the roles in Scrum, since it is currently the most popular Agile method being implemented. How easy is it for your organization to adopt these roles?
- A Scrum Master? How many managers or project managers do you know who truly understand the concept of servant leadership? How many organizations allow for management positions that do not have direct reports? To truly be successful with Scrum, a Scrum Master role has to be created from scratch, not just assigned to an existing function.
- A Product Owner?? Organizations that have a mature product manager function can transition easily to this, but many organizations manage product related decisions by committee with a team of business analysts. The role of a truly empowered Product Owner is difficult for many companies to swallow.
- A Scrum Team??? A self-organizing team is the foundation of Scrum and of Agile in general. How many organizations actually foster this? How many middle manager's jobs would be eliminated if an organization becomes successful with this? How many under performers would be exposed in this model? This is the most difficult, yet most critical change required.
Changes to process.
- No analysis or business requirements phase? No Gantt charts? No 12 month project plan? Traditional project management was just formalized at many organization in the last decade. Formal PMOs have been rolled out, massive enterprise tracking tools implemented and teams of project managers hired to create and maintain documentation. Can your organization tolerate getting rid of all the processes you just implemented?

Input 2 = Learn from Mistakes

Only a company or leadership team that has experienced project failures can truly appreciate and support an Agile implementation. These failures may have come in many different ways:

The project came in too late to meet the market opportunity.
The budget changes were so excessive that the project was either terminated or deemed a total failure.
The customer rejected the product because it was "not what they were expecting."

The list goes on and on....The Agile Manifesto was not crafted by grad students developing a thesis. It was developed by people who were clear that the way we were working wasn't working. Many people, like myself, have become Agile evangelists only after suffering through one or more of the above project failures over which we had no control. One of the major downsides with introducing Agile to the "younger" workforce is that they don't truly appreciate how much more fun and enjoyable it is to work on an Agile project. Give them one month of using project time-sheets and hourly tracking in an ERP tool and they will start to see the light.

Output = Agile Implementation Success!

The benefits of Agile are self-evident for those who have lived through traditional project failures and are willing to change. There are hundreds of successful case studies and stories of successful Agile implementation, but implementation failures are becoming more and more common. Becoming "Agile" is not just using the term "Agile", it is a transformation that will effect your entire organization.

Dan Tousignant, PMI-ACP, PMP, PSM, CSPO, CSP
@scrumdan