• 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...

Value Stream Mapping is a technique that is already used in the context of Lean Manufacturing. At OT2004 I attended the workshop “Understanding the Software Value Stream” by David Harvey and Peter Marks (see http://www.ot2004.org/cgi-bin/wiki.pl/ot2004/?KkbagegehhgidslcbhbffcaabcbzencoukKk ) for details.

Borrowing metaphors from other domains, and applying them to the creation of software can be, from my experience, a dangerous thing. Even adding the word 'development' after 'software' is dangerous, since that also implies a metaphor.

I consider borrowing from manufacturing especially dangerous – I consider software 'development' to be a creative activity best carried out inside a 'living company' not a kind of machine.

Value Stream Mapping seems worth exploring though, so the main question that remained in my head after the workshop was: how can we map Value Stream Mapping to software 'development', without implicitly taking over the 'production metaphor'.

As described on http://www.mamtc.com/lean/building_vsm.asp:

Value Stream Mapping is a method of visually mapping a product's production path (materials and information) from "door to door". VSM can serve as a starting point to help management, engineers, production associates, schedulers, suppliers, and customers recognize waste and identify its causes. The process includes physically mapping your "current state" while also focusing on where you want to be, or your "future state" blueprint, which can serve as the foundation for other Lean improvement strategies.

Interesting results that could be achieved with the above are:

• Enabling all stakeholders in the process to see the whole picture. In my experience people usually only see their own part of the process. Optimizing one part without considering other parts might cause the whole process to deliver less value instead of more.

• Both materials and information is taken into account. In software development we work with information only, but since information is supported by VSM, this could be sufficient.

• Focusing on 'what is' and 'what could be'. Reflecting on process is a useful, and often difficult activity since assumptions have to be made explicit. Imagining what could be without taking the current situation into account, however, is much more difficult. There are other techniques (such as Diagrams Of Effects) that are useful, VSM could be a useful addition, since it takes information flows (rather than actions) into account.

Continuing the quote:

...

A value stream is all the actions (both value added and non-value added) currently required to bring a product through the main flows essential to every product:

• the production flow from raw material into the arms of the customer

• the design flow from concept to launch

The idea of adding 'non value added' steps to a value stream is to identify steps that are wasteful and can be eliminated. Adding everything makes brainstorming about the process easier, because different stakeholders might find different activities valuable.

Separating production and design flows is not something that is generally applicable to software. For instance, in my daily practice of software development, there is no visible distinction between design flow and production flow, because each step in a process based on Extreme Programming encompasses both production and design.

One of the things that came up after analyzing the value stream we created at OT, was that not only is value produced at multiple steps in the process, also very early on in the process value can be realized. Ordinarily, for a production line, I would think value is created at the end of the production process, when a product is handed to a customer and (possibly) money is exchanged.

In a process with short iterations, typical of agile software development, value is also created during planning meetings with the customers. For instance, customers get to re-think their business process while brainstorming their next wishes for software (and, as a consequence, perhaps changing the value ).

At the next xp-nl meeting (http://www.xp-nl.org/Wiki/XpBijeenkomst4.5 ) we're probably going to explore Value Stream Mapping further.