problemsOver the July 4th holiday I was able to read the first 50 or so pages of Peter G. Rowe’s 1987 monograph Design Thinking. This book, like so many good things in TUG-land, was recommended to us by Jorge Arango. I’m eager to continue reading, but the number of note-card doodles I need to work through with the turn of each new page has me doubting I’ll get all the way through to the end before business as usual resumes on Monday. That’s OK though, because I’ve already learned and been influenced by so many things in this text, including some intriguing ways to break apart and examine the enterprise of doing architecture work.

Rowe is obsessed with, as he puts it, “the influence exerted by the structure of the problem-solving process itself.” In three different examples from three different architects, Rowe starts to build an argument about procedures and the inclinations of different procedures. The cases help Rowe illustrate a beguiling tension between the conditions of the project as given by the client, and the “enabling prejudices” (Gadamer, 1975) of the architect and of the architect’s procedural approach.

I’m eager to see where Rowe is taking this, but am already brain-asplode from what I’ve consumed thus far. And I’m burning a lot of sharpies and note cards. And tweeting-out some of the chestnuts, not the least of which is this delightful across-the-board way Rowe has of characterizing all of the architectural procedures in his sometimes-widely varying case studies:

Not all of the approaches to getting architectural work done described in Rowe’s text are iterative, but all of them are episodic. And in a UX world where so much of the procedure of making things is agile, a reader like me can’t help but see corollaries between what Rowe is describing in military terms and what agile folks describe in terms of athletics. Rowe’s choice of the word “skirmish” to characterize the episodes of project activity really grabbed me. As opposed to “sprint.” My contention, again on Twitter (this time in a message to Christian Crumlish) is that the stuff we do and make would be profoundly different if we adopted Rowe’s metaphor and the entailments of his metaphor:

Problem-centric, Not Project-centric

The entailments of “sprint” include going as fast as possible in short duration, linearity, and a finish line. If your approach to the procedures by which work gets done is project-centric, these entailments of “sprint” are hugely helpful. Specific and not-prolonged bursts of exertion with a clear finish line and distinct lanes for participants to work inside of. And there’s always a winner. That sounds like a well-run (see what I did there) project. Adoption of “skirmish” to replace “sprint” and bringing in a different set of conflict-flavored entailments is probably not helpful if you continue forward with your procedures and processes in a project-centric manner.

That’s part of what’s so fascinating to me about Rowe’s metaphor and his instantiation of it with regard to the procedures of doing architecture work. The framing is problem-centric, not project-centric. And when you move the frame from project to problem, swapping “sprint” out for “skirmish” and sporting event out for warfare starts to make wholly different kinds of sense and meaning. The inclination of skirmishing is not to solve the problem, but rather to figure out what the problems are. What before how. The inclination of sprint is to solve the problem, or break it into as many 2-week chunks as it takes to solve.

This book gets even more fascinating when you dig into what Rowe means by “problem.” Based on the work of Newell, Shaw and Simon from 1967 and upon further distinctions made by Churchman, Rittel and Bazjanac between 1967 and 1974, Rowe sets forth two broad classes of problems and a sub-class of the latter class: well-defined, ill-defined and wicked problems. I was captivated by Rowe’s gloss on these, and by his assertion that most architecture work is set in motion against ill-defined or wicked problems. If we accept Rowe’s assertion, it follows that the procedures adopted by architects are problem- and not project- centric. And in the face of ill-defined and wicked problems, it follows that the procedures adopted by the architect are likened to skirmishes and skirmishing.

Skirmishes are asymmetrical. Non-linear. They’re differentiated from battles insofar as they do not presuppose a crisp (or even intentional) beginning and/or ending. Continuity in tactics, approach, personnel and equipment from skirmish to skirmish is not required or even expected. Skirmishes do not presuppose winners and losers. Skirmishing does not always or need to result in destruction; rather, the necessary pre-condition for a skirmish is simply the coming or bringing together of opposing forces.

Which brings us back to Mr. Arango. In 2011 at the annual Information Architecture Summit, Jorge presented a panel along with Andrew Hinton and Andrea Resmini titled More Than A Metaphor. Their argument, in three parts, was and continues to be that “the architecture part” of information architecture is not a metaphor, and that the work we do in information environments isn’t similar to or like unto the work of architects in the built environment. It’s the same work. In Jorge’s section of the conversation, he presented a diagram that he described as a “force diagram.”


Arango was trained as an architect, and the contention he made in his presentation is that the unique value provided by architects is the leadership to deal with all those opposing forces. The ability to lead a team who’ll figure out an architecture to take on the unevenly-distributed, complex and contradictory forces of the project.

As we practice it at TUG, this figuring-out of “the what” of the project always happens inside of some sort of time box. And yes, you could say we’re sprinting inside of these time boxes or that the edges of the boxes are tantamount to a finish line if you’re so inclined. But the work we’re doing, the energies we’re exerting back at that snarl of uneven project forces and objectives and variables to declare a clear “what”… The action of the verb to characterize the activities we engage in to yield those structures is “to architect.” And the meaning of the action of this verb and of this work we do strikes me as sharing a far deeper set of affinities with the meaning of the action of the verb “to skirmish” than those it could be seen to share with “sprint.”


Post-script: Lakoff and Johnson have said all that you need to know about metaphors and entailments in their 1980 book Metaphors We Live By. There’s a PDF of this work out there on the interwebs that’s easy to find with Google, and I exhort you to do so.


Another post-script: I think this sense of skirmishing is what Graham Linehan is talking about with his approach to writing: “I will research and procrastinate and sort of circle an idea for as long as possible before attacking it.”

Showing 5 comments
  • Edward Vielmetti

    “Skirmish” sounds like a small piece of a very long battle where there are no clear winners and losers and where even the outcome of the day’s events are obscured by the fog of war.

    I appreciate the “sprint” metaphor, even if I realize that it’s not so accurate, because it’s easy to get discouraged if you think of your work as a long series of ambiguous skirmishes and never any clear wins.

    • Dan Klyn

      By way of local (to us) example, the “Toledo war” was not very long, and the outcomes non-obscure. And the discouragement issue you raise: I think you might be swapping skirmish in for sprint and not making the corresponding frame-change that Rowe makes from project- to problem-centricity. With ill-defined and wicked problems, the removal of ambiguity and the declaration of clear wins relative to the problem at hand isn’t necessarily or even primarily what’s being sought after in the solution(s). Breaking the effort up into sprints which have high definition and low ambiguity may still be possible, but some of these problems don’t lend themselves to how we’d prefer to organize and manage resources on projects. The influence exerted by the agile project management approach on what’s possible for us to think about and do relative to the problems we’re framing and trying to solve is something Rowe’s book is causing me to scrutinize more and better than I’ve done in the past. I’m grateful for your push-back and perspective, Ed!

  • Daniel O'Neil

    I just re-read Dan’s comment and it it says a lot of what I was saying below. I have to use smaller words and shorter sentences because I’m not Dan…here’s another way to put it.

    1) The objective of agile methodology, more than anything else, is to create a spirit of moving forward and accomplishment. It works under the fundamental assumption that you can’t really understand the requirements of a software project because the systems are too complex and the needs are too abstract. Hence you generate small prototypes.
    2) As Ed pointed out, I don’t think they would mind the idea of a skirmish except that it’s critical to prototype and generate outcomes in agile, so the implication that skirmishes can be inconclusive might create some friction.
    3) More importantly, Agile folks might take issue with the idea that there are really “difficult” or “wicked” problems. Problems that cannot be addressed in sprints are instinctively chunked, that is, they are made small enough to solve some part of it and nibble around the edges.

    This isn’t necessarily an accurate way of viewing the world, but it is a realistic application of a methodology that is designed to keep features cranking out of the factory. The roads must roll.

    (Love the force diagram)

  • Jim Laing

    I think the suggestion to switch from “sprints” to “skirmishes” makes a ton of sense and helps clarify intent. This is especially true as it relates to 1.0 products, where so much work is just figuring out what the thing should be (the wicked problems).

    Just like so many movements, I think what the original Agilists had in mind (or, if we’re talking about sprints, the pedant would say Scrum-ists) is pretty different from what is practiced today. I think Daniel has it right, in terms of describing the original intent of sprints as finding the right solution through iteration. However, today (it seems to me that) iteration is rarely practiced in the real world. (Incrementing, however, is common: ) Given that iteration is a lost art, I wonder if the word “skirmish” might help regain some of that original intent – helping a team recognize that what they’re doing is hard, has unpredictable results, and that failure is likely. Of course, once a product is well-defined, sprinting might be a more appropriate metaphor. But if you’re only building well-defined things, than agile isn’t really benefiting you much.

    • Daniel O'Neil

      These are really good insights, Jim. I think the difference between “incrementing” and “iterating” is a critical one and something that I need to think more about.

Recommended Posts