me.andering – Willem van den Ende

Preparations for the trial run of People vs Process: Cultural Patterns of Software Organisations this Wednesday are starting to wind down. The presentation, exercises and stories we want to do are virtually done. Marc uses cultural patterns to describe some common failure modes when starting with an agile way of working : Agile choreographies in the culture space:

Most of the time, transitioning to an agile approach means going from a Variable or Routine culture to a Steering culture.

Practices like daily stand-up meetings, short iterations, frequent releases, iteration retrospectives, test driven development, continuous integration, big visible charts, stop the production line mentality all help improve the visibility and stability of the software development system.

These are all indicators for a steering culture.

The transitioning process itself often escapes the attention of the unwary. That can result in an oblivious or variable transformation process, which in turn can result in one of the failure modes Marc mentions. A heroic (variable) or unconscious transformation can result in reduced performance, that you often won’t be able to notice… Or you’ll get lots of ‘resistance’ and think ‘how did that happen?’

The process of transformation itself can be done in a steering way, for instance by using a change backlog. It helps if one knows, for instance by experience, where to look. Because we don’t have a stable process yet, we have to rely on observation. To know what to observe, we can rely on experience. Either our own, as we go along, or re-using past experiences, e.g. from an experienced mentor/coach who knows where to look.

Using past experiences in various contexts to choose practices that apply in a new context, and doing risk analysis combined with scenario planning (elaborate, or back-of-the-envelope, depending on the complexity of the environment) already gives the change effort itself some characteristics of an anticipating culture.

For risk analysis, some of the failure modes Marc mentions are valuable input. Up-front identification and analysis of risks, their likelihood and mitigation strategies can be done in a simple ‘agile’ fashion as well – get the people involved in a room around a flip chart and brainstorm away for an hour or so. Then keep the flip chart on the wall, and re-visit it every iteration or two. As in all things ‘agile’ we do an ongoing assessment – of risks materializing, as well as potential new risks…

Otherwise, the result of an oblivious or variable transformation process might be, ‘that agile method does not work, let’s try to surf to the next wave…’

Photo Credits:

1. Smoking, Picking Nose and Driving by Mike “Dakinewavamon” Kline
2. Pink Swirl by tanakawho

I read in several places that systems thinkers tend to keep their work to themselves, and that stories work best to get more people to do it.

So, here is a story with a diagram of effects – want more traffic? .

Context: Last week, Marc Evers and I were working on a quote for a community website, based on a request for proposal we got. We made the diagram to clarify our interpretations about the clients ‘business’ – a not for profit foundation supporting a community of practice.

I’m involved in a number of websites, e.g. to support my business, conferences and as of recently wyrd web – a budding company to support more of that. The diagram helped me understand this client, and some of my other contexts involving a community and its’ website(s) – e.g. systems administrators don’t always see why uptime and responsiveness provides business value to a community of practice (which if done well supports a thriving eco-system).

We decided to send the diagram to the client, and then I posted it. The diagram itself is isomorphic with part of its message: quality content drives traffic, which in turn drives quality content. The post attracted a nice comment, which helps me to write more about this topic .

We’ll see in the coming weeks whether this diagram helped the clients’ contact person in sharing our understanding of an effective website’s value with the not-for profit’s board.

I’m enjoying the term mythodology – collecting fieldstones for an article, I’m re-reading “Weinberg on Writing – the fieldstone method”

Doing an internet search for mythodology, I found Marco Abis named his website mythodology. As he says on mythodology:

Towards the end of 2005 I found it in the book “Weinberg On Writing” in relation to the (in)famous writer’s block (but interestingly the quote is from Tom Gilb):

‘Writer’s block is not a disorder in you, the writer. It’s a deficiency in your writing methods-the mythology you’ve swallowed about how works get written-what my friend and sometime coauthor Tom Gilb calls your “mythodology.” Fieldstone writers, freed of this mythodology, simply do not experience writer’s block.’

[..]Agile methods are the next (current?) step but are still only scraping the surface of the problem having myths themselves which get in the way of the true Quality.

Hear hear!

As Agile ‘methods’ (I’m still / more and more against methods ) become mainstream oversimplification becomes rampant, as was to be expected.

As a programmer told me:

One programmer is fanatical about code quality, he is especially strong against duplication. He is also the one who maintains an install program for our servers, and one for development workstations. They should be quite similar in operation – however they are two different scripts, one was once a copy from the other, but they have now diverged. This means defects have to be repaired twice, and the scripts are a complicated mess that only that programmer can maintain, with a lot of effort.

When I asked him “why did you duplicate these scripts” he said: “The what? oh yes, that is not a program. That is something I just put together so we can install our program. It’s not a program, it’s just a script… “

For some reason this second programmer sees the install script as a
non-program, so the same routine that applies to programs, does not apply to ‘scripts’, therefore duplication is not a ‘problem’ – he can not see it as a problem, even when the first programmer asks him about it.

The second Programmer has an oblivious pattern for one part of the project where he may apply a routine or steering pattern to other parts.
The first Programmer seems to be aiming for a congruent culture (albeit, so far a culture of one person only, a micro-culture so to say):

Congruent culture – everyone is involved in improving everything all the time; it is a culture of ongoing reflection and improvement.

So in that view

Scripts are programs too

And if there is a problem (defects caused by duplication in this case), you stop, work on the problem, find out what caused it and what we can do to prevent it from happening again. And, last but not least, we do this with the whole team, so everybody can step away from their micro-culture.

In a way, a congruent pattern makes it irrelevant whether something is a program or not…. if something gets in the way, we do something about it.

(This post is part of a series on cultural patterns of organisations. Marc Evers and I are hosting a trial workshop next week, so we’ll be posting some more stories and pattern descriptions as we are working on our introductory presentation this week).

Credits:

(photos under a creative commons 2.0 ‘by’ license)

“Oblivious” by James Craig (picture of a standing duck oblivious of a waterfall, because it faces the other way)

“Oblivious” by Emily Nieves (picture of a lady in the water with her eyes closed)

Tomorrow and the day after sees Agile Open California come to life. With a strong theme “Sustainable Agility: Thriving in the Mainstream” , and a good number and variety of participants, it looks like an interesting addition to earlier Agile Opens in Europe and Agile Open Northwest.

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