Howard van Rooijen recently posted about a thread on the Scrum users group. In the thread by Ken Schwaber explains that:
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
Ken’s whole point is Scrum is designed to be a lightweight, barely there process. Trying to elaborate on it and define different styles sort of misses the point. Keep the process as simple as possible and let people figure out how to adapt it to their teams and organizations.
I think my greatest realizations of Scrum have been its ability to reveal organizational problems and bring them up into the light. Now, we haven’t been able to change all of them for the better, but we have been able to adapt.
We’re working through an organizational impediment on one of our Scrum projects. The developers on a project are being blocked from completing their tasks by lack of access to a development server. A policy exists that gives only one or two people in the organization access to make changes on the development server. Scrum has made this inefficiency readily apparent in short order. I expect tomorrow we’ll have worked out some form of solution.
Despite being an incredibly simple process that Mike Cohn can describe in a small diagram, Scrum is full of nuances. We’re constantly inspecting and adapting how we do things in Scrum and I don’t want to get caught up in which form of Scrum we’re using.