There is a second way that our thinking has been misdirected. Instead of seeking a concept of affairs of the world and how they would be supported by software, we spend most of our time thinking and building mental models of how the computer is going to execute our program. Our conceptual model is filled with algorithms and data structures - neither of which have anything to do with affairs of the world.
The object metaphor was supposed to change this orientation; so too the agile story (as we will discuss a bit later).
Naur reinforces the assertion that the conceptual model is the essential requirement for successful software development. Naur also demonstrates that this conceptual model is indeed conceptual - it exists only in the minds of the developers and cannot be reduced to documentation.
Theory exists in the heads (plural) of developers (plural). It exists in the same heads that are subject to Millers Magic Number 7 +/- 2, the same heads that Brooks claims are incapable of holding such a large and complicated model - at least consciously. So how is this apparent paradox resolved?
Group Think - Hive Mind
"... thinking doe not take place inside our heads but is an activity that we perform with our heads. Most of our mental activities need external resources, and very often thinking is merely a grouping or regrouping of objects in our environment. ... humans basically use artifacts to acquire knowledge and create meaning rather than to represent it."
Keil-Slawik is also concerned with theory (conceptual models) as a pre-requisite for successful software development. He makes many of the same arguments as Naur to explain why representational documentation  cannot contain theory. He also grounds theory firmly in a physical context.
"A gestalt [synonymous with theory for our current purposes] emerges when certain objects or phenomena in the environment are related to each other in a meaningful way. ... the perceived gestalt is a construction of the observer. ... we perceive the world by constructing meaningful relations (gestalten). Consequently, we can only perceive what we construct."
These insights open the door to an understanding of how groups of people - sharing the same physical environment - can establish a collective gestalt (conceptual construct) - a theory - that can then be used as a foundation for software development.
A collective understanding - utilizing an entire context of external resources, organized into what Keil-Slawik calls an "ecological model of iterative learning - is more than sufficient to deal with the scope required by Brooks' conceptual model.
We now have all the pieces to ask what agile practices can contribute.
Agility is a Silver Bullet
Most of the agile practices, when used in the right way for the right purpose, directly attack the essential difficulty of software. They can be a silver bullet!
Let's examine some of the agile practices from the perspective of how they contribute to theory building.
Consider the agile environment: big visible charts (information radiators), walls with story cards, whiteboards full of drawings and notes, a build-lava-lamp, food, rolling-chairs on hard floors, and computers of course. The agile environment provides exactly the kind of context full of "artifacts to think with" that Keil-Slawik argues is necessary for a group to successfully construct a shared gestalten.
Think that rolling chairs on hard floors are an irrelevant detail? People are tangible artifacts too, and rearranging them along with the artifacts does enhance theory building. Context matters, gathering people around the story progress tracking wall matters just as much as physically handling the story