Let’s say you’ve developed a piece of cool technology: some really effective image recognition software, for instance. You then think hard about how you can commercialise this and come up with a great idea: a photo-sharing that automatically tags the uploaded pictures. Perhaps you could teach it to learn faces of family and friends – wouldn’t that be cool?

What you’ve just done, my friend, is generated a problem to fit your solution. And you’re already in trouble. You’ve got a hill to climb persuading people that they have the problem that you’re solving. Because you’re generating the problem, you’ve automatically got woolly requirements that are just begging for scope-creep and half-arsed implementation. When I said “wouldn’t that be cool” in the previous paragraph – that’s a clue. You might have struck lucky and hit a genuine pain-point for people, but chances are you’ve got another failed technology project on your hands.

Now let’s imagine you’re Flickr. You keep getting requests for automatic tagging from your punters, so you create a project to deliver just that. You are fulfilling a known need, so you don’t need to work as hard to market the idea and you’ve got something to refer to when eliciting the requirements. Of course you’re not guaranteed success because there’s always room to screw things up, but you’re in a much better position than when inventing a market for a cool technology.

Lean has the concept of pull. Rather than produce as much of each part as possible assemble them into cars and then try and sell those cars, the sale of a Toyota ripples up the system ultimately triggering the manufacture of parts to create a new car (Kanban). Last week at Agile North, Chris Matts reminded us of the car parks full of unsold British Leyland cars during the seventies, which were a result of push manufacturing. Like British Leyland a lot of software projects are based on push rather than pull, and has anyone noticed what happened to the British car industry in the last 30 years? Yes, it’s now pretty much entirely Japanese.

Last year I reported on a company introducing a single metric for measuring development team efficiency. I predicted it would be a harmful failure. Recently I had on update on how it was all working out. And… err… I was wrong.

As it turns out the people running the programme were quite sensible and smart: instead of driving teams to a particular target, they simply measured and investigated anomalies; that way they uncovered gaming (such as the team checking in open source projects to affect their score), and were also able to feed back their findings into the metric. Interestingly they found that the teams adopting Agile practices tended to core more highly.

In his book The Power of Intuition, psychologist Gary Klein recommends that metrics be used as trip-wires rather than guides: when metrics breach certain levels then that is a cause for investigation not immediate action.

Well done the metrics guys at, err the big company. And as for me – well sometimes it is a pleasure to be proved wrong.