When to Follow or Trim Scrum: Guard, Break, and Depart

During a recent Product Owner training in New York, the speaker observed that many teams trim Scrum ceremonies, believing Agile is flexible, but the speaker questions when to follow the framework strictly versus when to adapt.

Common complaints from teams include skipping retrospectives when busy, conflating planning meetings with task allocation, using person‑days instead of story points, and PMs assigning work directly.

The speaker likens this to buying a bicycle and then replacing its wheels with squares, which makes it slower; similarly, cutting Scrum removes essential parts of the tool.

Additional issues include a PO demanding extra work after a sprint, PMs assigning tasks in planning, and overly long daily stand‑ups.

The advice is summarized as “Guard, Break, Depart”: first guard the Scrum process by following the guidebook faithfully, then once proficient, experiment with modifications, and finally, when you become a “bike‑repair master”, decide whether to keep or discard changes.

A practical recommendation is to set a 100‑hour practice goal, during which teams should strive to execute Scrum as intended, reducing the cost of retrospectives rather than eliminating them, encouraging PMs to stop assigning work directly, and keeping stand‑ups short (e.g., 15 minutes for 20 sessions).

After the 100‑hour period, teams can make informed decisions about trimming Scrum; the journey also expands perspective even if Scrum never fully fits.

Finally, the speaker emphasizes that mastering Scrum is like learning to ride a bike: you must first learn the basics before you can teach or repair it, and only after sufficient practice should you consider major changes.