me.andering – Willem van den Ende

While procrastinating on the next post, Nynke jumped ahead with scenario planning and Marc continues with his routine on routines – we follow our routines (except when we panic) on what happens when a routine culture breaks down because of a foreign element. I could have anticipated that…

So this episode was supposed to be on how cultural patterns work on different levels, sort of like fractals, with stories. The first story already got quite more elaborate then I planned (and I wanted at least two in for the first story…), and I have no pictures for it! I’ll panic (following Marc’s lead ) and leave the stories for (maybe) tomorrow.

About my routine (when in panic, why not make a blog entry about blogging and me, which is what blogs are supposed to be about, no? )

My current process for posting a blog entry, is that I collect fieldstones, and when I feel one is strong enough, I go out and hunt for pictures. Because the feedback (steering…) on some posts suggested that posts with pictures and/or posts that are well prepared attract more readers as well as more comments (hint: I like comments)… So adding pictures became a routine… And in that routine, I have to follow the rules: post only with pictures…

To keep up with Marc and Nynke, I have broken that routine

To me (agile) software development is about delivering business value to the customer (by as little software as possible), and doing what works in practice. Today I’m writing a bit about routine versus variable cultures in organisations.

A current project, recent writings by Marc Evers and Nynke Fokma and upcoming sessions on organizational cultural patterns (based on Gerald Weinberg’s work) inspire me to write a little about… routine , so I can explain what the session is about, and evolve my understanding beyond what’s in the book. I’ve been using variations of this model for quite a while now, so it is about time to write about it

My mentoring/coaching clients fall roughly in two categories: those doing some form of chaos development, and those who supposedly have a bureaucratic, routine based process.

Digging deeper, my clients fall into one category: those who have some form of chaos development…

I’ll explain my digging along two lines:

1. Routine processes are uninteresting strategically
2. Routine processes are not focused on results. They only (seem to) work, because result-oriented people find a way to work around it and don’t tell anybody…
3. Routine is boring

Routine software development culture :
“We are developing software – follow The Rules”

Routine processes are uninteresting strategically

As Marc Evers writes in Keep on failing (in the small…):

“Predictable projects are not interesting, not in a strategic sense. If it’s predictable, there’s probably someone who has already done it or even created a product or service for it. Most interesting, strategic IT projects are in the complex space, where cause and effect are only coherent in retrospect and do not repeat. Best practices, recipes and step-by-step methods don’t work here. You need to steer based on feedback instead, through a cycle of probe, sense, respond”

So, if you want to create an entirely new market, you have to work based on feedback, if you want to go somewhere with an innovative product, you have to dance to the beat of life, and create your own beats

Routine processes are not focused on results

Because, to get anything done in a routine environment, you have to bend the rules. “The Rules” are usually made to prevent change of any kind, and “The Rules” have a tendency to grow in volume. As they grow in volume, they inevitably start to contradict themselves. Therefore, my clients only fall into one category

Now, as an investor or product owner, if you start a new project, you might feel tempted by the false idol of “The Rules”. It is easy to find IT suppliers who happily work with “The Rules”, making big, fixed-price contracts and maybe even using some form of Model Driven Architecture / Design, which is a translation of working by “The Rules” in software development terms. . .

As Nynke Fokma writes in Great innovations that help the world

“The intention of MDD, model and routine driven developments, is to make software work routine. It is a focus on the tool rather than on people”

So, why do routine-oriented people get scared when you mention agile. They hear a transformation from:

“We are developing software – follow The Rules”
to:
“We are developing software”,

which would be a Variable culture.

The mental image of a Variable culture for someone in a Routine culture looks like this:

“Variable Expansion”

If you remove “Follow the Rules”, Routine people can’t see the safety net. A Variable culture doesn’t have a safety net, so we don’t want to go there from routine.

However, as a mentor, a Variable culture is a much more pleasant state to start than a Routine culture – there are no “The Rules” to unlearn…

People in a variable organisation know that they are developing software, which makes them more aware than people in an oblivious culture:
“Are we developing software, really?”
“Oh, no, this is not software, It’s just some macro’s I made in Excel and Access” (never mind that these macro’s are the only things that are keeping track of millions of euros worth of business, as I saw in a moderately large manufacturer).

Clients in the variable space are usually a lot of fun for me. They are results oriented, and often have delivered software recently. They know they are developing software, they hire me to do better.

Usually, when they get to the point to hire a mentor or go for training, they know they have a bit too much chaos development. They already have some areas for improvement in mind, maybe some practices too, and with some creative questions, maybe a small retrospective, we collectively find some more.

We keep the results focus and the fun people are having at work, and add just enough process to make the team(s) more productive (deliver less defects, more business value).

What that looks like? I’ll leave that for an upcoming post…. There are loose ends here, some intentionally…

I’m not saying you don’t need any _routines_, which is differently from having a routine culture. Appropriate routines create a stable basis on which you can build and experiment. On the other hand, as nynke says: if you are in control, you are not going fast enough…

Credits:

The beat of life photo by ♥ Cherie ♥

“Variable Expansion” photo by Andreas Kollegger.

Gerald Weinberg, for his work on organisational cultural patterns

Nynke Fokma and Marc Evers for blog entries and discussions.

Rachel Davies is blogging about what for me was one of the highlights of XP Days Londen 4 – a presentation and workshop by Dave Snowden about Cynefin, a framework for Sensemaking. You can find more information about this in the paper Sense Making in a Complex and Complicated world by Cynthia Kurz and Dave Snowden (IBM Systems Journal, Vol 42, No3, 2003).

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.