Frameworks, theoretically speaking…

Figure 1
Figure 1

Theoretical frameworks are defined more by what they do than what they are. To understand this, consider a physical framework for a house (Figure 1.) Its purpose and function is, quite literally, easy to grasp. It solves problems in the physical world and it’s easy to understand how such a framework can add value to our lives. It’s also easy to assess the limitations of a physical framework. The house framework reveals the underlying structural of beams, joists, rafters, and such. With this structure, it is easy to imagine this as an ideal solution to protecting a family from the weather. It is equally obvious that this same framework would be wholly inadequate as a sports stadium. The structure in Figure 1 adds value to the eventual solution for protecting a family from the weather, but as a solution for hosting a large sporting event it leaves much to be desired.

Staying with the physical framework for a moment, several useful rules become apparent.

  • The problem defines what framework should be used. Frameworks ideally suited to solving one problem may result in disaster if applied to a different problem. A corollary could easily be that there is no single framework that can solve all physical structure problems. Rather, frameworks can be composed of a wide variety of materials and can come in all manner of shapes and sizes.
  • The choice of physical frameworks defines the tools, techniques, and materials to be used during construction of the overall solution.
  • Frameworks necessarily limit focus. By focusing the crew in this way the contractor can better controls quality, cost, and scope.

Similar to how a structural frame (or framework) to a house provides underlying support in the physical world, a theoretical framework provides an underlying conceptual structure in the world of ideas. Scrum and SAFe are examples of theoretical frameworks. The rules for physical frameworks apply equally well to theoretical frameworks. However, when the conversation shifts to theoretical frameworks, people often struggle with how to apply these rules. Being less tangible, it is easier to inadvertently select a theoretical framework that results in a sub-optimal solution for a particular problem. Without a clear understanding of the problem and the capabilities of a selected theoretical framework, a manager may inadvertently select a set of tools, techniques, and practices that are unsuited to the task. The framework won’t support the desired solution.

Just as with a building designer, the challenge for the leader tasked with implementing Agile is that he or she must first have a clear understanding of the problems they are trying to solve. They must also have a solid understanding of the possible Agile frameworks from which the optimal choice can be made.

As with physical frameworks, theoretical frameworks define the tools and techniques employed during the actual work effort. When the theoretical framework is appropriately matched to the business problem, leadership can more easily identify and define variables and constants, design define meaningful metrics, and make more effective decisions for reaching desired outcomes.

Expert 2.0

A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this “Linus’s Law.” (P. 41)

So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.

This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.

Imagine, around 1440, a gentleman from Verona named Luigi D’vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent “movable type.” This last guy actually existed in the form of Johannes Gutenberg.


Assuming D’vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg’s interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.

But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the “magic” to happen. Quality “thinking outside the box” doesn’t happen without a lot of prior preparation. You will need to know something about what’s outside the box. And note, there aren’t any limitations on what this “what” may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn’t guarantee that it will be useful. It only enhances the possibility for innovative thinking.

There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the “magic” of innovative thinking, as defined by Haskell (2001, pp. 45-46).

  • Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
  • Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
  • An understanding of the history of the transfer area(s) is vital.

To summarize, in your field of interest you must be an expert of both technique and history (lest your “innovation” turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.


Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.

Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O’Reilly & Associates, Inc.


Image by István Kis from Pixabay