This post is currently only a draft. Input on how to improve the structure is very welcome

“A journey of a thousand miles begins with a single step.” – Lao-Tzu

When doing architecture, we always have to content with the present state of the system. It is extremely tempting to ignore this picture of the ugly system and create your vision of how things should be in the future. It is also very easy to get people to agree on such a vision. But somehow, we never get there. Have you ever wondered why that is?

Most people are pretty good at making a plan for how things should be in the far future. But we’re not sufficiently prepared to make a plan about how things should be right now. This is what I mean when I say we suffer from too little myopia.

As a tool to get there, I have found the Twelve-Three-One paradigm useful: We have a goal for what we should achieve in twelve months, three months and one month. The twelve month perspective is our goal – for example to change from EJBs to POJOs, to consolidate four applications on one server, or to deliver our big project. When you’re planning, this can be extremely fuzzy without putting you at risk. The three month perspective shows the direction we’re going to get there, for example, exchanging your entity beans with Hibernate, or duplicating all applications to the target server and slowly moving all dependencies to it, or to put a limited part of our system into production. This can be vague, but should represent our current working hypothesis on how to get there. The one month perspective shows the next step. It should be as finely planned as you require to get anything done in our organization (for example: copy the foo.cfg file to server-1 and modify these settings).

(more…)

Update: Added retrospective result example

I learned by favorite team building exercise on the ROOTS conference in Bergen three years ago. Alistair Cockburn conducted a great workshop that really drove home the lessons of iterative development at the same time as it showed a very useful technique for conducting retrospectives. I have later conducted the same exercise as a workshop in different situations. Maybe the most fun occasion was Oslo XP Meetup March 2006

The workshop works like this: The participants are divided into teams of six or so. It works best with about four or five teams. Each team is further subdivided into “developers” and “customers”, which sit apart during the workshop. When the exercise begins, the “customers” will be given a picture on a piece of paper. They are to describe the picture to the developers using only written instructions. Only one “customer” can visit the “developers” at any time. The teams are given five to ten minutes to plan their work before the exercise begins. Then they are given ten minutes to complete the first picture. After they have completed the picture, the “customers” and “developers” join together to do a quick retrospective for the next round. The exercise is then repeated.

(more…)