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.

My take on projects in ye average bigge organisation has been: the price of a project depends only on the position on the corporate ladder of the manager who starts the project. The lower the level of the manager, the cheaper the project.

Please note that delivered functionality or business value is not part of the ‘project cost’ equasion…

I have often wondered about, and looked in amazement at these large projects that seem to go on forever. I believe that most projects can be done with less people in less time, and many projects are not worth doing at all.

Maybe someone at <insert large ‘consultancy’ company here> did actually invent a working perpetuum mobile…

Read what a (former) big shot in a large company writes on how this mechanism works in practice, and what it feels like to be on the receiving end. How to destroy your company by packages, outsourcing and ‘consulting’ companies (and not paying attention to your users and customers)….

“Outsourcing is a brilliant trick of the managers. The responsibility for the failing project is moved to an outside vendor. They are now the object of aggression.

The real customers don’t talk with the programmers. They talk with the managers that are talking to managers that are talking to managers. Somewhere in the chain of communication all the meaning is lost. The result is something they don’t want, the users don’t want and the customers don’t want. Last but not least the process took so long that the market has changed. They have to start all over again.

Do you now understand why we there is such a shortage in IT specialists? About 30% of IT-projects is succesful. This means that 70% of the IT-specialists are working for nothing.

My advice

Adapt what is working as long as possible.

A team of 15 people is capable of doing more than a team of 1000.

Do it yourself.“

Hans describes a full circle process of what happens before a project is outsourced. I call it the “Shit” cycle I couldn’t resist making a drawing of it:

I missed one phase in the process: the pre-project phase, which consists of a sales rep of <insert large ‘consultancy’ company here> taking the high-level manager to the golf course…

What I don’t know is, each time the project goes through the cycle again whether golfing is required (Hans writes about one project that cycled for ten years…).

I prefer small change over big change. I’m talking about transformations, of course . Small transformations make it easy to check if what we want to happen actually happens, and how far of we are. If you’re reading this blog there is a fair chance you are familiar with growing software in small steps – I apply the same principles when working on myself or helping others to improve their (development) performance.

(more…)

I’m enjoying and making sense of Dan Russell’s posts on sensemaking:

What’s always struck me about sensemaking behavior is this: People just don’t seem to be all that good at it. They take notes on the topic, then never go over them, or lose them in the shuffle of life.

I resonate with that. I’ve learnt a couple of approaches to make sense of where I am, where the organisation is, and where it’s context is, for instance systems thinking tools such as the Cynefin model. Whenever I’m confronted with a problem, I may or may not reach for my tools. Often, I get stuck in a situation, and _then_ reach for my tools and think “why did I not think of that before…”
For instance, I’m working on a product where the self-organizing team has not been able to agree on a direction and a planning method for a while. I look at the context – it is new product development, something like whatever we are going to make does not exist. If I get the Cynefin model out of the box, we find ourselves in the “Complex” domain, where cause and effect are only coherent in retrospect and do not repeat. The appropriate approach (according to the Cynefin model) is to create a bunch of products instead of one.

So it may not be a wonder that the team can’t agree on an approach – we shouldn’t. We are not blind men looking at different sides of an elephant – we are looking at several elephants, and each may require their own approach…