Saturday, September 27, 2008

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.

4 comments:

Tobias said...

Jeff, this is an excellent article, and thank you for gathering these thoughts together in such a succinct and powerful way.

It has always seemed a great shame to me that those on the business/product management side of a software organization have not studied OO design principles. This ignorance of something so essential to modern systems thinking leaves a gaping hole in an organization's ability to truly embrace Scrum.

I hope this article will trigger off further discussion in the Scrum community about the essence of OO and Scrum, and the symbiotic relationship between the two. I hope it will encourage non-developers to study OO design.

Boris Gloger said...

Jeff, I am very happy that you posted this article. We need to get this thought out to the Scrum Community.

Mike Cohn said...

Excellent, Jeff. I think this is a great way to think about the principles that underlay Scrum.

Josh Gough said...

Jeff, this is very interesting. I started thinking about how the simple "rules" of Scrum reminded me of both abstraction and encapsulation during the training in Atlanta. I mentioned something at dinner about wanting to find a way to "visualize" software, and this helps me think in that direction.

First: Abstraction
All of the top-level artifacts or practices in Scrum, from the daily meeting to the sticky-notes on the walls, to the wall columns dividing work-item states of the sprint, through to the demo and retrospective serve as abstractions, or as an interface.

Next: Encapsulation
Each sprint, when inherited from the abstraction or by implementing the interface thus allows the team to implement sprint-specific details underneath the outbound communication interface.

In a word: IScrum