Dave Thomas gave an amusing keynote, with a great, clear visual style that’s all the rage in geekland: little text, large fonts and beautiful images. He also had some nice effects: scrolling code, pages that looked as if they fell over. One sentence seemed reluctant to appear. Dave had to encourage it a bit. I’m not a fan of presentation effects (probably because I’m unable to do them well), but these effects worked. Enough about form, on to substance. Dave talked about “Cargo Cults” and “Angry Monkeys”.

Cargo Cult stands for every situation where we blindly copy something, without understanding it, to get some positive effect that we’ve observed. Angry Monkeys stands for every situation where we blindly do something, without understanding it, to avoid a negative effect that we’ve experienced.

Dave gave several examples of both systemic problems, reflecting his interests and preferences: real object orientation, dynamic typing, agile processes… He could have put up just one slide with, in big friendly letters: “THINK!”. But that wouldn’t have been as much fun.

There is only one practice

What came out of this keynote tied in with what Norm Kerth told us: perform regular retrospectives to improve your team, your practices, your process(es) and your process-changing process.

Hansei. Kaizen.

Evolution at work

Some of what Dave said resonated with Richard Dawkins‘ writing on evolution:

• You can’t capture everything in a taxonomy. There are no species; no classes. There are only individuals with sets of genes; objects with state and behaviour. Some of those individuals/objects are so similar that you can lump them together, but you’ll always encounter Duck-billed Platypuses.
• Evolution is a powerful tool. Luckily for us, we don’t have to wait millenia, we can guide evolution. Sometimes, we even succeed in improving the system, as we learn more. But, in the end, it’s always the world that decides if we are fit enough to pass on our genes.

During the train journey back to London, Duncan Pierce suggested that agile metrics should measure the “fitness criterion” of our process.

Tags: Systems Thinking, agile, SPA 2006

This afternoon, I’ll go to the “A good read” session, where a panel discuss a set of books. As you might have noticed, I love to read books. The one I’ve got with me to read on the train, is “The Ancestor’s Tale” by Richard Dawkins. Nothing to do with the day job. I just find evolution to be fascinating. Darwin has really changed the way we see the world, as few people have done.

In the Ancestor’s Tale, Richard goes back in time to find the common ancestors (“concestors”) of different species. For example, the first concestor is the species from which both humans and chimpanzees descend. Then come the gorilla’s, and so on. I’m currently 425 million years from today, where I meet with the ancestor of the Coelacanth and us. The Coelacanth caused a bit of a stir when it was discovered in 1938, because everyone believed that Coelacanths had gone extinct a long, long time ago.

Dawkins makes it clear that there’s no strict, clear boundary between species. It’s all gradual evolution, there are no large discontinuities. “Species” are just arbitrary classifications invented by biologists to indicate that two types of creature are sufficiently different to make the distinction useful. We are not descended from Chimpanzees, but we had the same parents. We are all siblings of Coelacanths, even creationists.

I’m reading the Ancestor’s Tale because I liked “The Selfish Gene“, which argues that the reason for all life is to propagate genes. It’s a great book, the argumentation is very convincing, but I fear the metaphors he uses are prone to misinterpretation. For example, what does it mean for a gene to be selfish? If you look long enough (a few million years or so), it would look as if genes have some sort of will or goal. Of course, it’s all massive, random processes with feedback from selection.

I read the Selfish Gene after hearing Dawkins in Steve Reich and Beryl Korot’s “Three Tales” music video.

Part of Dawkins’ text is:

“We and all other animals
are machines
created by our genes

A monkey is a machine
that preserves genes up trees

A fish is a machine
that preserves genes in the water”

Hmmmm… How’s that for a metaphor that can be misunderstood? Read the book to understand what Dawkins means by “machine”.

How do you decide which books to read? What’s the story behind the last book you read?

Tags: SPA 2006

Norm Kerth’s keynote looking back on 5 years of Retrospectives wasn’t surprising if you read the book or performed retrospectives. Many (most?) people in the audience have done or want to do retrospectives. Norm gave a great overview of Retrospectives and the results he and other retrospective facilitators have achieved. Performing retrospectives is good for the health of your team, the results of your project and your career. A simple and effective way to improve your process is the only thing you really need in your process. Everything else you need, will be introduced if and when you need.

An interesting and fun session about Product Managers. In the workshop we looked back at experiences with Product Managers. From these experiences, we determined what a product manager needs to do and what qualities we’re looking for. It is a very difficult job, juggling all those (possibly conflicting) demands.

Clarke Ching just wrote a blog entry about a book on “Agile Product Development”. Maybe worth checking out.

After a nice walk in very windy St Neots, off to Richard Mitchell’s session on modeling with views. Instead of making one big domain model, Richard creates smaller models, specifically for one (type of) domain specialist. He can then combine them in one, consistent model.

We talked a bit more about the theory of constraints and its application in software development. And then it’s time for the traditional last evening diversion. This year we had a wine and cheese tasting. Most people seemed to prefer the wine to last year’s Belgian beer. Apparently, Geuze Lambic is an acquired taste…

Wednesday

First, get some work done: handle registrations for Agile Open. If you want to attend, don’t wait to long to register, because we limit the number of participants to 40.

I’m looking forward to Dave Thomas’ keynote. “Cargo Cults and Angry Monkeys” sounds very interesting.

Read more at http://www.spaconference.org/cgi-bin/wiki.pl

Attended a workshop on Use Cases. The audience contained both use case users and sceptics, which resulted in some heated discussion. Not unusual for an SPA session. I did get some useful ideas to apply at work.

The day ended with a barbecue and drinks sponsored by Cincom, who valiantly keep on making, selling and using Smalltalk. One day, when I grow up, I want to do a real Smalltalk project again.

Monday

Marc Evers and I hosted the “Thinking for a Change” session this morning. The session went well: 3 out of 4 participants were able to find the root cause of their problem AND come up with some useful things to do about it. The problems were quite diverse:

• a software development coach having trouble communicating and working with the managers of the team
• having a good balance between home life and work
• how to reduce the spiraling costs of change in an application
• a business struggling to find enough money to survive the next few months, until their product is out.

In the evening we did a “Birds of a Feather” session on evaporating clouds. Again, two very different cases. One of them got to a start of a conclusion; the other managed to uncover a whole set of assumptions. To really resolve it, both parties would need to go through the exercise, to get a better understanding of the other party’s position, reasoning and assumptions.

In the bar, after dinner and drinks, I joined another group making a Current Reality Tree and a Future Reality Tree. Today was a Thinking Processes day.

Retrospectives in enemy territory

You know retrospectives are good for you. But what if you can’t hold a “real” retrospective? There could be many reasons:

• We don’t have any time
• We don’t feel safe
• We don’t do silly, fluffy stuff like that
• We don”t need to improve any more

Do you give up? No, that’s the kind of situation where you really need a retrospective.

Undercover retrospectives

Don’t organize retrospectives.

1. Find some excuse to have a celebration. The end of a release or iteration. Two weeks without a build failure… Use your imagination
2. Go out and get coffee and pastries. Or soft drinks and pizza. Take away Chinese…. Be creative
3. Invite the team members, your customer, system engineers who put your software into productions, DBAs who nurse your precious data, people from other teams who helped you get to this success. Thank them for making the reason for the party happen.
4. Now comes the devious bit. Get people talking about what went right. Ask them “If you could change one thing, what would it be?”. Ask them if they would like to research something new. Make mental notes of what people say (I don’t recommend alcohol at the celebration: you’re unlikely to remember what was said, the next day).
5. Make it happen. Implement the suggestions; start research. By the next celebration, everyone will be pleasantly surprised that you listened to them and took their ideas seriously.

Try it! It doesn’t cost a lot of time and money, but it does wonders to your team.

XP Day France is done. On to Great Britain to attend SPA2006.

The conference starts tomorrow afternoon. Before that, a few early birds are having dinner at a restaurant near the conference center.

I’m off to meet Rachel Davies, Andy Moorley, Willem van den Ende, Marc Evers and Norm Kerth. Norm wrote “Retrospectives”. If you haven’t read it yet, go out and buy it. Now.

As someone said: “If it doesn’t have retrospectives, it isn’t agile.“. I agree. Now, who said that?

At the XP.BE user group meeting hosted by ERG Transit Systems, we ran a workshop on “Management metrics”.

The people at ERG wanted to introduce some metrics to get feedback on their process improvement efforts. However, metrics can be dangerous. “You get what you measure”, but what you measure may not be what you intended.

We used a workshop format designed by Jason Gorman and Duncan Pierce to design, break and improve metrics. The session went like this:

• we formed 4 teams
• 3 people from ERG presented 4 requirements for metrics, one for each team. For the rest of the session, they acted as “onsite customer”
• each team designed and presented a metric to satisfy the requirement
• each team received another team’s metric and tried to “game it”, to subvert it to reach the opposite of the desired effect, or to score as high as possible with the least amount of effort. This was the fun part.
• each team then improved their metric, taking into account the possible “misuse”
• our customers performed the acceptance test. Each metric had to pass two tests:
  1. Would our customers be able and willing to implement this metric tomorrow?
  2. Would the developers want to work in a team that used this metric?

3 out of the 4 metrics passed the user acceptance tests. The fourth might too, with a bit of work. Not bad for 90 minutes of work!

Some things I learned about metrics:

• No metric is fraud or misuse-proof, therefore people have to want to use the metric correctly. If people want to game the system, they can be very creative.
• Metrics that take a noticeable amount of time and work to collect will not last long
• It’s better to aggregate data, because errors in the individual items tend to cancel each other out. E.g. it’s easier to track the estimates of a whole release, rather than the estimates of each individual feature
• It’s better to look at team results, rather than individuals, because of the aggregating and because that motivates people to work as a team. This is related to the “Reward one level up” rule I first heard from Mary Poppendieck.

I ‘d like to align metrics with the “Throughput Accounting” measures. I’ve added an “Idea for Session” about this topic on the Agile Open site. How about you?

More useful info and books on the wiki.

Marc Evers and I will host a session on the Theory of Constraints’ “Thinking Processes” at the SPA 2006 conference.

The session is, not coincidentally, called “Thinking for a Change”, after the Thinking Processes book by Lisa Scheinkopf, that introduced me to the subject.

We will introduce “current reality trees”, “transition trees” and “future reality trees” by applying them to real problems that participants bring to the session. We will be “learning by doing” by taking small steps: explain part of the technique, apply the technique, reflect, explain another part…

We don’t have the time to deal with the “Evaporating Cloud” technique during the session, but we will run a “birds of a feather” session about it. The previous entry contains an example of the use of the evaporating cloud. Expect more examples of the techniques in upcoming entries.

The conference takes place in St Neots, Bedfordshire, from 26 to 29 March.

Some of the interesting sessions of the conference:

• These are some of my favourite tools by Willem van den Ende and Marc Evers invites participants to bring in and share their favourite tools. These don’t have to be physical, technical tools… Willem and Marc probably prefer them not to be.
• Planning and tracking security requirements by Johan Peeters explores the use of “Abuser stories” to explore and plan security requirements.
• Designing metrics for agile process improvement by Jason Gorman and Duncan Pierce lets participants design, test and refine metrics. I attended this session at the London XP Days. It’s a fun learning experience. You’ll never look at metrics the same way again.
• Jidoka in software Development by Kevin Rutherford explores the application of “Jidoka” from the Toyota Way to software development. I attended this session at the Benelux XP Days.

See you there!