One of the roles of a Scrum Master is to improve the effectiveness of the Product Owner by helping him manage the Product Backlog, design and communicate the Product Goal, and facilitate his ability to maximize the resulting value of the team.

It is much more fun to think about the ways in which a Scrum Master can contribute decisively to your distress and failure. To participate in this game you must have a clear rule, illegal activities such as slashing the wheels of the car are forbidden. Only actions that do not contravene the culture and values of a typical average company are allowed.

 

 

Manipulating the essence of Scrum

This is the most obvious one, just discredit the framework as a process of transparency, inspection and adaptation. 

  • Promote that stake holders can include new tasks in the backlog without talking to the Product Owner.
  • Indicate to the Product Owner that he must establish commitments, milestones, dependencies and dedication percentages.
  • Promote isolation between the team and architecture, quality and security areas, without any direct participation or representation in the team.
  • Organize important meetings with stake holders in parallel with Scrum meetings.
  • Prevent the Product Owner from being able to interact directly with developers.

 

Teamwork

How about creating the most dysfunctional Scrum team possible? A collection of individuals comparable to the unlikely heroes of the movie “The Dirty Dozen”.

  • As a Scrum Master, promote invasive micromanagement of the teams.
  • Hold two review models, first the one that would be held only with the developers, then another one with the Product Owner, where you make sure that the message they receive is as cooked as possible.
  • Support that access to resources and tools is a process of disheartening bureaucracy.
  • Discourage teamwork and cooperation.
  • Force the team to thoroughly estimate each task in hours and criticize their lack of results.
  • Never give, ask for or encourage feedback in the team.
  • Every request for information, coordination or help from the Product Owner must be preceded by a meeting.
  • Prevent the team from talking to stake holders directly.

 

 

Metrics

Make them as arbitrary as possible and force the team to become scribes whose sole purpose is to fill out long, meaningless reports.

  • The team must engage in useless report writing and filling out information in triplicate.
  • Promote fancy metrics without team consensus. And change them often.
  • Measure for the sake of measuring, with no intention of advancing anything sensible.
  • Demand progress information, but disregard what they tell you.

Backlog management

All sabotage is based on deception, that the backlog is a riddle, wrapped in a mystery, inside an enigma, to paraphrase W. Churchill.

  • Facilitate contradictory methods of prioritizing the backlog.
  • Insist on the need to be present at every refinement, but introduce yourself only if you are not talking on the sly with stake holders.
  • Introduce new elements into the backlog on your own.
  • Try to encourage the inclusion of items in the sprint backlog that do not contribute to the Sprint Goal.
  • Demand a ticketing tool to report bugs, with the consequent reports.

Conclusion

It is not difficult to sabotage the work of a Product Owner because, often, organizations allow behaviors such as those described and discourage a work process in Agile, so that these practices could, beyond irony, be executed without consequences. In fact, they are almost natural tendencies, so it is necessary to make an effort to go against the flow when the simple and accepted thing to do is, precisely, to let oneself be carried along by it.

The typical company is an organism adapted to these behaviors with silos, bureaucracy, distrust and hierarchy. A Product Owner, when he is one, must often combine his work with the partial dedication to a conventional project management, with traditional reporting and upward communication that hinders the decision-making capacity and his ownership of the product that, with his role, he should have, while maximizing the value of the work that is delivered thanks to an open and loyal relationship with the Scrum Master.

Author

  • Scrum Master en Keepler. “Working with people to build products that solve problems. Digital transformation is the new industrial revolution based on the fractal creation of team-based development systems. I collaborate with companies to understand problems and develop solution strategies.”