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...

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.

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.

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.

The chicken Marc Evers and I used for the Systems Thinking workshop taped to the conference retrospective wall.

At XP Day Benelux we learnt that it is more like a Duck (have you ever seen a yellow chicken with feet made for swimming?). This came out of the Chicken Talks session. Originally, in the timeslot of the Chicken Talks, there was a session planned called Lightning Talks. As with any conference I guess, there are risks in the program. One of the risks for 2004 was that there would be no presentations submitted for the Lightning Talks. The Lighting Talks was intended as a session with brief five or ten minute presentations, presenters had to submit their talk before the start of the conference. The idea being, this would enable people to put last-minute ideas into the program, as the remainder of the program is already fixed several months in advance.

We did a risks analysis before the conference. Most risks did not materialize, the one for the lighting talk did. Since we had an overview of possible risks, it was easy to switch to mitigation actions for the few risks that do materialize.

As a mitigation action for the Lighting Talks Pascal van Cauwenberghe worked with session organiser Bernard van der Beken to invent an alternative session. The evening before the conference they had about three different ideas for a replacement session. To remain agile with respect to the program, we have no printed program leaflets. Instead, we put up the sessions on the conference website, and on a wall in the conference centre:
.Onwall Conference Program

I printed out the program the day before, and took a printer with me to print last-minute changes to the program and session handouts if need be. We decided to keep the new session description hand-written, so it would be more clear that the session had changed.

Pascal and Bernard came up with the name Chicken Talks, because attendees chickened out sending in lightning talks submissions, and the chicken plays an important part in the session. The session centered around a variation of the Talking Stick Protocol (also known as Circle Talks ). The chicken was used instead of a talking stick. The other variation was, that instead of asking for the stick, the chicken is thrown around. The person holding the chicken must speak (he or she is also the only one allowed to speak, as with the talking stick). When the speaker is done, he can throw the chicken to anyone else in the group. As the chicken is softer than a stick, this is safe to do. This variation of the protocol ensures that everyone gets to speak, which is quite useful with a group of technical people, as they are often quite introverted. I could not attend this session, judging from the reports of those who did, it was a great success. One of the outcomes of the session was, that the group decided the Chicken was more like a duck... So from now on, it shall be known as Ducky the Chicken ;-).

We've used the Chicken Talks at the newyears' reception of our extreme programming users' group two weeks ago, which also was a great success. I've added it to my facilitation toolkit. It was fun to see people throwing the chicken around, and observe how different people hold the chicken. It was especially good to hear people who are usually a bit on the background. If you try the chicken talks out, I'd be interested to hear how it worked for you!

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!

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

Neverheless, I went to the open space conference of the Dutch Society for Organisational Learning. The theme of this day was Unlearning. I had a great day, meeting interesting people from a variety of fields. Marc Evers and I put up a play of Warped Juggle on the planning board. We had a cozy session with five participants, which gave us some new perspectives on the Satir Change Model, amongst others - Unlearning happens during the chaos phase, and with scenario planning we might welcome chaos, rather than experiencing it as painful. We put up more output from this session on the SystemsThinking.net wiki.