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.

• organisational change projects where techniques (such as value stream mapping and ‘5s’) where applied, while maintining a command-and-control management structure (in fact, also executing the organisational change in this fashion). This approach was exemplified by e.g. General Electric and (to a lesser extent) General Motors.
• organisational change projects where a lot of attention was paid to empowering employees, getting everyone involved in changing their way of working (as exemplified by e.g. Fujitsu Services and Standard Life insurance), and driving organisational change bottom-up, with a supportive management.

Both approaches deliver large monetary savings and/or allow companies to increase sales without increasing staff size. I am in favour of the latter, and I suspect that change initiatives done in that fashion are more durable (they might actually start an ongoing process of emergent, self-organising change by the employees).

In his closing presentation James Womack said that Toyota was very liberal in sharing its’ way of working. I also saw figures, stating that Toyota is worth more (in monetary terms) than all of other major car manufacturers combined. If Toyota’s competitors choose the first strategy, there is indeed little to fear from sharing techniques, as Toyota will already have evolved their techniques further, since their people will continue to reinvent themselves and the company. It ain’t what you do, it’s the way that you do it…

One of the interesting things for me, is that eXtreme Programming already pre-eliminates some 'waste' for you, and helps in decreasing batch size (amount of functionality that can be planned and delivered) and increasing quality without adding quality-checking-after-the-fact. I'm curious to see in the future, how we can further improve speed, quality and customer satisfaction by applying lean techniques to our project (ehm, oh yes, that's becoming products now).

Mary Poppendiecks' talk at XP2004 was also quite interesting in that respect - if you want your software project to live a healthy long life, it is probably wise to look at it as product development, and manage it as such.

• solving problems by daydreaming
• research on presencing that is performed by MIT, and is supposed to be a kind of 'sixth discipline' for the learning organisation, being the 'flow of the learing organization', which is called Presencing
• Many german companies are reverting back to becoming an 'unlearning organization' - they hire army officers as managers in order to fight their crisis with a more directing, command-and-control style of management. Someone at lunch was actually working for such an organisation.
• the importance of cultural training, or at least cultural awareness in organisations. Organisational departments such as sales, software development, systems support, operations, all have a distinct (sub) culture, including preferred ways of communication.

Today I was reminded again of a kind of reason for not using or creating the simplest possible software. The Shoulds are so powerful, that even experienced Extreme Programmers can find it hard to resist. Examples of the shoulds are: separate content from presentation or its opposite (from 'naked objects' all objects should be representationally complete, everything is an object (which has been a favourite of mine for a long time) or they are not using design patterns.

The previous instances of moralistic programming are somewhat easy to recognize, because the 'should' or universiality assumption is explicit in the language. It becomes harder to recognize in situations where e.g. a database is added to a program, because the programmers in question always use databases (so it is an assumption), or the choice for a programming language is not taken, because it is more convenient to always use the same tool for the job.

I attended a session on XP Tools. It is easy to assume that such a session is on software tools, whereas XP has re-introduced a number of very powerful non-software tools, such as index cards and face-to-face communication. Many people apparently are still using ANT (an automated build tool)

To a certain extent, I don't think it really matters very much which tool one chooses, as long as the choice is conscious, and the tradeoffs for choosing one over the other are clear. Unlearning moralistic programming, and doing situational programming more often is a lengthy process for me. What I think helps is to keep on trying new things (I am exploring the SeaSide web-application framework again, which in an interesting way different from other ways to develop web-applications), listen to what other people are doing (conferences provide an excellent opportunity for that) and regularly starting new projects, so it is more often time to select a technology and process that is appropriate for the problem at hand.

Several exercises were about doing synchronized movement with a group of people, where no-one is an explicit leader. The intention of such an exercise is to carry it out well, and be aware of the people around you, especially the person to the left and the person to the right of you. One exercise was a yoga-exercise, which, as appeared from the debriefing was too difficult, so most people could only focus on their own movement and not that of their neighbours. Instead, they focused on the workshop leaders, to follow the movement, or just paid real close attention to their own movement. The remarkable thing was, that only two or three people exercised their right to ‘check out’ and no longer participate. Another option would have been to ‘stop the production line’, and remark to the group at the moment that the exercise was too difficult and could maybe be simplified. The others realised that the exercise was too difficult, but kept on trying to carry it out, only remarking the difficulty in the retrospective after the workshop. So, even in a workshop on self-organizing teams, the team wasn’t self-organized al the time - it worked well when the exercises were relatively simple, but with an exercise that was too difficult for a large majority of the participants, the self-organization broke down.

I saw a parallel to software development teams, where people lose track of their surroundings, as they are ‘in the zone’ focusing in on a difficult technical problem or solution. My conclusion: if you operate a group just above the boundary of its capacity, the capacity to self-organize will break down, and the group will (no longer) function as a team.