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.

You can now post your interest in participating at the agile open wiki. The goals of this conference are set by the participants, so you're welcome to add your goals to the wiki, or discuss them on the Agile Open mailinglist. The current round of goal brainstorming already generated some interesting ideas. We seem to be drawing people interested in Agile from inside and outside the software development community.

I want to be clear, that the Toyota Production System is not the Toyota Way. TPS is the most systematic and highly developed example of what the principles of the Toyota Way can accomplish.

I find The Toyota Way easy to read, it lends itself well to be read chapter by chapter while I'm sort of in the midst of a tornado this week: moving to a new house in Eindhoven, doing two consecutive nights of game workshops (Who's dropped the Ball with Marc Evers for xp.be in Leuven, and Game Of Goose with Nynke Fokma for Ordina in Nieuwegein), as well as working with ZeelandNet on their next round of improvement through Agile Software Development .

Misconception: TPS is a set of tools

Do you value the practices, or do you practice the values?

Many good American companies have respect for individuals, and practice kaizen and other TPS tools. But what is important is having all the elements together as a system. It must be practiced every day in a very consistent manner - not in spurts - in a concrete way on the shop floor.

Misconception: Lean equals Mean

This reminds me too much of the Six Sigma style methodology we are implementing at name of company witheld that I just hate!

Six Sigma is a statistical process for optimizing large manufacturing processes. Many small-scale software and hardware companies are now applying it on processes which are too small to consider applying statistics to.

TPS is not like Six Sigma. It emphatically calls on the creativity and spirit of the people involved to learn and solve problems. Terms like Eliminate Waste and Lean are rapidly interpreted by some people as 'downsizing' - I think that view is short-sighted:

Eliminating waste means eliminating steps that do not add value for the customer. This means only value-creating and value-adding activities remain. This leads eventually to high-customer satisfaction and a long-term relationship with the customer, which means for Toyota a stable and growing stream of revenue, leading to high profit margins, a large cash-reserve and long-term job security for the people working at Toyota. As the book says:

Lean is about developing principles that are right for your organization and diligently practicing them to achieve high performance that continues to add value to customers and society. This, of course, means being competitive and profitable.