Roots of Scrum: Object Technology

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.

Inheritance
It is easy to extend the Scrum pattern to fit the local environment without modifying the metaClass represented by the Scrum organizational pattern.

Polymorphism
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 tream to another Scrum of Scrums. Using an object-oriented network to scale allows potentially unlimited scaling.

Emergent Design
A small change can have a ripple effect that causes refactoring and a new design emerges.

Messaging
OO is a messaging environment. Constant high bandwidth communication works best.

Self-Organization
There is typically no "control" object. Behavior emerges from the interaction between objects in languages and between people in Scrums.

Aggregation
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.

Reflection
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.