LE GOUROU (V1)

Le gourou s'est rendu indispensable pour l'organisation. Il maitrise un savoir faire incontournable. Les développeurs viennent le consulter dans son antre. Il dispense conseils et solutions techniques à la demande.

Il intervient rarement à plein temps sur un projet mais plutôt ponctuellement lors d'opérations de sauvetage.

Le gourou est une évolution de l'architecte, du moine codeur ou plus rarement du pragmatique. Plus particulièrement, il est l'évolution ultime du moine codeur. A force de se spécialiser dans une technologie stratégique et par rétention d'information, le moine codeur sécurise son avenir en devenant enfin un gourou.

TRAVAIL EN ÉQUIPE

Généralement, le gourou intervient ponctuellement dans les équipes. Il détient une position transverse à tous les projets et à toutes les équipes. Cette situation présente l'inconvénient de la solitude et l'avantage de ne jamais couler avec un projet en difficulté.

RELATIONS AVEC LES AUTRES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le gourou se moque doucement du folklore du collectiviste.

LE STAGIAIRE (V1)

Le stagiaire est au plus bas de l'échelle sociale dans l'organisation. Il est de passage et corvéable à merci. Parfois son travail est utilisé.

LE TRAVAIL EN ÉQUIPE

Le stagiaire est rarement réellement intégré à l'équipe.

RELATIONS AVEC LES AUTRES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le stagiaire est ignoré par beaucoup, sauf par son maitre de stage (quoique...) et par le collectiviste.
Il retrouve d'autres stagiaires lors des pauses et des repas.

LE COLLECTIVISTE (V1)

Le collectiviste vit pour l'équipe. Selon lui, les individus se réalisent dans l'équipe. L'efficacité de l'équipe est la clé de la réussite du projet. Il est constamment à la recherche de pratiques permettant à l'équipe de s'améliorer. Le consensus, l'auto-organisation et l'amélioration continue sont sacrés.

Le collectiviste a trouvé son salut dans le développement logiciel Agile. Voilà enfin une démarche centrée sur l'humain. Bien sur il est ScrumMaster ou coach Agile. S'il le pouvait, il ne ferait d'ailleurs que cela. Ses heures de gloire sont les stand-up meeting (il y en a un par jour!), les réunions de planification, de revue et LA RÉTROSPECTIVE! A l'occasion de cette réunion qu'il transforme en véritable messe, il sort de ses livres des outils anglo-saxons pour aider les équipiers à s'exprimer. Il prône de très courtes itérations. Cela multiplie la fréquence de ces moments de partage en équipe.

Certains recherchent les anti-patterns dans le logiciel et remanient vers les design-patterns. Lui détecte les anti-patterns comportementaux et remanie l'équipe vers des patterns organisationnels.

LE TRAVAIL EN ÉQUIPE

Le collectiviste mise tout sur le travail en équipe. Il est intiment convaincu que le travail de l'équipe est supérieur à la somme des contribution individuelles de ses membres. Il organise les tours de croissants le Vendredi, les rétrospectives d'itération, les repas d'équipe, les tours de tables, les pauses café en groupe, le démarrage de la bouilloire et la rotation des binômes.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le collectiviste s'extasie devant le binôme, symbole de partage.
Le collectiviste cherche à débarrasser l'équipe du moine codeur, cet infâme individualiste..

L'HOMME/MOIS (V2)

L'homme/mois fournit un mois de développement par mois.

LE TRAVAIL EN ÉQUIPE

Les hommes/mois se cumulent. Il parait que N hommes/mois travaillant en équipe pendant 1 mois développent comme un homme/mois pendant N mois. Ceci expliquerait pourquoi certains managers raffolent des hommes/mois. Il parait aussi que l'homme/mois est un mythe, comme l'affirme un certain Brooks.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

L'homme/mois apprécie l'architecte car il lui permet de faire sans penser.
L'architecte apprécie l'homme/mois car il lui permet de penser sans faire (Merci Thomas L. pour cette remarque ;o).

LE BINOME (V1)

Le binôme ne développe jamais seul. Son partenaire n'est pas son siamois, il permute volontiers. En général, il est une mutation du développeur pragmatique.

LE TRAVAIL EN ÉQUIPE

Il travaille en équipe: elle lui fournit ses partenaires.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le binôme est un pragmatique. Il trouve que le moine codeur l'a rejeté impoliment lorsqu'il lui a proposé de binômer.
Il trouve que l'architecte travaille bien seul ...

LE PRAGMATIQUE (V1)

Le développeur pragmatique est un praticien. Il pratique les tests, le remaniement, la programmation par assertions, la programmation par contrat, l'intégration continue.

LE TRAVAIL EN ÉQUIPE

Il travaille en équipe: il sait qu'il n'arrivera jamais au bout du projet seul.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Il trouve que la conception de l'architecte n'est pas encore pertinente car non testée.
Il rappelle au moine codeur et au cowboy codeur qu'ils ont cassé le build et que leur code n'est pas couvert par des tests.

L'ARCHITECTE (V2)

L'architecte pense, anticipe, modélise et documente. Désormais, il est au-delà du code et des tests. Éventuellement, il accepte de prototyper une de ses idées.

LE TRAVAIL EN ÉQUIPE

Il travaille en équipe: l'équipe est là pour transformer ses architectures et prototypes en produits opérationnels. Elle concrétise ce qu'il a pensé.

MUTATION CONNUE

Une mutation de l'architecte est assez répandue: l'expert en processus de développement. Il sait comment l'équipe doit travailler. Lui aussi travaille en équipe: l'équipe développe en appliquant son processus. Son outil préféré est souvent la présentation Powerpoint.

Ces deux personnages ont en commun le don de penser pour ceux qui font.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Il se méfie du cowboy codeur car il ne l'écoute pas.
Il n'apprécie pas le moine codeur car il ne fait que ce qu'il veut.
Le pragmatique l'irrite car il a un avis à proposer.
Le binôme l'irrite car ils sont deux à avoir un même avis à proposer.
L'architecte apprécie l'homme/mois car il lui permet de penser sans faire (Merci Thomas L. pour cette remarque ;o).

LE COWBOY CODEUR (V1)

Le cowboy codeur n'a pas froid aux yeux. Quand il faut développer, il code. Gestion de versions, conception, modèles sur un tableau blanc et tests ne font pas partie de sa panoplie. Le débuggeur suffit. Un build cassé est un étape transitoire et sans conséquence en attendant qu'il finisse de coder.

LE TRAVAIL EN ÉQUIPE

Le cowboy codeur travaille en équipe : il sait qu'il ne pourra pas tout coder. Aussi, il parait qu'il existerait d'autres activités que le codage et il faudra bien que quelqu'un d'autre s'y consacre. Bref, l'équipe ne lui pose pas de problème tant qu'elle ne le déroute pas du codage.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le cowboy codeur ignore l'architecte sous toutes ses formes (concepteur et expert en processus).

LE MOINE CODEUR (V1)

J'entame une galerie de portraits. Ils caricaturent des développeurs avec qui j'ai eu l'occasion de travailler. Il ne s'agit pas de personnes mais plutôt d'attitudes. Parfois ces comportements sont temporaires, périodiques ou tenaces. Peut être avez-vous rencontré certains de ces développeurs? L'exercice n'est pas professionnel voire un peu cruel, mais cela fait du bien. En tout cas, n'hésitez à me proposer d'autres candidats en laissant des commentaires!

Dans la mesure du possible, je vais essayer d'illustrer ces développeurs en Lego. Si je n'y arrive pas, je reviendrai au dessin.

La première caricature est dédiée au moine codeur. Pour le décrire, je lui avais déjà consacré une petite bande dessinée.

Le moine codeur est un solitaire, un reclus. L'équipe est une contrainte. Elle le gène et le ralenti dans son travail. Il s'isole pour pratiquer son expertise. Il partage information et connaissances au compte goutte. Ainsi, il est et restera indispensable et incontournable. Il sait ce qu'il a à développer et en conséquence consulte exceptionnellement le client ou son représentant. Les notions de spécifications, backlog et priorités ont été inventés pour piloter les novices.

LE TRAVAIL EN ÉQUIPE

Il n'a de pas de temps à consacrer au travail en équipe.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le moine codeur est un cowboy codeur solitaire et reclus. Pour lui, les binômes sont des faibles.

LE SOCLE TECHNIQUE

Les bons résultats de nos pratiques éveillent la curiosité au sein de notre organisation. En conséquence, nous communiquons beaucoup en interne pour répondre à la demande d'information.

Malheureusement, nous sommes maladroits dans nos communications puisque certains messages essentiels ne semblent pas passer efficacement. Nous voyons bien que les pratiques d'équipe et d'organisation séduisent et retiennent l'attention. Pourtant, ces pratiques ne sont viables que s'il existe un très solide socle de pratiques techniques. Produire des incréments de produit en courtes itérations mène à l'échec si ce socle technique n'est pas en place.

Ce socle est constitué de rigoureuses pratiques techniques telles que le développement piloté par les tests, l'intégration continue, la programmation par contrats et la programmation orientée-objet. Le liant de ces pratiques est la recherche de l'excellence technique, à tout instant. Les solutions médiocres doivent être améliorées au plus vite pour ne pas augmenter la dette technique du projet.

Malheureusement, ces pratiques sont moins séduisantes que les pratiques d'organisation telles que les stand up meetings, les backlogs, les réunions de planification et de rétrospective et le pilotage par Kanban.

Étant donné le type de produits que nous développons, l'excellence technique est une exigence absolue. Dans le sens premier du terme, les tests sont vitaux dans notre créneau. Le pire qui pourrait nous arriver serait d'adopter les pratiques d'équipe et d'organisation en délaissant le pré-requis technique. Cela mettrait en péril le projet et donnerait une véhiculerait à tord une réputation aux méthodes agiles.

Sans le même raisonnement, le pire qui pourrait nous arriver serait de louer les services de consultants qui ne seraient pas à 100% intégrés dans les équipes et qui ne s'impliqueraient pas personnellement dans l'application des pratiques techniques. Au risque de m'attirer les foudres de certains professionnels, je suis convaincu qu'il est plus pertinent de pousser des coach ayant un profil technique au sein de sa propre organisation comme recommandé dans le Toyota Way.

THE ENTERPRISE AND SCRUM, KEN SCHWABER

En plus d'un an, nous avons beaucoup travaillé sur la mise en pratique de Scrum. Notamment, nous cherchons des solutions pour notre équipe qui monte encore en charge. Nous sommes dans le cadre d'un gros projet de développement.

Alors, je me suis beaucoup documenté sur Scrum et avec Nicolas Blanpain nous avons même effectué la formation certifiante ScrumMaster.

J'ai commencé par la lecture de Agile Software Development With Scrum puis de Agile Project Management With Scrum. Je viens de clore la trilogie de Ken Scwhaber avec The Enterprise And Scrum.

LA FOLIE DES GRANDEURS?

Ken a un sacré appétit. Il voit grand. De plus en plus grand.
Etape 1: Scrum permet de bien piloter un développement de logiciel (Agile Software Development With Scrum);
Etape 2: Scrum permet de bien piloter un projet. Scrum ne se limite plus au développement de logiciels. (Agile Project Management With Scrum);
Etape 3: Scrum permet de bien piloter une entreprise. (The Enterprise And Scrum).
La progression est notable.

AGILE WORLD MANAGEMENT WITH SCRUM?

Et bien, je dois avouer que la gestion d'entreprise avec Scrum m'a ennuyé. Je n'ai pas accroché. Je suis fan de Ken Schwaber et de son style mais il ne m'a pas convaincu. Je ne dois pas être la cible type de ces propos. Pour autant, je ne regrette pas la lecture de ce livre. Au lieu de m'étendre sur mes déceptions je vais me concentrer sur ce qui m'a plu.

QU'EST-CE QUI FREINE SCRUM?

Un chapitre est dédié aux comportements qui minimisent le retour sur investissement de l'application de Scrum. J'ai pu (malheureusement) reconnaitre dans mon expérience chacun des points identifiés. Je dois commencer à me faire vieux ... Notamment, j'ai bien reconnu l'engagement défiant les lois de la nature. Plus concrètement, une équipe identifie le restant à faire. L'équipe mesure et confirme sa vélocité sur plusieurs itérations. Mathématiquement, l'équipe voit qu'elle ne peut tenir le délai avec avec le contour souhaité par le client. Alors le management pousse à coup de "allez, on se retrousse les manches et on va réussir". Et bien non, on ne peut s'engager en défiant les lois de la nature. Cette attitude mène directement au point suivant.

LA DETTE TECHNIQUE

Dans ses conférences (chez Google et Agile 2006), Ken Schwaber explique comment une organisation peut accumuler une dette technique et se saborder en essayant d'être trop ambitieuse sur sa vélocité. Un chapitre du livre et consacré à ce sujet. En deux mots: l'équipe s'engage (ou est poussée à d'engager) au delà des lois de la nature. Pour tenir les délais l'équipe lâche sur ce qui ne se voit pas : la qualité. Cette réaction marche à très court terme. Par contre, à moyen et long terme la dette technique accumulée immobilise le développement.

SCRUM ET LES PRATIQUES TECHNIQUES

C'est le grand sujet du moment: Scrum n'est pas efficace sans l'ajout de sérieuses pratiques techniques. Ken Schwaber doit être lassé d'entendre cela car il insiste souvent sur le fait que tout incrément doit être potentiellement livrable. Cet objectif ne peut être tenu que si de solides pratiques techniques sont en place.

L'ORGANISATION DE GRANDES EQUIPES

J'ai retenu de bons conseils pour l'organisation de grosses équipes en petites sous-équipes Scrum. Pour minimiser les dépendances, les sous-équipes doivent produire des fonctionnalités orthogonales. Par contre, cela implique qu'aucune équipe n'est réellement responsable de la production d'un incrément de produit complet incluant toutes les fonctionnalités développées dans le sprint par les sous-équipes. C'est pourquoi Ken Schwaber recommande d'utiliser une sous-équipe Scrum chapeau ayant une vision produit complet. Cette équipe comprend le Product Owner du produit complet ainsi que toutes les compétences nécessaires pour transformer les fonctionnalités développées dans le sprint en un produit complet. Par exemple, cette équipe peut être responsable des moyens d'intégration et de recette du produit complet.

SCRUM POUR LES PRODUITS CRITIQUES

Dans le cadre du développement de logiciels critiques, Ken Schwaber recommande une pratique que nous appliquons déjà depuis plusieurs années. Chaque incrément doit être livré avec une traçabilité des exigences à jour.

EN CONCLUSION

Finalement, je pense avoir bien fait de lire ce dernier livre de la trilogie. Je vais essayer d'en appliquer certaines recommandations concernant l'organisation des grosses équipes. Par contre, je vais désormais me remettre aux livres abordant des sujets techniques! C'est parti avec le pavé sur le remaniement des tests xUnit.

THE PRICK, LE SCRUMMASTER ET LE COACH (V3)

Dans une de ses conférences, Ken Schwaber dit avec humour que le ScrumMaster d'un projet est aussi appelé le "prick". Il hérite de ce surnom peu envieux car il est la personne la moins aimée du projet. Il est mal aimé car il harcèle l'équipe pour maintenir la discipline et la qualité. Il ne lâche pas car il est le garant de l'application du processus et de la qualité du produit.

PUSH / PULL

Pour ne pas tomber dans ce travers dans notre organisation, le ScrumMaster est aussi un développeur de l'équipe. Il devient légitime car il applique ce qu'il demande des autres. Il montre le chemin en étant exemplaire dans son respect des pratiques. Il ne cherche pas à pousser les équipiers vers un niveau mais plutôt à les tirer vers le niveau qu'il s'efforce d'atteindre et de conserver. Concrètement, il est plus facile de faire adhérer à la pratique du test-first lorsqu'on l'applique soi-même et qu'on binôme pour l'enseigner.

MANAGEMENT / LEADERSHIP

Nous rejoignons la nuance qu'il existe entre manager et leader. Un ScrumMaster développeur ne fait pas que proposer ("y a qu'à, faut qu'on") . Il entraine les autres par son exemple en montrant une voie. Attention, il ne dicte pas la voie. L'équipe choisit les pratiques. Mais pour exiger légitimement des autres qu'ils appliquent leurs pratiques encore faut-il commencer par les appliquer soi-même.

SCRUMMASTER / COACH

Du coup, le ScrumMaster développeur ressemble beaucoup au Coach XP. Il est un praticien expérimenté qui enseigne par l'exemple.

UN JOB A TEMPS PLEIN?

Sur nos projets, nous constatons d'ailleurs que les activités du ScrumMaster pour une équipe atteignant 9 développeurs ne constituent pas un plein temps. Au delà de 9 personnes, l'équipe se scinde en sous-équipes donc le problème ne se pose pas. Alors, que peut faire le ScrumMaster le reste du temps? Le ScrumMaster peut-il s'investir sur d'autres équipes? Afin d'être légitimement accepté par l'équipe, nous choisissons de ne pas diviser la disponibilité d'un ScrumMaster entre plusieurs équipes. La deuxième partie de son temps est accordée au développement. ScrumMaster développeur est un job à temps plein.

SCRUMMASTER(S)

Dans notre organisation, nous avons une autre particularité. Nous avons plusieurs ScrumMaster développeurs dans l'équipe. Ils ne se marchent pas sur les pieds. Aux contraire, ils se relayent. Ainsi, il y a toujours un garant de la discipline des pratiques et de la qualité, malgré les congés et les moments de fatigue. Il suffit de passer le relai. C'est aussi une manière d'investir sur les équipiers en formant des ScrumMasters praticiens au sein de l'organisation.

SCRUM MOU / SCRUM + XP

Scrum doit se pratiquer avec de solides pratiques techniques. Chaque sprint doit fournir un incrément de produit potentiellement livrable, donc testé et documenté. Avoir un ScrumMaster développeur sur un projet est aussi un moyen de s'assurer que les pratiques techniques ne seront pas délaissées à la faveur des pratiques d'organisation.

A LA MANIÈRE DE TOYOTA

Cette conception du leadership rejoint les principes du Toyota Way:

Principe 9: "Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others."
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) viennent de l'équipe et font partie de l'équipe. Ils font le même travail que les équipiers et sont sur place pour les former.

Principe 12: "Go and see for yourself to thoroughly understand the situation".
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) font partie de l'équipe. Ils comprennent la situation puisqu'ils sont en situation sur le terrain.

EN CONCLUSION

Si vous n'êtes pas le client ou son représentant et que vous contribuez au développement d'un logiciel, alors développez!

NIKO-NIKO

C'est un article qui nous a donné l'idée de mettre en place un calendrier Niko-Niko.

LA PRATIQUE

Chaque soir en quittant le travail, les membres de l'équipe collent une pastille de couleur sur le calendrier dans la case du jour révolu.

Une pastille verte indique que le développeur a passé une bonne journée sur le projet.
Une pastille jaune représente une journée neutre.
Une pastille rouge marque une mauvaise journée.

Une tendance de pastilles jaunes et rouges signale que l'équipe doit se réorganiser pour redistribuer les tâches ou repenser sa manière de travailler. Cette pratique permet également de suivre un indicateur sur le « sustainable pace ». Elle permet enfin à l'équipe de fusionner en la rendant maître de sa propre gestion.

LES ENSEIGNEMENTS

Pour le moment, nous ne savons pas encore ce qu'il faut concrètement retirer de cette pratique en cours d'expérimentation. En tout cas, elle permet de vérifier la corrélation entre la santé de l'équipe, la santé du projet et la qualité du logiciel. Ceci confirme l'exactitude de l'équation "Equipe = Produit". Enfin, le Niko-Niko permet aussi à chacun de s'exprimer sur la manière dont il vit le projet, sans avoir à attendre la rétrospective d'itération mensuelle.

VERS UNE AUTRE PRATIQUE

Lors de la 2ème réunion du CARA à Valence, j'ai fait une présentation à base de photos sur les pratiques de notre équipe. Les discussions autour du Niko-Niko m'ont permis de revoir cette pratique sous un nouvel angle.

Plutôt que de signaler le ressenti de la journée, les pastilles pourraient indiquer l'efficacité de la journée.
Une pastille verte indiquerait une journée très efficace.
Une pastille jaune représenterait une journée de production conforme.
Une pastille rouge marquerait une journée gaspillée.
Une succession de pastilles rouges avertirait qu'une action corrective doit être menée pour revenir à un travail efficace. Il faut alors rechercher la cause racine de cette perte de productivité. Une telle tendance ne se détecte pas forcément par une remontée de la pente du burndown chart de l'itération. En effet, le burndown chart mesure la vélocité globale de l'équipe. Cette moyenne peut masquer l'enlisement de certains équipiers. Les difficultés des uns peuvent être compensées par la performance des autres. Certes, un développeur en difficulté signalera sa perte de productivité lors du stand-up-meeting quotidien. Son alerte risque de passer pour une anecdote sans conséquence durable alors que l'historique du Niko-Niko révélera un enlisement dans la durée.

CONCLUSION

Nous pourrons discuter de l'intérêt de cette pratique alternative du Niko-Niko lors de notre prochaine rétrospective d'itération. Enfin, ces réflexions me démontrent l'utilité de présenter son travail. Cette autre pratique du Niko-Niko résulte des échanges menés lors d'une réunion du CARA. Merci aux participants pour ce nouvel éclairage!