Skip to main content

Scrum Master's challenges as a coach while also a member of Scrum Development Team

May 10, 2019

Thanks in advance for reading. I believe you will find this post helpful if you're a Scrum Master and also a Development Team member.

This is not first post around the challenges when same person is who is taking Scrum Master role is also a member of Scrum Development Team. At the bottom of this post, I have added links to the interesting conversations I found.

One of the biggest conflict of interest I've experienced is in empowering team to self-organize in their own way. From the Scrum Guide: 

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Development Team part of myself then says, hang-on.. Scrum Guide:

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

So in my role as a Development Team member, I am empowered and required to contribute to the self-organization. But as a Scrum Master, I can't tell how to perform certain work and my goal is to coach the Development Team so it is self-sufficient in self-organization and ask for help when needed. 

To give some specific examples:

  • Giving opinion on architecture decisions as a practitioner deciding which framework to use for testing. 
  • During Sprint Planning, giving opinion how much of the Product Backlog we can include in the forecast. 
  • Best practices on writing manual test cases. 

And I can go on and on... :-) 

As a coach, I should let the Development Team members figure it out themselves and decide what is best course of action (well, that is self-organization, right?) but as that team member myself, I am obligated to add my opinion as a Professional Scrum Developer. 

So... what do I do? Here is my guiding principles:

  • Stick to Professional Scrum. Live Scrum Values to create high trust work environment. 
  • Be transparent in conversations. Say, "as your Scrum Master here is my advise..." and then later on.. "as a Development Team member I think we should... "
  • Think about "Scrum-and"s and not "Scrum-but"s to set the right mindset. We are using Scrum, and... we do .... 
  • Always keep Sprint Goal and product users in mind. Users do not care how you work as Scrum Team. Speaking of which, as Development Team self-organizes, roles of Scrum Team also self-organizes and finds out how best to accomplish their work. Scrum Team's overarching goals are to deliver value with quality to the users or the product being developed. 
  • Scrum is NOT a destination. It is a journey. We use Scrum to achieve business agility and take competitive advantage. 

And I can go on and on here as well :-) Instead, I encourage you to read and contribute based on your own experience.  I'd love to hear from your in form or reply to my post or the posts below.

Thank you for reading. I hope you found this post helpful. 

What did you think about this post?