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.

None of the participants, including myself, had much prior experience with Value Stream Mapping. Everyone involved was just very keen to learn.

After a 5 minutes introduction of the technique, we just starting by doing, working on a value stream from one of the participants. Everyone chipped in, and as we went along we developed our 'diagramming technique'. Since our new office didn't even have a flipchart yet, we settled on using index cards to create our map.

As we went along, we clarified the meaning of the stations and queues, discussed about using average times, probability distrubutions or numbers from just one project.

At the end all of us understood much more about value stream mapping (you can read our findings in Dutch.

It often happens to me, especially when sending an e-mail with a question, that I come up with the answer right after having asked the question. If that happens to you, you don't really need a person to ask the question to, you could do just as well ask a teddy bear for help. Often the answer becomes clear when you have articulated the question properly.

Recently, my colleague Thijs Janssen presented Erik and me with a teddybear.
Erik and I often thank Thijs for helping us solve our problem, while actually, we solved it ourselves right after asking him a question...