I was getting really frustrated about some online discussion today. It seemed other people were getting even more upset than I was (and even that is just one of many possible interpretations. I know from experience that the more frustrated I am, the less reliable my interpretations are). Instead of blowing off steam by firing of a blog post in frustration… which would let steam off on my end but could potentially multiply frustration elsewhere, I stumbled across Habits & strategy for effective listening by David Parnell. and decided to write publish on that instead. Tips for listening in a discussion can be just as useful when reading a discussion. Continue reading ‘Until cooler heads prevail – some things that let me calm down when reading online discussions’
Tag Archive for 'sensemaking'
Jurgen Appelo writes in Communication = Information * Relationships that “top-down systems thinking is a management fad“. I agree. Systems thinking works only if it happens in all directions at once. It seems to work when a group of people is doing systems thinking in the same room at the same time. All combined, these people bring the perspectives that are necessary to come up with changes that work. Continue reading ‘Bottom Up Systems Thinking’
Chris Matts is drafting comic strips on real options and financial options in the new decision coach blog he and Olav Maassen started yesterday.
I particularly liked the draft on Financial Options, it explains a number of not so intuitive financial instruments and techniques (e.g. naked short selling and futures) in such a way that I find them easy to understand, and possibly explain them to others. Not a bad thing to have in turbulent financial times. Chris’s goal is to make them understandable by ‘basically everybody’ – I encourage you to go and read it, and give him some feedback on bits you don’t understand.
Several people have been asking me how we market and sell development projects, consultancy and courses. I don’t know exactly, and I don’t know many people who do…
Marc, Rob and I have been busy for a while, thinking about repositioning what is soon to be formerly known as eXperience Agile. We were feeling that what we are offering is more than ‘just agile’. We also want to reach pragmatists on the other side of the chasm, who don’t respond well to the zeal that seems to rear its’ ugly head around methods every once in a while.
In short, We’d like a new website, so that our regular customers can easily find out which courses are forthcoming. We want new versions of the brochure, so that people can see the new courses, and we want to send out mailings more often, so that we can keep our clients and alumni informed on interesting conferences and new developments. There must be a system to all this, most likely similar to a tale of website traffic. And we’d like a new name and logo, so the brand fits better with our aspirations and activities.
Not that we know much about branding (or are necessarily fond of it – I’ve even said Branding is for cows in the past). But we got to do something
So we spent a day brainstorming new names, and finally found one that we all liked and had an available domain name that was not too long. If I remember correctly, Rob came up with the name and it fits well with the name of Marc’s company (Piecemeal Growth) and mine (Living Software), as it is also inspired by patterns.
Rob and Marc brainstorming on the new name
We also decided to do some experiments. We moved slowly, we were all available at different times and registering the domain name took longer than expected.
One of the experiments we decided to do is sponsoring a conference with money – usually we sponsor conferences with blood, sweat, and tears (and a good portion of laughter of course). And then it took us a couple of months to get moving on it.
We were procrastinating, because not ‘everything was ready’…Sounds like a software development project, doesn’t it . We did not have a logo, nor did we have the new website we wanted so badly – the current one is inconvenient to maintain and could look nicer.
This week, I decided to get moving, even though the sponsoring deadline of the conference had already passed. Luckily, one of the organizers mailed me if we were still interested in sponsoring – I had talked to him at the agile2008 conference already. That was excellent timing.
So I decided to go for it, and pay for the sponsoring. Doing that helped us to move forward. The conference organizers helped us by giving us a deadline – the logo had to be in by friday to make the printed programme
We felt we can always iterate over the logo and change it later. We also had to give them a url to the website. Oops. Ok, so we don’t have the flashy new site yet, but we have the domain name, so we point it to the old one for now. Ah. brochures. We should have something to hand out at the conference. Hm. The previous one was quite succesful, but we didn’t get around to making a new one. What changes do we really, really want to make so we can send it to the printer this week? Let’s take out the course schedule so the brochure lasts a bit longer, add a new course and announce the rebranding in the brochure.
By now, I hope you are curious about which conference we are going to sponsor, what our new name is going to be, and what our new offerings are. Be the first to know, and subscribe to our – soon to be revamped – newsletter – leave your e-mail address in the box at www.experienceagile.eu or contact me directly.
Credits: Thanks to Marc Evers for simplifying the text.
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.
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.
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:
- Routine processes are uninteresting strategically
- 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…
- Routine is boring
Routine software development culture :
“We are developing software – follow The Rules”
Routine processes are uninteresting strategically
“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. . .
“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”
“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:
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…
“Variable Expansion” photo by Andreas Kollegger.
Gerald Weinberg, for his work on organisational cultural patterns
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…
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:
|Complex – cause and effect are only coherent in retrospect and do not repeat||Knowable – cause and effect separated over space and time|
|Chaos – No cause and effect relationships perceivable||Known – cause and effect relations repeatable, perceivable and predictable.|
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:
|Complex – Anticipating||Knowable – Steering|
|Chaos – Variable||Known – Routine.|
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.
I’m still busy making sense from the Cynefin framework for sensemaking (for a brief introduction on how I see it so far, see the previous post on Cynefin). I’m puzzling on how eXtreme Programming could fit in several domains, and how choreographies from one domain to another would work. Richard Veryard, also raised the question about XP, in his blog post on a brief history of methods. He places XP in the ‘known’ domain. As I was re-reading the Cynefin paper this week I’m making some progress in understanding it. Or so I believe. As my thoughts went in many directions, I created a mindmap about how I could place XP in the various domains.
So far I find the chaos domain the most puzzling. I’m not sure thinking about software is appropriate in that domain. In chaos brainstorming and deciding on a choreography to one of the other spaces (preferably complex) might be more appropriate. I can see how XP could fit (and misfit) in known, knowable and complex – although in each context it has a different effect, and you can use it for a different purpose. I hope to work on the mindmap a bit more and then write a longer post about it.