Pols Consulting

Jennitta Andrea has published a wonderful experience report in http://www.stickyminds.com/BetterSoftware called The Case of the Missing Fingerprint.

Well worth reading. Nice work.

I have noticed a couple of common problems when the team meet the business to estimate what they are going to do next:

1. There is too much talking and the estimating takes far too long.
2. It does not involve the whole team. Some people don’t feel confident to participate while others dominate the proceedings.

Here is a little technique that is worth trying if you find yourself in this situation:

1. Get someone to read out and quickly explain the task that needs estimating.
2. On a count of three (as if playing Rock, Paper, Scissors!), each developer presents a hand showing their estimate with a finger representing a unit of work. If you feel that the task is too big for 5 units of work, simply break the task down and repeat for the smaller tasks.
3. We take an average of the team estimates.

The nice thing about this is that it is quick, fun and appears to provides reasonably accurate estimates (probably because it involves everyone).

Here is a nice technique to remember!

Think of everyone having just two neurons, one of which triggers when you talk to them. These are:

1. You are an idiot neuron.
2. I am brilliant neuron.

So if you say, “this system will help you do your job better“, the idiot neuron will fire and they will disregard what you say. How could you possibly know when you have never talked to me before? Clearly you do not know what you are talking about.

If, on the other hand, you say something along the lines of “How could we build this to help you do an even better job?“, the brilliant neuron will fire and they will listen to what you have to say.

I like to think of the neurons I am triggering when I talk to people. It really helps me.

Its been a busy couple of weeks for me as experience reports chair of ADC.  We had 31 papers to review.

An interesting point for me, and worth blogging (well, Tim Mackinnon suggested I blog it) for anyone interested in submitting papers to future conferences, is how we decided on the final papers.

We tried to be as agile as we could (difficult as most reviewers live in different time zones). So we:

• Only asked for an initial abstract to whet our appetite.  There is no point wasting people’s energy writing a full paper if they are going to be rejected.
• Interviewed each submission in person, or on the phone so we could ask questions and explore the submission in more detail.
• Paired on the reviews.
• Had a conference call to tell each other what we liked and disliked.

The key aspect for me was using the Identify The Champion pattern for deciding on which papers to accept.This says someone has to advocate the paper for it to be accepted.  To advocate, you have to be willing to shepherd the submission and make it happen.  So when people said “we quite like this one, …“, I would say are you willing to advocate it?  Most times the answer was no.  It really helps focus the reviewers and keeps the quality of the papers hight.

The end result is we have 16 really interesting papers.  Hope to see you at ADC!

Some agile people have started using the term best practices to describe what they do (such as pair programming, test first). There are a couple of problems with this.

Firstly, there is no such thing as a best practice! Practices always depend on a context. These practices are not best in all situations. Sometimes you may not need them; sometimes you’d be better off doing something else. People rarely place the best practice in a context.

Secondly it sends out a negative message; we’re the experts and you don’t know what you are doing. While this may be true, it is not the best way of motivating and inspiring people to change!

It turns out that principles are more important then practices for getting people to change. If people understand the principles behind something they are better placed to recognize which practices best fit their need and why a particular practice would be worth adopting.