Spécialistes ou généralistes ?

Les équipes agiles sont plus efficaces avec des généralistes ou des spécialistes qui se généralisent

Thierry Crouzet vient d'écrire un billet sur Généralistes contre spécialistes. Il défend avec brio l'idée que les généralistes sont plus utiles que les spécialistes dans les périodes de changement.

Cette idée est défendue par le mouvement agile, chaque fois que la constitution d'une équipe est évoquée. Le tout petit nombre de rôles dans Scrum y pousse : pas d'architecte, par exemple, mais seulement des développeurs dans une équipe.

On pourrait comprendre qu'une équipe Scrum ne doit pas inclure de spécialistes. Il ne s'agit pas de cela. Dans mes équipes je me suis souvent appuyé sur des spécialistes pour avancer et il serait dommage de se priver de compétences pointues. L'idée est plutôt d'éviter l'hyper-spécialisation. Comme le fait remarquer Crouzet, il y a un risque d'enfermement du spécialiste dans une seule voie. Il y a aussi qu'une équipe de développement qui serait composée de spécialistes ne pourrait pas rester de taille réduite pour couvrir tous les domaines et que la communication y serait bien difficile.

La notion de Generalizing Specialist lancée par Scott Ambler est souvent reprise dans la communauté agile. Même si on trouve parfois un défenseur des spécialistes, la tendance est à avoir des équipes composées de personnes plus généralistes. Ils travaillent mieux en équipe et ils sont plus heureux.

Commentaires

1. Le jeudi 29 mai 2008, 11:38 par philippe voncken

Bonjour Claude,

"il y a un risque d'enfermement du spécialiste dans une seule voie"

Bien souvent, le contexte fait que le spécialiste est fort utile dans les projets informatique, agiles ou pas, et que ce "risque" d'enfermement dans une seule voie est bien souvent un avantage certain. C'est justement ce que l'on demande au spécialiste. Son expérience fait qu'il sait ou aller sans avoir à chercher dans toutes les directions, voies qu'il a déjà explorées, et donc cela fait gagner du temps aux projets tout en garantissant un niveau de qualité.

2. Le jeudi 29 mai 2008, 21:41 par Eric

Philippe, je ne suis pas d'accord avec toi. C'est exactement pour les raisons que tu décris qu'un spécialiste est dangereux. Lean nous a appris qu'il était bien plus rentable à long terme d'explorer toutes les voies, sans a priori sur la solution.

Principe que moi-même je devrais mettre en pratique plus souvent. Sur un projet récent, nous avons pris une décision sur un outil de reporting. Commentaire de l'architecte officiel (spécialiste, donc): "c'est le standard mondial". Commentaire de votre serviteur (non spécialiste, mais qui en donne l'impression par moment): "oui, je l'ai utilisé il y a quelques temps".

Total: 3 mois après avoir tenté par tous les moyens d'utiliser l'outil en question, nous avons dû changer notre fusil d'épaule et passer à un outil très différent. Cela nous a coûté cher en temps de dév mais aussi en management ("que s'est-il passé? à qui la faute?").

Conclusion: ne jamais, jamais donner un avis de spécialiste et rester modeste...

3. Le vendredi 30 mai 2008, 13:41 par claude aubry

Il y a quelques années j'aurais été d'accord avec Philippe. Maintenant, après quelques expériences difficiles sur des choix d'architecture faits par des spécialistes, je suis plutôt du côté d'Eric.

Et je suis flatté que 2 éminents consultants de Valtech se retrouvent à discuter chez moi !

4. Le vendredi 30 mai 2008, 14:42 par philippe voncken

Eric,

mon message est mal passé. On ne parle pas du même type de specialiste et peut etre pas non plus du même type de generaliste.

Je suis d'accord sur le danger de l'hyperspecialisation, mais l'hypergeneralisation est tout aussi problématique. J'aimerais donc recadrer sur ce principe.

J'ai dit: "Son expérience fait qu'il sait où aller sans avoir à chercher dans toutes les directions, voies qu'il a déjà explorées,.."

Je n'ai pas dit qu'un spécialiste ne doit pas être ouvert d'esprit et qu'il ne doit pas se mette à jour quotidiennement.

Pour ton projet, 3 mois me semble long pour se rendre compte qu'un outil ne correspond pas aux besoins. Il fallait remettre en question la proposition plus tôt en créant une tâche spécifique pour la recherche d'un outil plus adapté. C'est ce que je pratique en ce moment sur mon projet, et j'espere en tirer un bon résultat :) réponse dans 3 mois ;)

J'ai l'impression que ma définition du spécialiste informatique se rapproche de ta définition du généraliste. On fait appel à nous sur les projets pour notre expertise et nos connaissances. Apres il faut savoir se remettre à jour quotidiennement.

Au final je me rapproche plus de la définition de Scott Ambler avec son Generalizing Specialist qui nous correspond mieux. Un généraliste qui se specilise est-il plus un généraliste ou plus un specialiste ?

Ma pensée initiale était donc plutôt: Je pense que les spécialistes qui se mettent à jour quotidiennement sont plus utiles que des généralistes qui font un peu de tout mais qui ne maitrisent rien.
L'experience est irremplaçable.

Pour finir sur la modestie, je suis d'accord avec toi, il faut savoir prendre le temps de la reflexion face aux problèmes.

5. Le vendredi 30 mai 2008, 17:18 par Alix

Bonjour,
Spécialiste ou généraliste ... est ce vraiment un problème ?
Une équipe doit être agile à tous les niveau, en fonction du projet, des problématiques, de la phase en cours. Elle doit être adaptée au contexte.
Travailler par itération permet justement de modeler l'équipe, on peut former l'équipe ou une ressource généraliste pour le spécialiser si besoin, faire intervenir un spécialiste si besoin... etc
Attention aux caricatures, pour l'exemple de l'outil le spécialiste avait il les bonnes entrées pour prendre la bonne décision ?