me.andering – Willem van den Ende

In the Extreme Programming mailing list, Dale Emery points to a simple and interesting game that emerged during the agile development conference. You can read details on The Blindfold Game in Brian Maricks’ blog. I like this game, maybe I’ll try it out at our XP users’ group meeting

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.

I’m going to the Lean Summit in Noordwijk tonight, hoping to meet practioners from other disciplines than Software Development. After reading draft’s of Lean Software Development me and other people in the Benelux got interested in lean manufacturing and product development (as you could see from the Value Stream Mapping exercise we did at the most recent xp-nl).

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.

As XP2004 was drawing to a close, many interesting ideas came by. Ideas that stuck so far were:

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

I am still enjoying the XP2004 conference. One of the tenets of Extreme Programming is doing the simplest thing that could possibly work. Which means amongst other things, that is the responsability of a programmer to focus on what the customer really needs, and choose the simplest tool available to get the job done.

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.

Until june 21st I’ll be in Germany, first going to XP2004 in Garmisch Partenkirchen, where I’ll be hosting a Systems Thinking workshop together with Marc Evers (and attend other interesting sessions ). After that, I’ll be taking a brief holiday. If I can hook up my laptop to the web, I might just keep you posted.