Scrum Patterns - Not Just About Sucking a Little Less by James Coplien

In some sense, Scrum is simple with only eleven main components, but its rollout and operation are intricately complex. Even with its broad certification base and online standard, it is difficult for people to appreciate its complex subtleties from a 16-page guide and a two-day course. We all assumed that the deviation from good practice was small or innocuous until we started taking stock about ten years ago. We discovered just how worried we should be. Folks don’t understand or even know how the parts work together. We sometimes see only 20% improvements if that. Even the parts themselves, people retrofit to their old mental models and complain when it gets hard to pedal the motorcycle.
The Scrum Patterns are the new defacto Scrum standard with input from Scrum’s inventor and nineteen others among the world’s top Scrum experience tier. Collected, researched, and refined over nine years, and ranked #1 among the top 45 new Scrum books of 2019 by BookAuthority, these patterns guide practitioners into an agile rollout of Scrum, one pattern at a time with feedback. Each pattern takes the reader on an internal journey through those management and development instincts with which they were born and which Scrum encodes. And if the two are in conflict, we certainly defer to the individuals and interactions behind such sentiments rather than the process specs in patterns-cum-tools.
This evening’s talk aspires to raise the bar about what Scrum is and can be, and to paint a path to better understanding both the parts of Scrum and Scrum as a whole, so you can better inspect and adapt your process going forward.

[@ChrisAthanas]

Great talk

[@randall.chamberlain]

If you get beyond the repeated references to absolutes (don't do this ever, always, always do this other thing) I still think the talk achieves the goal of defining scrum clearly.
But I wouldn't follow the advises blindly. It is absolutes which in the end pulls us back. Agile is about doing what makes sense, not about doing scrum.

[@SaudBako]

James should focus less on loud commands and more on real use-cases and empirical evidence.
Less blatant drilling, more skeptic persuasion.