What I think you’re looking for, then, is a framework for organizing the questions that need to be asked about any software development process (how is the architecture determined? How are builds managed? Who does the testing, and when?)

With that in place, you could then build an information set (a matrix, a layer cake model, a sausage… that shows which questions are addressed by which methodologies. More importantly, this could help organizations identify questions that they’ve forgotten even to ask.

Using David Spann’s example, Scrum mainly addresses questions regarding the flow of work through the organization, but it [deliberately] does not address architecture and many other important questions. An organization that adopts Scrum needs to understand which questions won’t be answered by Scrum.

Bringing this discussion full circle: If you keep the focus on the questions, rather than the answers, then you might be able to steer around the prescriptive tar pit that the OSI reference model was turned into.

Scrum, as a management methodology, is elegant in its design: offering just enough practical advice to agile teams so they do not overcomplicate the development lifecycle with too much ceremony and documentation. However, it is a management methodology, not a software development methodology; therefore, it assumes such matters as sufficient architectural design, appropriate technical environments, and protocols for development, testing, and production are in place. Similarly, it assumes someone or some group is managing the customer/product community so that the product owner can represent a unified and prioritized description of the business need.

Israel

It’s CMMI.

Before anyone boos me off the stage, I’ll admit that I’ve never actually looked at CMMI, so maybe I’m off-base here. I did have some exposure to its predecessor, CMM, well over a decade ago. I came away from that with much the same take that we’re describing re OSI: In their search for prescriptive solutions, my team had made CMM into something far more bureaucratic than it needed to be. I suspect a lot of teams did the same.

With respect to being overly prescriptive, my own sense of Agile these days is that we emphasize the practices more than the principles. I actually use the quip “Principles over Practices” whenever I start suspecting an Agilist I speak with is too dogmatic.

Israel

I started in the networking field when the OSI model was the New Big Thing. It definitely was helpful as a means for understanding varying network architectures, which is how it was meant to be used. Yet I seemed to encounter far too many folks in the field who assumed that the OSI model was meant to be prescriptive, rather than descriptive (thus confusing the OSI _model_ with the OSI _protocol stack_.) This confusion between descriptive vs. prescriptive models is one of the issues that plagues Agile today.

I usually try to express the principles in the most meaningful way to the person with whom I speak. I like the way Jim Highsmith summarizes the Manifesto: “Value over Constraints; Teams over Tasks; Adapting over Conforming.” I usually add Jim’s thoughts about innovation through experimentation to the conversation. If the excutive I speak with is particularly interested in Lean, I usually follow the good counsel of Mary and Tom you refer to. And, I often discuss the Deming System of Profound Knowledge as another “layer” in the discussion.

One theme I still wrestle with is Complex Adaptive Systems. For one reason or another most people I speak with find it hard to comprehend/accept. Hence, I tend to keep this subject for later discussions.

Israel