I have to admit that I only read briefly about the innovations Jeff Sutherland has been making on evolving Scrum, and I think it's because I dismissed it for “smelling” like over-engineering Scrum's simplicity.

Seems I wasn't far off the mark as this post by Howard van Rooijen describes Ken Schwaber's reaction in the Scrum Development Yahoo! discussion group.  I have to capture this here for posterity as it encapsulates my reservations about misinterpreting the results of  Scrum's inspect and adapt process as evolved Scrum best practices.  In a short sentence, it isn't, was or ever will be Scrum. 

Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results.

Scrum is not the organization that produces the results, or the amalgam of procedures, tools, automation, and standards that are implemented as a result of the inspection, as part of the adaptation. Scrum is the very simple mechanism that helps an organization be more effective in accomplishing its goals.

I've been following the threads about type N, A, B, C and advanced Scrum. Although these may represent the engineering, personnel, and product management practices that an organization adopts as a result of Scrum's inspect and adapt, they aren't Scrum. I think we are mistaking the consequences of Scrum with Scrum itself.

What may be most destructive about these supposed extensions is that they will divert people from the real work of Scrum ... seeing what is going on in their organization and going through the change process to become effective. And learning how to continually inspect and adapt to keep their organization's practices optimal. Instead, people may think that all of these things that use the Scrum name are advances in Scrum, templates that they can mimic and then, amazingly, they are advanced development organizations, also.

We are running the danger of any small process. People want to make it bigger. Well, Scrum isn't bigger. Each organization's total ability to build complex products is certainly bigger, and hopefully continually evolving, but it isn't Scrum.

Keep Scrum Simple.
Ken