In several posts I tried to say that Scrums roots are not in the lean manufacturing debate but in knowledge management. Jeff Sutherland re-posted today a comment he made a couple of years ago on this blog. Roots of Scrum: Object Technology.
I re-post this article here:
Scrum was originally designed to support emerging object technology environments, which have now become the dominant paradigm in software development. One of the goals was to get the organization of the team to reflect the potential flexibility of the software since software rigidity always reflects the organization that built it. This is Conway’s Law. Fred Brooks cited Mel Conway’s 1968 Datamation paper in The Mythical Man-Month and the name stuck. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Object-oriented languages have a small set of interoperating principles. Break any one of them in creating a language and many of the benefits of object technology evaporate. A similar analogy could be made about Scrum. So here is a candidate set of principles.
It is easy to extend the Scrum pattern to fit the local environment without modifying the metaClass represented by the Scrum organizational pattern.
The same message sent to a different Sprint can produce a result dependent on the environment.
Encapsulation (information hiding)
Work is packaged in increments. Scrum teams can scale by making a Scrum of Scrums look like a Scrum team to another Scrum of Scrums. Using an object-oriented network to scale allows potentially unlimited scaling.
A small change can have a ripple effect that causes re-factoring and a new design emerges.
OO is a messaging environment. Constant high bandwidth communication works best.
There is typically no “control” object. Behavior emerges from the interaction between objects in languages and between people in Scrums.
Objects can be aggregated into components. Components aggregate into an architecture. Scrums can be aggregated into Scrums of Scrums orchestrated by a metaScrum. A metaClass creates the framework for all classes. The Scrum framework could be viewed as a metaClass laying out the minimal attributes of a Scrum and the relationship between components.
Constant review and analysis at a meta-level leads to increased functionality and flexibility. This is an extremely powerful feature missing from some languages, which tends to cripple them. It leads to the Retrospective in Scrum.
All software implementations of objects use the metaClass of a specific language to create coherent structures. There were hundreds of people who created new objects languages and 99% of them failed in the market. These are like homegrown implementations of Agile. “We are doing Agile” has no meaning. It is like saying we are doing object technology. In the last decade we would look into the code of a C++ application and see nothing but old C procedures. There was often not a single object to be found. Today we see hierarchical organizations implementing hierarchical teams and calling it Agile. They can’t help themselves. They have to change the organization first to get it right or Conway’s Law assures that they will fail.
Certain languages are structured to work together like JRuby with Java. This is analogous to Scrum and XP. Others like Java and C++ inherit features from a common ancestor but do not interbreed well. Those that take pieces of Agile languages and cobble them together get what you would expect – a horse designed by a committee. It can’t run but maybe it can store water.
Jeff – thanks for writing this!