So what is our session about? It introduces systems thinking using causal loop diagrams (also known as diagrams of effects, Systems thinking is a methodology independent tool for understanding team and project dynamics and for finding effective interventions. We will use an experiential approach through playing a ball game ("group juggle"). All participants will be involved, either as a 'player' or an observer. We ran this game as part of a larger session at XP2004. The image below shows participants at xp2004 playing a second round of group juggle.

This game is derived from The Systems Thinking Playbook by Dennis Meadows and Linda Booth Sweeney, and I highly recommend this one. At a systems thinking meeting last week, we played another ball game, warped juggle. It struck us, that these games are very versatile and can be used for many purposes, e.g. showing group interaction, mental models, experience organisational change in the small, and explain causal loop diagrams as we'll do at xp day.

Managing change is better done by starting at check, so John Seddon suggests a change cycle that consists of only three steps: Check Plan Do. I can relate to this, because I have experienced the power of this cycle in various activities:

• Weekly planning games work like this Check what has been done last week and how that affects the customers' situation, Plan what to Do in the next week. Very simple, but also very powerful, as the software evolves together with the customers' situation.
• Retrospectives fulfill the same role: Check the current state of your process by looking back on the past project (or iteration), Plan new ways to add value and eliminate waste, by looking at what we can do better next time and Do by having the retrospective right in between your current and next project, and using the results directly in the next project.
• A systems thinking techique, that of creating a causal loop diagram (also known as Diagram of Effects) also follows this pattern. Check being telling a story and drawing observable values and the effects they have on each other, Plan finding intervention points within the effects or changing the system by introducing other observable values and Do enacting the interventions or changing the system.

Playing the blindfold game at the last xp-nl proved this again - if you steer every 20 seconds, you won't get the blindfolded person anywhere near the target. With 5 second iterations, this is much more doable.

I've been rehashing a lot lately. I know it is not very useful, but it takes some effort to start "pre-hashing" so to say, thinking and acting towards the future. What helps me right now is writing (here or in my notebook), reading, talking to friends and going to conferences. Day by day, I'm experiencing and enjoying more about how the future wants to unfold ;-)

Having said that, I'm taking off for a an open space conference with fellow consultants in the French Alps, I'm curious what that will bring!

Using an agreed-upon protocol has the effect that People don't resent interruptions as much; they already gave permission for it. Another effect of agreeing on the protocol beforehand in my experience is that everyone on the team is aware that it is alright to admit you are stuck or don't know the answer. This lowers the barrier to ask for help a lot. Asking for help takes courage, but works much better in the long run - I see it as an opportunity to invite the whole team to work together on a problem, which usually creates solutions none of the individuals could have invented themselves.

Brian relates problems the players are having with steering a car, roleplayed by another person, with voice commands every twenty, five or one seconds to iteration length in an agile software development process. He notes, that many people have problems with one-week iterations (which are then similar to one-second feedback in the game), although they can often be taught to deal with them.

I've experienced a situation where a one week iteration was too long. At the end of a four week project, the customers had difficulty of thinking of enough new functionality for a full week, yet there was still work to be done. On the other hand, I also experienced one week iterations being to short, especially in the case a large refactoring has to be made to existing software.

Over the years, I've worked on projects with one week, two week, three week iterations, and before that in projects without iterations... Iterations are necessary in my book, to get feedback from the project and steer it, so it stays on course (or changes course if the context requires that). The relation to me between the game and the real-world is, that in real-world projects I find it worthwile to look at the effect the iteration length is having on the project (as Brian does in his reflections on the effect the number of seconds has on the time it takes to get the role-played car to the target). If you think iterations are too long or too short, change the iteration length for a few iterations, and evaluate (e.g. with an iteration retrospective) what difference it makes to your project. After the experiment it will be easy to decide if you want to keep the new length or not.

This is probably caused by two main factors:

• The software being used is complex and/or hard to adapt (this is especially so for Enterprise Resource Planning systems, where it is probably cheaper to adapt your company to the software than the other way around).
• The IT department, or whoever is responsible for modifying the software is not agile, and can not respond quickly to small change requests, necessary to support ongoing organisational evolution.

A solution towards the first problem, is to have workers rethink their processes in such a way, that the processes need less software to support them in the first place. That leaves developers more time to think hard about the essential software that remains. A solution for the second problem is to have developers and customers work closely together in short iterations. This is scary at first – because the developers can no longer hide behind technical jargon, but have to communicate with the customers/users in their language.

An example of this is the development of a help desk ticketing system for an Internet Service Provider that I guided. The chief of the help desk had noticed that not all problem reports were handled quickly by other departments. He therefore wanted a system that would enable him to track the tickets, so he could say how long problem reports took to be solved, and who was to blame if handling was slow.

A developer started on a requirements and design document. Based on the design document, the developers estimate was, that it would take two developers half a year to develop the system (I estimated it would take even longer).

When the project did get started, we managed to have the chief help desk, his boss and the two programmers present for the planning meeting. The boss didn’t want to pay for over half a year of development. If there were problem reports weren’t handled quickly, she preferred the various departments communicate with each other, and look for the root cause of the slowness. This required a much more basic ticketing system. After three iterations of a week, the basic ticketing system was functional enough to be put into production.