Le consommateur n'est pas le client, c'est le produit

The consumer is not the customer, it is the product.

Autrement dit, lorsque nous utilisons, par exemple, Google, facebook, etc. nous ne sommes pas les clients de facebook. Nous sommes en fait leur produit, qu'ils vendent à leurs vrais client.

C'est une des très bonnes remarques faites par Bruce Shneier dans ce très court discours que je vous recommande : http://www.youtube.com/watch?v=I6ZkU2fUM5w

5 questions à se poser sur un projet

Voilà 5 questions à se poser pour diagnostiquer un projet que je voudrais retenir (parmi d'autres). Elles sont extraites du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :

Have you delivered running, tested, and usable code at least twice to your user community in the last six months?

Did you get together at least once within the last three months for a half hour, hour, or half day to compare notes, reflect, discuss your group’s working habits, and discover what speeds you up, what slows you down, and what you might be able to improve?

Can you tell your boss you mis-estimated by more than 50 percent, or that you just received a tempting job offer? Can you disagree with your boss about the schedule in a team meeting? Can people end long debates about each other’s designs with friendly disagreement?

Does it take less than three days, on the average, from the time you come up with a question about system usage to when an expert user answers the question? Can you get the answer in a few hours?

Can you run the system tests to completion without having to be physically present? Do all your developers check their code into the configuration management system? Do they put in a useful note about it as they check it in? Is the system integrated at least twice a week?

Alistair m'a tuer

Extrait du chapitre 2 de Crystal Clear: A Human-Powered Methodology for Small Teams d'Alistair Cockburn :

Even with the best of intentions, developers will work on things that only randomly bring business value if they are not told what will provide business value.

Je suis un peu désespéré de lire ça mais bon... heureusement il y a d'autres choses intéressantes à retenir de cet ouvrage.

agilité, auto-organisation, charrue et boeufs

The best architectures, requirements, and designs emerge from self-organizing teams. (http://agilemanifesto.org/principles.html)

Je suis 100% d'accord avec ce principe.

Mais attention à ne pas mettre la charrue avant les boeufs. Une équipe auto-organisée ne se décrète pas, elle se constate. On peut mettre en place les éléments qui lui permettront de s'auto-organiser, bien sûr, mais quels sont-ils, ces éléments ? Et qui les met en place ? Un leader ? Un manager ? Un chef ? Mais alors cette équipe est-elle auto-organisée ? Ou est-ce que ce qu'on appelle une équipe auto-organisée est simplement une équipe livrée à elle-même ?

J'ai peur que le principe ci-dessus soit parfois mal interprété :
- OK ! Il me suffit de les laisser s'organiser comme ils veulent et ils vont me pondre un super truc.

Ce qui est cher est souvent rare mais tout ce qui est rare n'est pas forcément cher.

Si ce principe nous dit que, souvent, les meilleures choses ont été produites par des équipes auto-organisées, il ne nous dit pas qu'il suffit de livrer une équipe à elle-même pour qu'elle produise les meilleures choses.

Dommage que, parmi les 12 principes du manifeste agile, celui de l'équipe auto-organisée revienne si souvent dans les conversations et celui-ci si peu souvent :

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Si j'étais cynique je dirais que c'est bien pratique, pour un manager, une équipe auto-organisée mais que, a contrario, trouver des gens motivés et accorder sa confiance, est un exercice infiniment plus complexe.