me.andering – Willem van den Ende

I was at Marc’s yesterday, brainstorming some more topics for workshops. One thing that came up, about which we did not have a clue on what a workshop about the topic would look like, was Learning to see things as they are, rather than how they should be. This capacity enables one to see the future(s) more clearly, and have an open dialogue within a group about the future. If you don’t know where you are, how do you know where you’re going to?

A number of books and techniques I’ve been studying over the past few months have the theme of learning to see. Value stream mapping and causal loop diagrams are two such techniques. Peter Schwartz writes in his book The art of the long view about discussing multiple futures, rather than just the companies’ official future. The book Presence: Human Purpose and the Field of the Future discusses seeing things as they are as well.

While writing, I realize a workshop on Perspectives Nynke Fokma created would be about learning to see as well. Time to start working on that one.

Perhaps seeing things as they are is impossible, since seeing is done by perceiving. Nevertheless, striving to collectively learn too see, enables more robust and diverse forecasting.

Steve Denning concludes Use narrative as well as analysis with:

What hampers the creation of such new narratives is of course the corporate culture, which, as we saw in chapter 7 on Taming the Grapevine, holds the existing corporate story in place with an iron grip. The story of what the business is and how it works is not something that has to be argued for, but rather life as it is lived there, a matter-of-fact down-to-earth common sense apprehension of the obvious realities of the organization, which any wide-awake person would grasp if he would just open his eyes.

I couldn’t get someone to understand my hand-written mindmaps. Hubert Smits pointed me to freemind a cross-platform open source mindmap diagramming tool. It is very easy to install (RPMs for linux are included) and well thought-out: I can create a mindmap in minutes about as fast as taking ordinary notes – the most important actions are easily done with the keyboard. I’m usually not so thrilled about computerized diagramming, but freemind is easy and quick to use. Below, I quickly made a mini-mindmap to show how it works

Now I would like to have something similar to create readable diagrams of effects quickly…

Last week, a new weblog by Nynke Fokma went live, called Bommelstein. Welcome Nynke! . Nynke writes, amongst other things, about Systems Thinking and (In)Congruent Communication .

Recently I’ve been working with Marc Evers and Nynke on a site about systems thinking, with a weblog-aggreggator containing weblogs from systems thinkers and a wiki. We made this invitation:

Have you noticed that changing your software development method changes your organisation?

Wondered why the customer can’t keep up with the programming team?

What to do about it?

How to get a team to use unit testing?

Doubted whether the lack of unit testing is really the team’s biggest problem?

We found systems thinking to be a simple but powerful technique for finding answers to questions like these. When seeing organisations, projects, and teams as systems consisting of interrelated and interacting parts, one enables a relaxed focus on relationships as well as the whole and can easily reveal self-reinforcing feedback loops and not-so-obvious causal relations before they trip us up.

Would you like to change the rules of the game?

Figure out what you can do as systems thinker?

With a little self-esteem and imagination?

Co-create flexible processes congruent with desired products?

Increase awareness of your self and what is going on around you?

Turning on feedback loops?

Weave your thoughts with others in a wiki?

We cordially invite you to join us on www.systemsthinking.net

In the early days of the dot-com boom, reading the book Patterns of Software by Richard Gabriel made me aware of the risks of having too much (venture) capital for a project. If a project has too much money allocated to it, there may not be enough driving force to eliminate wasteful work.

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…

Marc Evers points me to It’s time to fix tech marketing by Thornton A. May in Computerworld. Mr. May says:

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.

he names as one of the causes:

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.

Even though I still like the Chasm model, I can relate to the mental models cause. IT departments have become quite diversified in their problems. In Cynefin terms, I think IT departments are moving from known to knowable or complex space. Therefore, selling one-size-fits-all products (e.g. ERP systems, which typically fit only in known space, because they assume an unchanging process) and services (e.g. software development based on proprietary methods) is no longer a viable long-term solution. Instead, vendors will have to look at patterns within the industry, and carefully select customers who they want to sell to.

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.

On October 26th, Marc Evers and yours truly facilitated a session of who’s dropped the ball at XP.BE in Leuven. I’ll post a few pictures I didn’t get around to posting so far. The difficulty I have with posting pictures of game workshops like these, is that it might give away too many ideas for new player – the game is most educational if you play it for the first time, and I wouldn’t want to give away ideas and configurations tried, because at each play new ideas come up. I also don’t want to give away the surprises Marc and I plan that disturb the gameplay . On the other hand, I would like to show the energy and level of engagement of the participants in the game. As usual, the players got the instruction to keep as many balls in the air as possible.

Graph of balls in the air over time, a Diagram Of Effects (DOE) and players trying out a new configuration

We first asked the players and an observer what happened (events). We used that to create a the graph of number of balls in the air developed over time, and used that as a start for a Diagram Of Effects. The DOE was useful in generating more observations and interpretation of events by the participants. In the debrief there was some debate between the participants as to how much creating the DOE contributed to creating new ideas for keeping balls in the air. Pascal Van Cauwenberghe suggested to do more rapid prototyping based on small changes to the DOE. So, after what started as the debriefing, we continued with a few prototypes and discussions, and ended up with a surprising solution (not shown here, to not spoil the fun at future workshops).

Setting up another configuration

Some lessons we learnt (as appeared during the micro retrospective at the very end of the session):

• Energy is low during the introduction. Recommendation to try for next time: skip the introduction.

• Energy was low while Marc and Vera were drawing second version of causal loop diagram. The group also did not feel they owned the diagram. Try next time: make the diagram in groups, and start using post-its for the DOE variables right away – that makes it easier to change the diagram. During a brief introduction we can introduce the main aspects of the Diagram of Effects notation by drawing a mental model of what the bosses (Marc and me) think is going to happen.

• Connection to the context (eXtreme Programming) was not clear to everyone. Marko van der Puil has written a great blog entry about how the XP values relate to this game and to Systems Thinking. I hope his weblog is going live soon, so everyone can enjoy it. In a succeeding session we can ask participants at the start of the workshop to think for themselves about relations to projects they participated in, and observe how the four values ( communication, simplicity, feedback and courage) appear in playing and discussing the game.

• Some players were wondering what effect the DOE had on the final configuration. Next time, we’ll try to cut gameplay as well as discussion short even sooner. Stopping gameplay is hard, since players enjoy playing a lot as you can see in the photographs.

• Prototyping is important: if you have an idea, try the configuration ASAP, so you get feedback on your idea.

We’ll be playing this game three times within one week, at XP Days in Mechelen, Karslruhe and London. The workshop in Mechelen is likely to have a good turnout – the conference is virtually sold out, and many participants indicated a preference for this session. The London conference is now also sold out, so that will probably be a busy session as well. I’m looking forward to meeting you at one of these conferences!

Together with Marc Evers I’m going to do a number of combined ballgame / systems thinking workshops at various locations in Europe over the coming month. This Tuesday, October 26th, we’ll be in Leuven at an Extreme Programming Belgium Users’ Group meeting.

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.

In the Extreme Programming mailinglist Kay Pentecost is raving about an interview with Johanna Rothman over at IT conversations on her book about hiring technical people and about Agile Project Management. I attended Johanna’s workshop on this topic at AYE last year, she has a many of useful techniques to offer – highly recommended.

I didn’t notice the IT Conversations site before – they seem to have a wide variety of subjects, both IT related and more people-oriented.

I’m driving to Enschede tonight to meet up with Laurent Bossavit, who’s in the Netherlands for EuroFoo.

Yesterday, Laurent wrote about Technology, sweet and sour

how he had to pay for WiFi service to notify me about his plane being late. In a sense, it is not in the best interest of airports to let your flight depart on time – the more time you spend on an airport, the more money you spend. For Schiphol Airport, the main source of profit used to be their shopping centre. I don’t know what happened after tax-free disappeared, but I guess not much has changed.

The dutch national railways (NS) have developed this system into a fine art. While punctuality of their trains has dropped to unacceptable levels (that was the main reason I bought a mobile phone, and after that a car several years ago…), they have at the same time turned around many of the medium and larger railway stations into shopping malls, with most of the restaurants and snack-places operated by the NS.

If the train doesn’t go on time, you are more likely to buy coffee or a snack, so the NS make more money on you. So, as a traveler you might be inclined to think that the goal of a railway or airline system is to bring you from A to B as quickly as possible, there might be multiple incentives for the operators, leading to other conclusions…

One new idea that emerged during the European XP Week trip was to organise Agile Open – an open space weekend on Agile (in Software Development and otherwise) in spring 2005.

Marc Evers and I discussed this idea with several people during the xp days and afterwards (Marc also blogged about this ). The idea is, that we’d like more time to explore topics that come up during xp days and regular conferences in depth, and have a place where people from around Europe (and possibly elsewhere) can experiment with new sessions and show them to various xp-days organisers. Most XP days (even though they’re completely independentently organised) now have a session submission and review process. This works pretty well, although something kept nagging me. Duncan Pierce spelled it out clearly to me after XP-days London:

We’re reviewing session descriptions, instead of sessions.

Even though we’re trying to be independent and objective, it is much easier to trust someone you know with organising a session than someone you don’t know. I talked to some peope who thought about organising a session for this year, but didn’t get around to it. The threshold to start is quite high if you’ve never done it and are unsure about your facilitation skills. I’m starting to get more comfortable with it myself, based on the good feedback I’ve gotten over the workshops I’ve been doing. Even with experience though, getting a session accepted at a conference remains a somewhat mysterious process.

At XP Day Benelux we nevertheless had many new presenters this year. I hope next year we’ll have more new presenters, helped by the Agile Open – we’re thinking of an open space conference, where the program is decided on by the particpants at the start of the conference. We are looking to grow an overview of supply and demand with respect to workshops on Agile. With a stimulus to present session ideas before Agile Open, as well as questions for sessions from people with only a question or problem and no idea on how to organise a session around it.

One thing we’re already looking for from the demand side is more technical and entry-level sessions for XP Day Benelux.

Another reason to organise Agile Open is a recurring theme in many ongoing discussions: how to sustain a viable agile consultancy business, software house or corporate department. These questions are currently mostly debated at the bar or local user groups (and Mary Poppendiecks’ XP2004 keynote). I believe it is worthwile to go in-depth on this theme with a larger crowd.

We now seem to have a critical mass of people who want to co-organise, as well as participate so we’re going ahead with it. I’m going to send out a mail with a cost-estimate and details so far tonight to those who reacted until now. If you’d like to participate or co-organise or know someone else who might be interested, please contact me or Marc directly. We’re looking forward to make this event a reality and expand the ideas we’re having so far!