In the last year there has been lots of talk about Type A, B and C Scrum (well, really types of Sprints, in type A the Sprints are isolated cycles, in type B Sprints are overlapping cycles and in type C Sprints happpen all at once) – when I first read the “Future of Scrum” paper – I couldn’t quite understand why the paper had been given that title – as it seemed to me that Jeff Sutherland was really talking about a particular project using Scrum that had evolved (through the inspect and adjust nature of Scrum) into a highly optimised process for that team, for that project, for that environment – I didn’t see it as a Scrum Design Pattern or a template that could be replicated elsewhere.
Today a fascinating thread has started over at the Scrum Development Group; Ken Schwaber has posted a message which essentially disregards the different types of Scrum (although he congratulates Jeff on a successful implementation of Scrum at PatientKeeper) and states that Scrum practitioners should concentrate on applying the process correctly and evolving it within their organisation rather than concentrating on trying to work out how to scale-up the process:
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