The Steps to Becoming a Scrum PhD

Almost two years ago, I received from a friend and mentor tips on how to be a high-performance Scrum Master. I remember him saying: Hey Ema, why be a Scrum Master if you can be a Scrum Ph.D.?

This friend was Mike Beedle, one of 17 who signed the Agile Manifesto and passed away on March 23, 2018.

Today, organizing some photos, I found a picture of training we did together in Chicago (January 2018), CAL1 with Michael Sahota.

Certified Agile Leadership 1 - By Agilitrix - Chicago 2018.

Seeing this picture motivated me to write this article.

I would like to pay tribute to everything I have learned from Mike. So, I will share one of the most valuable mentoring I have had from him. An email that changed my life as a Scrum Master and Agile Coach. I remember him saying he had found this on the web but had no author. It was not signed. So this is the opportunity, if the author recognizes these teachings, to claim the copyright.

Why be a Scrum Master if you can be a Scrum PhD?

This was the email I have received from Mike.

"Subject: The Steps to Becoming a Scrum Ph.D.

Hey Ema,

Sorry for the delay in answering you. Since our last conversation, I've had a busy schedule. I hope all is well there in Brazil. Why be a Scrum Master if you can be a Scrum Ph.D.? To become a Scrum Ph.D. you need in every situation to ask the following question: How can I help? So, look at these steps below. Make these statements and try to answer these questions, can guide you. I found this on the web some time ago. Unfortunately, I don't know who wrote it.

HOW CAN I HELP my Product Owner?

Scrum Masters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog and release plan.

• Is the Product Backlog prioritized according to his latest thinking?
• Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the backlog is emergent.
• Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It’s counterproductive to over analyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
• Is the backlog an information radiator, immediately visible to all stakeholders?
• Have I helped my Product Owner in organizing backlog items into appropriate releases or priority groups?

HOW CAN I HELP my Team?

• Is the team in the state of flow? Some characteristics of this state:

1. Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with one’s skill set and abilities).
2. Concentration and focus, a high degree of concentration on a limited field of attention.
3. A loss of the feeling of self-consciousness, the merging of action and awareness.
4. Direct and immediate feedback (successes and failures in the course of the activity are apparent so that behavior can be adjusted as needed).
5. The balance between ability level and challenge (the activity is neither too easy nor too difficult).
6. A sense of personal control over the situation or activity.
7. The activity is intrinsically rewarding, so there is an effortlessness of action.

• Do team members seem to like each other, goof off together, and celebrate each other’s success?
• Do team members hold each other accountable to high standards, and challenge each other to grow?
• Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable?
• Has the team kept the focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the Product Backlog Items committed for this Sprint.
• Is the team’s task board up to date?
• Are the team self-management artifacts visible to the team, convenient for the team to use?
• Do team members volunteer for tasks?
• Do team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?

HOW CAN I HELP the Organization?

• Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and rarely the best.
• Are teams independently able to produce working features?
• Are you helping the Project Manager?
• Are you creating a learning organization?

So Ema, this is it for now. Any questions, let me know. When possible I will answer. Keep doing the good job you are doing.

Best,

Mike"

I hope these tips help the Agile community as it helped me. In Memoriam Mike Beedle, which even far from here, keeps inspiring us.