Scrum Master as Coach

As her service, the Scrum Master coaches the development Team, the Product Owner, and the Organization to benefit from Scrum and improve its product discovery, development, and delivery efficacy. In this article, I’ll discuss the areas in which the Scrum Master coaches these roles in helping deliver better value to the customers, improve the ROI and develop adaptability within the organization.

Coach the Development Team

Here are few areas the Scrum Master can coach the development team:

Self-Organization:

The Scrum Master coaches the development team and the organization to transition from top-down, externally managed to a self-organizing team. Scrum Master helps develop this vision within the team and provides a structure within which the team members can try smaller experiments to move towards self-organization.

Cross-Functionality:

The Scrum Master coaches the Development Team members to acquire additional, cross-functional skills. The team members move towards becoming T-Shaped cross-functionally skilled members.

Foresee and Remove Impediments:

Coach the Product Owner

The Scrum Master coaches the Product Owner in following areas

To improve Product Backlog Management efficacy:

To understand empirical way of Product Planning:

To order the PB to maximize business value:

To understand and practice agility: The Scrum Master coaches the Product Owner to internalize the concept of agility and what being adaptable means. The Scrum Master holds the Product Owner accountable to identify market changes and adjusting direction to minimize risk and maximize ROI.

The Scrum Master coaches the Product Owner to internalize the concept of agility and what being adaptable means. The Scrum Master holds the Product Owner accountable to identify market changes and adjusting direction to minimize risk and maximize ROI.
To experiment small and adapt: One of the common dysfunctions I’ve witnessed with the Product Owners is the false

One of the common dysfunctions I’ve witnessed with the Product Owners is the false certainty they bring to the development teams in the form of requirements. Most Product Owners live in the assumptive world that when my team builds it, we launch it, the customer will pay for it. Absolutely naive. We know from real world data that most product failures are due to the gap in the product-market fit, not due to the incorrect use of technology or buggy code. It’s essential for the Product Owners to distinguish between the user asked requirements and the hypothesis. The Product owner who realizes that many of these are hypothesis, it doesn’t take them much time to start thinking of testing the hypothesis and making them small. A Smaller hypothesis is easy to implement, test and verify. It require less effort, time and cost less, hence minimizes the risk.