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).

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

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.

Well worth reading. Nice work.

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).

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.

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!

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.