Agile and Wilful Blindness

@ruthmalan challenges @swardley on #Agile

Asked what is agile? It's a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015

@swardley have you seen John Seddon's quip: "Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster."?
— ruth malan (@ruthmalan) April 21, 2015

@swardley in theory :) What we're paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015

@swardley I was making a sophisticated/nuanced point. We canalize -- we think we're open to finding misdirection but it's hard
— ruth malan (@ruthmalan) April 21, 2015

---

Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stewart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.

Let's suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn't matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley's point that you don't need to know beforehand exactly what you are building.

But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon's point that Agile may simply build the wrong things faster.

And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don't know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it's the wrong system in the wrong place.

One important function of architecture is to pay attention to the things that other people (such as developers) may miss - perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).

Read Ruth's further comment here (Journal November 2015)

---

Wikipedia: Shearing Layers

Enterprise POSIWID

#bizarch #entarch #POSIWID As anyone knows who has attempted serious business and organizational transformation, an enterprise can be as stubborn as a teenager. Complex systems have strong feedback loops that maintain and restore the status quo against the most forceful and ingenious interventions.

One way of thinking about this challenge is to identify two distinct sets of purposes. On the one hand, there are the official intentions and plans of the leadership, which define what the purpose of the enterprise is supposed to be. We may call this the nominal purpose of the enterprise. Many enterprise architecture frameworks regard the nominal purposes as paramout, and are dedicated to realizing them. But on the other hand, the observed behaviour of the enterprise can best be explained in terms of an entirely different set of purposes, which repeatedly frustrate the official intentions and plans of the leadership. (See for example my post [Why New Systems Don't Work].) These are sometimes called defacto purpose; alternatively we can call it POSIWID, which stands for Stafford Beer's maxim that the Purpose Of a System Is What It Does. Large organizations and ecosystems are subject to inertia, and expensive initiatives often fall disappointingly short of expectations - this is the POSIWID effect at work. And of course there may be multiple conflicting defacto purposes [POSIWID should be plural].

POSIWID may also mean that there are covert purposes at work. Sometimes a corporate bureaucracy appears to be designed to make life difficult for employees and customers, as Tom Graves observes in relation to United's complaint resolution system [February 2010]; even if such a design is not consciously planned, it may be sustained by the short-term benefits it confers (such as cost-saving or corporate convenience).

Within enterprise architecture itself, we can perhaps distinguish between nominal purpose and defacto. Never mind what EA ought to be doing, if many enterprise architects are merely playing Framework Bingo, then many people will assume that to be the de facto purpose of EA [July 2008].
 
When TOGAF 9 introduced (but failed to explain) the term "Holistic Enterprise Change", I suggested it might mean something like this. When you make changes to the business as well as changes to the systems, you may get more than you bargained for. Conversely, when you make changes to the technical systems without making changes to the human systems, you may get less than you bargained for [February 2009].

By the way, Patrick Hoverstadt may well touch on some of these issues in his talk to the BCS Enterprise Architecture group in London next Thursday.

---

Tom Graves, Economics as enterprise architecture (March 2010)

POSIWID blog

Architecture and Change

@tetradian and @robert_phipps have recently floated the idea of Enterprise Architecture as Vectors.

Clearly the word "vector" is just a metaphor. But I agree that EA needs a more robust way of talking about change than simply assuming that change involves a jump from one state to another state. (Yesterday we were operating this process, tomorrow we shall switch to a new process.) Most organizational change requires an extended transition period, including the so-called learning curve. Capabilities develop and mature. Business relationships and trust take time to become established. And so on.

And EA needs to understand the complex interaction between many different changes. A typical enterprise is teeming with lots of different change initiatives, some of which may be formally constituted as "projects". Each one is based on a false or simplistic theory about the current state of the enterprise (AS-IS), and a naive or optimistic theory about the future state of the enterprise (TO-BE).

As the vector metaphor suggests, these projects and other change initiatives interact (compose themselves) in usually unpredicted and possibly unpredictable ways. Sometimes the initiatives merely cancel each other out, leaving the essential characteristics of the enterprise-as-system largely unaltered. (The ability of complex systems to preserve their identity and deep structure in the face of efforts to change them has been studied by many systems theorists, including Meadows, Beer and Maturana.)

However, the participants in these projects usually resist perceiving the full richness of what has happened: they try to convince themselves and their bosses that the intended outcomes have been more or less achieved, and that something else is now required. Thus the cycle begins again.

---

Since I posted this, Robert Phipps has posted a more detailed explanation of his idea: Part One. See also Linked-In discussion.