Every now and then, someone else will ask me questions about the past, since I don't rehash voluntarily anymore. I prefer to work on the future. Marko van der Puil asks me how I reconcile that with facilitating retrospectives.

To me, retrospectives are as much about the future as they are about the past. We collectively investigate a set period in the past, to achieve closure on the past, and determine concrete actions for our future. If a retrospective doesn't turn up personal and collective actions for positive change, we might as well have skipped it altogether.

Luckily, I read the paper before going to the workshop - that left some room in my head to fill some of the gaps in my understanding the paper had left me with, rather than being overloaded (as most of the workshops' participants seemed to be. It made quite an impression). By the way, the reason I read the paper was that I was wondering if paying to attend this workshop was worthwile. Since after reading I still had many puzzles, I thought it would be, and it was. I'm still ruminating over these ideas.

One of the ideas that resonated most with me was the Cynefin Domains model. It is sort of a two-dimensional matrix. The paper has a nice graphical depection that makes it clear that the boundaries between the domains are semi-permeable. One way I understand this model, that an organisation can move from one domain to another by making sene of where it is now - and seeing if the paradigm it currently applies for e.g. decision making is appropriate. I've transcribed the four domains into a table:

To give one illustration (more in the paper mentioned above) Systems Thinking and Scenario Planning fit into the Knowable domain. Someone at XP Days London asked me if I didn't find it annoying that Dave Snowden sort of mowed the grass before my feet; Marc Evers and I were hosting a Systems Thinking workshop at XP Day London the next day.

I responded that I was very glad for the context setting Dave Snowden had done - we used the Cynefin Domains model in the introduction of our workshop, as we are constantly looking for a better way to briefly introduce Systems Thinking at the start of a workshop. I am not Systems Thinking :) it is one of the techniques I use to make sense of the world around me, if and when appropriate.

So how do I believe this model relates to appropriate forms of setting up an organisation? I immediately related this to Gerald Weinberg's Cultural Patterns (aka Shooting and Aiming Stances) for organisations, so I came up with this mapping:

The Congruent cultural pattern would be equivalent to sensemaking: taking self, other and context into account, and choosing (and changing, if the domain shifts) a cultural pattern that is appropriate. When I was reading the wiki page on Cultural Patterns I realized I forgot Oblivious. Thinking about it now, I find it hard to place. Maybe the oblivious cultural pattern is not realizing where you are, and not making any choice for an organisational form.

The connection was somewhat natural, since with a group of systems thinkers we've been thinking about how to move from one cultural pattern to another. In the workshop and paper, Dave Snowden says they've identified a number (27 if I remember correctly) of specific choreographies to move from one domain to another.

For instance, working iteratively is a way of moving from Known to Knowable and back, and moving from Knowable to Complex can be done by Exploration (to move in the opposite direction, use Just-In-Time Transfer).

Dave Snowden talked about the relation with eXtreme Programming. At first sight, I would place XP at the Known/Knowable boundary, because of the Iterative aspect. He seemed to place it in the Complex domain which left me a bit puzzled.

The way I could place it there, is that XP also has an exploratory component (e.g. doing spikes), and the extremely short iterations make it possible to investigate multiple alternative solutions (relating to what Snowden calls probes, exploration and to Set Based Development). Another component to XP/Agile is delaying (design) decisions as long as possible, which relates to just-in-time transfer.

I just noticed I'm using a lot of emphasis in this post. It seems to have a high jargon density. I'm looking forward to the article collection promised at cynefin.net, so I could upgrade some of the emphasized words to hyperlinks. In the meantime, I recommend you read the paper if these ideas interest you. I'm also interested in any comments you may have on this blog entry, as I'm busy understanding the Cynefin paper.

In November we're at a number of events I'm now dubbing XP Week. Friday November 19th at XP Day Benelux in Mechelen, Belgium. The Tuesday after that (November 23d) we're in Karlsruhe at XP Days Germany and then on Thursday 25 we'll do the systems thinking workshop at XP Day London.

Make feedback policies for feedback systems.

President Jimmy Carter had an unusual ability to think in feedback terms and to make feedback policies. Unfortunately he had a hard time explaining them to a press and public that didn't understand feedback.

He suggested, at a time when oil imports were soaring, that there be a tax on gasoline proportional to the fraction of US oil consumption that had to be imported. If imports continued to rise the tax would rise, until it suppressed demand and brought forth substitutes and reduced imports. If imports fell to zero, the tax would fall to zero.

The tax never got passed.

One of these wastes is not automating repetitive tasks. Fast Company Now guest host Keith Yamashita refers in Systems thinking: The Product to a speach by eBay founder Pierre Omidyar:

So people often say to me - "when you built the system, you must have known that making it self-sustainable was the only way eBay could grow to serve 40 million users a day." Well... nope. I made the system self-sustaining for one reason:

Back when I launched eBay on Labor Day 1995, eBay wasn't my business - it was my hobby. I had to build a system that was self-sustaining... ...Because I had a real job to go to every morning.

When you're the sole programmer and product visionary, this is doable. Your lack of time will force you to choose between glitzy new features and stabilizing the system (e.g. by preventing and removing defects and automating repetitive tasks). I'm curious how eBay does it now it has become much larger, and more people will likely be involved in decision-making and programming...

In fact, assemble any senior group of IT thinkers, and even though they'll probably fight over middleware strategy, Sarbanes-Oxley compliance campaigns, outsourcing initiatives and the future of Linux, they'll agree that the way vendors market products and services is dysfunctional, if not an actual roadblock to value creation.

Inappropriate and outdated mental models on why and how technologies enter the organization. The days of "crossing the chasm" are over. Geoffrey Moore, the creator of this once-dominant descriptive framework, has moved on; vendors should too.

One of the old-fashioned sales techniques reflecting one-size-fits-all thinking in my opinion is the venerable elevator pitch. It assumes you can prepare a one minute presentation about your product or service you can use anywhere. For my services, I find the elevator pitch simplistic - I prefer to spend time asking questions and listening to a prospect first, think hard if any of my services or a new service would fit the clients needs, and only then offer an appropriate service.

Selling to IT departments will become harder as IT managers themselves are under fire from their internal customers. See e.g. Job security top concern for CIOs in Computer Weekly. The average IT department has a track-record of not delivering value for money. So now CIOs jobs are on the line, as part of their departments are being outsourced and/or offshored - if the clients can't get good service, they try to get the same bad service cheaper.

Agile product development and agile services can be a remedy to this, taking into account the offering of the supplier, as well as the context and capabilities of the client. It's not going to be easy, and probably take a long time, as the way IT projects are managed has to change, meaning close collaboration between customers and IT people.

Convincing dissatisfied clients to become involved in IT projects and product development is quite a challenge, as both IT Departments and vendors have to show a profound and lasting care for concerns of senior management, end-users and the clients' clients.