August 26, 2005

Release 8.1: Speed dating... speed pairing

There is a discussion thread going on (see the extreme programming yahoo discussion group) about the fact that switching pairs is effective and can help implement of other practices and principles.

The argument goes on about the fact that it is actually hard to switch pairs to often, and that it could have a negative impact on the capacity of the team to deliver their iteration plan.

Following this argument, I have been thinking about speed dating and how it could be compared to pair programming: let's call this speed pairing shall we.

As I was thinking about this post, I looked for more info on speed dating there . Here is what they say:

"Speed dating is a formalized matchmaking process or dating system (a variant of a meeting system where the purpose is to enjoy romantic or friendship dates rather than decide anything). It originated in Jewish circles in the United States as a way to ensure that more Jewish singles met each other in large cities where they were outnumbered by non-Jews. It has been made more popular by its use on dating game shows, e.g. Fifth Wheel, and has recently become popular in the gay community. Supporters argue that speed dating simply saves time, as most people decide if they are romantically compatible very quickly, and first impressions are usually permanent.

In the original idea of speed dating, men and women are rotated to meet each other for only eight minutes each, are forced to the next round no matter how much they are enjoying the interaction (or dread the next one), then submit to the organizers a list of who they would like to see again (a form of approval voting since any number of suitors can be approved). If there is a match, phone numbers are forwarded. They cannot be traded during the initial eight-minute meeting, to reduce pressure (especially on women) to accept or reject a suitor to their face.

Critics of speed dating say it's shallow and tends to reinforce first impressions, which are often shallow to begin with. A scientific view of speed dating is that eight minutes is more than sufficient to determine if the range of a mate's hormones, a key indicator of immunities, is complementary (different) from one's own. This is claimed by some researchers to be the key factor in the so-called "first impression", and since it is olfactory (smell-based), there is no need for two individuals considering child-raising to spend more time on first impressions, it being more important to "sniff out" other mates.

This view is often rejected by critics as reducing humans to dog-like status, sniffing each other and then running off to sniff others. Another objection is that dating has more purposes than the raising of children, and that the invention of speed dating by a religious minority intent on resisting assimilation (and thus resisting cross-breeding) is a cynical move to increase their own population relative to the majority.

Another criticism of speed dating is that it tends to put less extroverted subjects at a disadvantage, while those with low self-esteem have been known to experience depression or even attempt suicide if their efforts at speed dating are unsuccessful.

None of these views seem to contradict each other, and speed dating grows in popularity perhaps due to the very objections that have been raised to it.

Speed dating is considered, due to its low overhead and flexibility, to be akin to an agile method or open space conference. However, what's at stake in dating tends to be very different than the matters decided in an engineering or political conference."

Wooooh! Hold on a minute... "Speed dating is considered, due to its low overhead and flexibility, to be akin to an agile method[..]"? That's interesting and why not?

OK, back to my point then:

In speed dating, you get 8 minutes to decide if you would like to know more about somebody else (ie: exchange phone numbers, go on a real date, etc..), and then you jump to the next iteration (go to the next table and start from scratch with somebody new).

Normally, when everybody has met everybody, that's where the event stops. If there are people you like and if they like you as well, chances are you'll get their contact details and will be able to meet them for longer in the future.

Idea 1: what are the pros and cons of doing just that at the begining of every project when a team starts working together?
Pros:
- everybody will get to meet (speed pair) with everybody else very quickly, allowing them to find out who they think they will enjoy pairing the most with
- ideal pairs could be created within the team (if big enough...)
Cons:
- some people might never be chosen by anybody else!
- fixing ideal pairs might go against Common Code Ownership in the long term.

I can hear a bell ringing ;-) goto next table!

Release 8.1: Who/when to sign off stories?

I have a problem:

I am still ensure as to what criteria should be used - formally - to sign off a story at the end of an iteration.

I am a velocity preacher, and I also devote a lot of attention to the fact that the velocity figure we produce at the end of each iteration is meaningfull and can be reflected upon and discussed during our retrospective meetings.

Velocity is innacurate if:
- we have not estimated consistently tasks of similar complexity
- we measure delivered stories using inconsistent criteria for each.

I also find it really hard to actually define what "consistent story acceptance" should look like. So far, I have managed to still produce a Velocity that has "meaning" by making sure that the team agrees what the sign off point of stories should be, but I am not convinced I should feel particularly happy not to have an answer on this.

Also, on some projects, the number of people (who are genuine customers) who need to sign stories off as delivered is such that it is virtually impossible to sign off stories within 1 iteration. As I also preach the Story Velocity over the task velocity measurment, I cannot be happy with this.

I am still banging my head on that one, if anybody has any ideas or experience to share.....

August 25, 2005

Iteration 8: Planning Game

New stories:

Story ID: 8.1
Estimate: 10
Type: BAU
Status: Started
Value: 5

Description:

I want to have a minimum of 3 posts at the end of this Iteration so that the people that read this blog have something new to get from here.

Acceptance criteria:

- at least 3 posts are published within 1 month
- each blog entry is of good quality (quality defined by: innovative subject and related to XP or Agile)

Tasks:

- find some subjects to blog about
- write entries
- ensure that they pass the "quality" check
- publish

Iteration 7: Retrospective

Outcome:

I have published two entries in this Iteration. I have released some of the value I described during my planning game, but not all. There are still some non-XP related litterature that I am sure I could have mentioned here.

What worked well:

2 posts, and some comments!!! Boy, are some people actually readin my blog? am I getting famous? (thanks for your comment James ;-)))

What did not work so well:

The 2 comments I got were:
1- spelling mistake...
2- somebody who disagrees with me!!! (I know, that is actually a GOOD thing). But still...
3- it has taken me an awfull long time to do this retrospective and get starting on the next iteration!!!

Puzzles:

I still wish I could find a bit more time to work on this blog.... Repeat from Iteration 6, 5, 4...