After moving into Bell Labs Research I became one of the founders of the Software Pattern Discipline and pioneered the use of organizational patterns. That work is broadly acknowledged as one of the foundations of Scrum and was also a foundation of XP.
There are three factors that make the Scrum Patterns special.
1. They adopt a systems thinking view of organizational transformation, rather than a rulebook approach. This means that we can get beyond technique to organizational structure and to principles and values, and really address the human issues that make complex development so hard. Patterns help us think in systems ways that are more or less the opposite of “root cause analysis.”
2. The Scrum Patterns are shaped by the thinking at the foundations of Scrum and written first-hand by those great thinkers: Jeff Sutherland, Michael Beedle, Gabrielle Benefield, Jens Østergaard, and more.
3. They reflect input from all the major certifying entities, and where we lack engagement with key constituencies today we are always seeking to be inclusive with more folks.
However, the inventor of patterns, Christopher Alexander, insists that this is an essential property of patterns. They compose with each other to create “morphological wholes.” These Wholes are teams, value streams, relationships, cycles in time, and other structures in the development organization.
Most engineering students think in terms of short time frames; a good mature engineer thinks ahead to how use and nature will cause a structure to weaken or become obsolete. Patterns attack that kind of entropy. Engineers building Japanese temples today plant trees that will be used to build their successors 200 years from now; patterns in construction lay a foundation for a good future by understanding the past.
In the far distant future I feel that much software development must give way to a swarm model and to something that looks more like open source, where we can leverage the commodity products (UNIX, C) of the current age to again return to systems dynamics. If we can find our way to such a landscape, we will have jumped over today’s uncomfortable and unholy marriage of high individualism and low-context development cultures.
I urge students to invest in learning about Japanese manufacturing in general and about TPS in particular. I think that one cannot explore the high-payoff parts of this world without making a large investment in understanding the culture in which it grew, and the roots of that culture. This is going to sound strange but students will appreciate it 50 years from now: Study the Japanese language and culture; study Buddhism and Japanese history.
The problem in software, I think, is that it’s dominated by nerds. Too many nerds find the locus of their pride in the details rather than in the big picture. That’s in part because nerds value intelligence over hard work. (Tell a nerd that he’s lazy and he’ll be a little bit put off; tell him or her that he’s not smart enough to solve a problem and you’ll cut him or her to the core.) It becomes crucial to demonstrate intelligence in the work place: salaries, promotions, and stature depend on it. The intelligence often goes hand-in-hand with a predisposition for intellectualism over feeling. This is a set-up for specialization. Specialization is less important in a highly connected world than it was in the industrial world; if I need to find out how to do X, I can often find the answer on the web instead of investing the time in an institution that “teaches me how to do X.”
It’s in fact hard to build a community of people both able and willing to build a body of literature that has value, that is generally applicable, and that is driven by socially-minded contributors. Nerds rarely find the energy for such work.
The organizational patterns are the other example of success. They’ve shown high value (in limited use) in their own right, but have also evolved into one of the most powerful engines of change that we have in contemporary software: Scrum. (Note that patterns merely capture mature practice rather than invent it, so it’s silly to say that the pattern people invented Scrum. It’s probably also silly to say that the Scrum people “invented” Scrum, but I’ll leave that question to them.) What both organizational patterns and Scrum did was to combine, rationalize, and publicize timeless ideas of how people are effective in the world of work.
Building great things and doing great things is much more about understanding agile and patterns than about understanding academic foundations. Understanding agile, or understanding patterns, has much more to do with falling in love, or with building something you find that gives you inner calm, than it is about anything you’ll ever find in a book, hear in a lecture, or learn from reading an interview.
Interview with Jim Coplien @ javiergarzas.com
Overview
Report
Wiki