Pols Consulting

Luke Hohmann is in London and has agreed to come along to XTC on the 17th November to describe and play some of his Innovation Games.

I became hooked on Innovation Games when I read an early draft of Luke’s book. Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start. I’ve found using Innovation Games really helps with situations like this. Luke has lots of practical ideas for Agile Teams.

Talk starts at 7:30 on the 17th Nov at  Zuhlke Engineering‘s offices  (43 Whitfield Street, London W1T 4HD).

It’s free, but please signup on the XTC website so we get an idea of numbers.

Many thanks to Luke for doing this and Keith Braithwaite for kindly offerring the use of the Zulke offices to run this session (knowing Luke, there will be lots of noisy audience participation so our usual pub venue wouldn’t work too well).

We were so lucky to get Dave Snowden as an XPDay keynote back in 2004.  One of the memorable moments was when he used the metaphor of organising a childrens party to explain the various approches to managing complexity.  It certainly resonated with the audience (based on the conversation in pub afterwards – a wonderful XP day tradition!).

Dave’s now uploaded a version to YouTube… Fantastic stuff. I love the deadpan humour.

One of my clients was telling me about the problems that they are having with “Aspirational Planning“.  I thought this was an excellent description of the problems lots of organisations have with planning.

Then it slowly dawned on me that he was serious – they really do create “Aspirational Plans”.  They are fully aware that they don’t reflect reality (as they take so long to prepare), but the senior management love to spend lots of time and (other people’s energy) creating detailed plans of what may or may not happen one day.

The teams on the ground just roll their eyes when I ask about these plans. I’m going to have my work cut out on this one.

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 (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 reviews 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.