Dreamfeed

At the Dutch Open conference in November 2005, I met Arie de Geus, the author of the book The Living Company. He held a presentation about Innovation and Sustainability (the conference theme).Arie has worked for the Shell Strategic Planning Group. He talked about playing is learning and learning through playing, based on his experiences at Shell. He has also been influenced by people like Jean Piaget. Playing is experimenting with a representation of reality. In many disciplines, people play around with ideas, models, concepts, before taking decisions. When engineers are going to build a new oil platform for instance, they build lots of models and (computer) simulations that are thoroughly tested and stressed, until they know enough to take the right decisions and build the actual oil platform.

Learning by playing helps to stimulate creativity and opens up all kinds of options, things one probably doesn’t think of without playing. It speeds up organisational decision processes.

In the discipline of management however, there is almost no learning by playing. Managers play with reality itself instead. This is very scary, leading to a lot of fear in organisations. In my experience, playing with reality itself and the resulting fear is also an important issue in IT (project) management.

A culture of fear in an organisation closes down options, and kills creativity and innovation. Fear makes people reject new approaches, they keep on trying more of the same instead. This only works for very simple routine decisions. In other situations, it leads to ineffective coping behaviour and very long decision times (some strategic decisions in Shell took up to 18 months…)

Making the transition from Fear to Fun is difficult - the culture of fear itself makes it even harder by making indiscussable what the fear is about, and even making this indiscussability undiscussable.

The Shell Strategic Planning Group has developed the practice of scenario planning to let managers play with different possible futures. Some more ideas on how to get from Fear to Fun, based on the discussions at the Dutch Open conference and on my own experience, are:

• let managers do simulations for strategic decision, e.g. using computer simulations (but let them make the models themselves, otherwise they won’t trust it and won’t accept the outcome);
• introduce a “managerial teddybear”, e.g. a consultant or a real teddybear - thinking out loud makes fear manageable, smaller, and makes the future ordinary;
• apply techniques like scenario planning and risk analysis in projects - play with different possible futures and all the bad things that could happen to a project;
• let people play with the often difficult person to person communication issues - one of the goals of our Balancing Act workshop.

In March, Willem and I will be running the Balancing Act - Simple Tools for Feedback, Courage and Communication session at XP Day France (23-24 March in Paris, the first XP Day in France) and at the SPA2006 conference (26-29 March in St. Neots, UK, formerly know as the OT conference). At SPA2006, Emmanuel Gaillot will co-facilitate.The Balancing Act session is about a number of people tools based on the work of the family therapist Virginia Satir. The session is highly experiental and intensive - almost no presentation, but a lot of doing, playing, experiencing and reflecting on your experience and your feelings. The session helps you to take a step in the transition from fear to fun in interacting with others (I’ll elaborate on the fear to fun theme in a next blog entry).

We are improving this session step by step, through several runs. We are also running the session with different co-facilitators, so that more and more people will get experience facilitating the session and the Satir tools.

So, if you’d like to learn how to improve your communication skills or if you’d like to cope with your co-workers (and yourself!) more effectively, and would like to have a lot of fun in doing so, come to XP Day France and/or SPA2006 and participate in the Balancing Act.

Hope to see you there!

Last week, I facilitated a risk analysis session for a customer. It was a very enjoyable and useful session, which has resulted in a list of important risks (with estimated probability and impact) and corresponding actions we are going to take.Good risk analysis and risk management is still uncommon on IT projects. One of the reasons is that thinking about risks is scary - people prefer to think of project success instead of all the things that could go wrong, or people are so scared of possible project failure that they avoid anything that even touches on risks, problems or failure. This can lead to the risks and the necessary mitigation and contingency actions becoming increasingly undiscussable, increasing the probability and impact of the risks, increasing the chances of project failure - the fear of failure becomes a self-fulfilling prophesy.

Doing a thorough risk analysis and managing the risks during the course of the project helps to make (and keep) these things discussable so that you can anticipate and respond using appropriate actions, which makes the risks less scary and increases the probability of project success.

I have noticed a number of additional effects of doing a risk analysis:

• It helps teams and organisations in making the shift from fear to fun in their work.
• The process of going through the risks, playing with the ideas of threats and possible project failure in a relatively safe environment (at start of the project, most options still being open), will reduce stress and panic at the moment when the risk actually materializes.
• It helps building and reinforcing a shared vision.
• Agile practices like short iterations, automated acceptance testing, early and frequent customer feedback, prove to be simple and effective tools for risk detection and mitigation. The last few years, I’ve been asking myself regularly how to “sell agile”, but I realised that this is not the right question: it’s about managing project risks effectively - something for which agile software development is an excellent fit.

A very good guide to doing risk management in IT projects is the book Waltzing With Bears by Tom DeMarco and Tim Lister.

In last week’s Automatiseringgids (a Dutch IT newspaper), I read an article about learning by playing (spelenderwijs leren in Dutch) as an effective tool to train people in ITIL (using a simulation of a Formula 1 race).Learning by playing is something I believe in and which I apply in workshops and courses. It was also one of the themes that emerged from the SoL Dutch Open conference we held in November 2005 - playing is learning, learning by playing - see also the description of the Fear to Fun session on the conference wiki (in Dutch).

The Automatiseringgids article described how incidents are handled in the simulation: the first time something breaks down, it is regarded as an incident; the service desk team passes it to the engineering team, who fix the problem. When the problem occurs more often, it is apparently a structural problem that needs a structural solution. This is something that management can judge and solve better than the engineering team can.

The Toyota Way of handling incidents is different - there are no ‘incidents’ there. A problem or defect doesn’t just happen, there is something in the process that causes the defect or the process currently doesn’t prevent the defect from happening. So it is always a structural problem. When a problem or defect is detected, the team stops the production line, identifies the root cause and fixes the process. Furthermore, there is no separation of engineers who do the fixing and managers who do the thinking - the production team together with their team leader are responsible for finding and implementing structural solutions.