Comment (0)

"I see a lot of nuances in how people interpret Scrum."

Today I’m going to talk about my interpretation of Scrum and the roles, events, artifacts, and rules that sit within it. I have worked with many different Scrum Teams from all kinds of different companies, so my interpretation is based on credible, practical experience.

A lot of people see the Scrum Master as a servant-leader, one who coaches the Scrum Team. This is wrong. The Scrum Master is really a project manager. They help the Scrum Team create high-value products, so they should lead the team by controlling the User Story Requirements List and assigning work to the developers and even the QAs. As leader, or manager, the Scrum Master has the final say on the order of the Product Backlog.

The Product Owner (often called a Product Manager or Stakeholder Representative) is solely supposed to analyze the business and write requirements. They represent the stakeholders but in reality, their responsibility is simply to transcribe their requirements and convert them into User Stories for the Scrum Master to manage.

The Team (sometimes known as the Dev Team), consisting of developers and testers, must complete the work the Scrum Master assigns them within the two-week Sprint. The Team must work with DevOps and the SQL Team to make sure they complete every User Story by the end of those two-weeks; otherwise, the Scrum Master must lengthen the Sprint to ensure value is delivered.

…

How does that sound? Does it sound like I’ve butchered Scrum? Do you disagree with my interpretation? I think most Product Owners, Developers, Scrum Masters, and management teams out there would say my interpretation is wrong. So I ask, on what grounds is my interpretation invalid? I’m confident that a Product Owner would disagree with the idea that a Scrum Master is their manager who tells them in what order the Product Backlog should be. What is their disagreement based on?

A former manager of mine once said to me, “I see a lot of nuances in how people interpret Scrum,” but for me, to expect a potentially releasable increment from the Development Team at the end of each Sprint was unrealistic* and suggested I was “interpreting Scrum incorrectly”.

*Realistic is an organizational gravity buzzword.

But again, on what basis does this manager believe I am interpreting Scrum incorrectly? What is the baseline here? Is it organizational status quo? I use the Scrum Guide as my baseline.

Where Scrum is applied based on multiple interpretations, transparency over the ways in which a team works is severely impacted. This eventually became evident for my manager which is why he later said, “I think it’s important that everybody agrees on what the rules (of Scrum) are and abides by them.” It is, of course, why an organization hires a Scrum Master in the first place.

So if agreement and understanding of the rules are beneficial to the successful implementation of Scrum, let’s use the Scrum Guide. Let’s objectively use the document that was purposely written to provide transparency over the roles, events, artifacts, and rules that sit within the Scrum framework. Why allow for different "nuances in how people interpret Scrum" at all?

Some well-known, additional reading on this:

• https://www.scrum.org/resources/what-scrumbut

• https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/

Comment (0)