Catégories
Agile

Le leadership Tribal

Motiver une ou plusieurs équipes a toujours été un challenge pour un manager ou leader. Un challenge d’autant plus grand avec les nouvelles générations qui exigent – à juste titre – davantage de sens. Plus question d’exécuter une tâche – en particulier répétitive – sans savoir pourquoi. Plus question d’avoir le sentiment de n’être que l’engrenage d’une « machine », sans latitude pour exprimer sa créativité.

Dans cet article, nous ne traitons pas de management au sens strict (gérer un budget, un planning, un client, des « ressources humaines », etc) mais de leadership.

Le fruit d’une étude

Le Leadership Tribal nous vient d’une étude menée pendant plus de 10 ans sur plusieurs entreprises diverses. Entreprises américaines seulement mais nous allons voir que ce détail a peu d’importance car les principes qui en résultent sont universels. Cette étude ne s’intéresse pas à la dimension psychologique, sociologique (origine des personnes observées, culture, etc), ni même environnementale. Elle se focalise plutôt sur l’observation et l’analyse du langage, comportement et type de relation adopté. Elle part d’un principe simple : les mots qu’on utilise influencent notre comportement. Par exemple, face à une difficulté, se répéter à soi même « je ne vais pas y arriver » augmente nos chances de ne pas y arriver. Et c’est également valable à l’échelle d’un groupe de personnes (d’une tribu).

Qu’est ce qu’une tribu ?

Une tribu est un groupe de 20 à 150 personnes qui se connaissent suffisamment pour se saluer lorsqu’elles se croisent dans la rue. Une petite entreprise est une tribu, une grosse entreprise est une tribu de tribus.

5 stades, 5 discours

Cette étude a permis d’identifier 5 stades. A chaque stade est associée une façon de parler, un comportement et un type de relation.

Tableau de synthèse des 5 stades de tribu.
Stade Discours Comportement Type de relation Population concernée
1 « La vie est nulle » Sabotage Exclu 2%
2 « Ma vie est nulle » Victime passive Isolée 25%
3 « Je suis génial (et pas toi) » Guerrier solitaire Domination personnelle 49%
4 « Nous sommes géniaux (et pas les autres) » Fierté tribale Partenariat stable 22%
5 « La vie est géniale » Émerveillement innocent Equipe Moins de 2%

Leviers d’évolution

Ce paragraphe résume brièvement les principaux leviers permettant de passer d’un stade à un autre. Chaque stade s’appuyant sur les acquis du précédent, on ne peut « sauter » un stade. Pour vérifier si une personne ou tribu a atteint un nouveau stade, il suffit d’observer le langage, comportement et type de relation adoptés.

Stade 1 vers stade 2

Pour faire passer une personne du stade 1 (exclue et dont le discours est « la vie est nulle ») au stade suivant, on l’encourage à aller là ou l’action se déroule. Par exemple en déjeunant avec ses collègues, en participant aux réunions, etc. Par ailleurs, elle devra rompre ses liens avec les autres personnes du type « la vie est nulle ». On lui montrera également que la vie « fonctionne » pour d’autres et qu’elle aussi (la personne qu’on accompagne) peut donc avoir sa chance.

Stade 2 vers stade 3

Le discours des personnes de stade 2 tourne autour du thème « ma vie est nulle » et sont généralement isolées. Leur niveau d’implication est minimal et le signe d’un tel état d’esprit est souvent la présence d’affiches de « Dilbert » dans les locaux. Elles savent cependant que la vie peut réussir à d’autres.

Pour l’aider à évoluer vers le stade 3, on peut notamment :

  • L’encourager à créer des relations dyadiques (2 personnes), en particulier avec des personnes de « stade 3 avancé » qui ne demandent qu’à remplir un rôle de mentor et façonner des « mini-elle ».
  • Souligner ses compétences, ses forces et son potentiel à développer.
  • Lui proposer des projets qu’elle peut réussir à court terme et qui nécessitent peu de suivi ou surveillance.

Stade 3 vers stade 4

Une personne au stade 3 a pris confiance en ses capacités a travers plusieurs victoires et adopte un discours du type « je suis génial » avec pour sous-entendu « et pas toi ». Ses relations sont dyadiques afin de cloisonner. Il maîtrise ainsi la connaissance et les informations dont il dispose, qui constituent son « pouvoir ».

Pour l’aider à évoluer, on peut :

  • L’encourager à former des relations tryadiques (3 personnes) autour de valeurs fondamentales communes.
  • A travailler sur des projets dont le succès nécessite du partenariat et l’aider à prendre conscience à l’issue de ce projet que ce dernier n’aurait pas pu réussir sans l’aide des autres membres de l’équipe.
  • Lui montrer que le vrai pouvoir ne provient pas de la connaissance et la détention d’informations mais des réseaux.
  • L’encourager à user de transparence en communiquant à outrance plutôt qu’en communiquant uniquement les informations dont les autres ont besoin (stade 3).

L’épiphanie

La plupart des personnes interrogées dans le cadre de cette étude se positionnent généralement à 1 ou 2 stades au dessus de la réalité. La prise de conscience de l’existence de ces stades et de leur caractéristiques (langage, type de relation et comportement) aident à ouvrir peu à peu (ou brutalement) les yeux sur soi. L’aboutissement de cette phase d’introspection; cette « révélation » qui changera définitivement sa façon de parler, de se comporter et d’établir ses relations; est appelée « épiphanie ».

Stade 4 vers stade 5

Le stade 4 consiste à ne plus raisonner selon le « je » mais selon le « nous ». Le passage au stade 5 consiste à aller plus loin, à déplacer les montagnes, à « écrire l’histoire » en accomplissant des exploits qui n’avaient encore jamais été atteints au sein de l’entreprise ou au delà.

Processus d’élaboration de la stratégie de la tribu

Pour cela on met en place la « stratégie de la tribu » autour de valeurs fondamentales et une noble cause. Cette stratégie doit émerger de la tribu dans son ensemble et du contexte (économique, technologique, etc) plutôt que de la vision seule du leader. La définition de cette stratégie se fait en 4 temps :

  1. Identifier les valeurs fondamentales et la noble cause de la tribu qui fédérera les membres.
  2. Définir les résultats concrets visés (et non pas un objectif du genre « devenir numéro 1 mondial »).
  3. Faire l’inventaire des actifs de la tribu (atouts, compétences, ressources, etc) et vérifier que ces actifs permettent d’atteindre les résultats visés.
  4. Recenser les comportements à adopter pour atteindre les résultats visés et vérifier que les actifs permettent d’accomplir ces comportements.

Si les vérifications mentionnées révèlent des limites (pas assez d’actifs pour atteindre les résultats visés, ou comportements inappropriés), on révise les résultats ou définit des résultats intermédiaires et on ajuste les comportements.

Le leader devra toujours respecter les valeurs identifiées et la noble cause quitte à faire des renoncements (renoncer à un marché par exemple). Dans le cas contraire, la confiance est rompue, les valeurs et noble causes bafouées et plus rien n’a de sens. On régresse alors vers les stades inférieurs.

Changer d’huile régulièrement

Régulièrement, tous les 2 ou 3 mois par exemple, la tribu se réunit et prends le temps de faire le point. Elle fait l’inventaire de ce qui fonctionne et qu’il faut cultiver, de ce qui fonctionne moins bien et identifie les améliorations à apporter. Au besoin elle ajuste sa stratégie.

Notre société cultive le « stade 3 »

Un livre de stade 3 parmi tant d’autres.

C’est triste à dire mais notre société – à travers notamment son système éducatif, le milieu du travail et les médias – cultive des personnalités de stade 3. Dès les bancs de l’école, les « bon points » nous poussent à l’individualisme et à la compétition, à conserver l’information qui permettra d’obtenir ce bon point (plutôt que de la partager pour aider les autres à progresser), à se comparer aux autres. La sonnerie nous dit quand nous devons changer de classe, faire une pause ou finir sa journée. De quoi nous préparer au monde du travail (surtout en usine).  Les bons points cèdent ensuite la place aux notes, aux classements, etc. Puis la compétition au sein des grandes écoles prend le relais avec le bizutage illustrant l’état d’esprit suivant : « dans la vie, il faut en baver et c’est chacun pour soi. Ne fait confiance à personne. ».

Une fois dans le monde du travail, la culture « stade 3 » se poursuit avec à minima les évaluations et notes annuelles, les primes. Mais le pire concerne le secteur commercial au sein duquel la loi de la jungle atteint son paroxysme.

Le monde de l’édition quant à lui n’est pas en reste d’ouvrages de stade 3 prônant la compétition, l’individualisme et le dépassement des autres.

Aujourd’hui, des voix s’élèvent pour revoir notre système éducatif. Proposent un système au sein duquel les enfants ne sont pas infantilisés mais responsabilisés, écoutés et auto-disciplinés. Un système plus démocratique faisant participer les élèves aux décisions qui définissent le programme et la vie de l’établissement scolaire. La pédagogie est révisée pour enseigner selon des principes de coopération plutôt que de compétition. Un système dont le programme s’adapte aux passions de l’enfant sans juger que l’étude de l’anatomie d’une grenouille est plus importante que la construction d’un cerf volant. Un système au sein duquel l’enfant qui a compris un enseignement peut transmettre ce dernier avec ses propres mots aux autres élèves qui parlent le même langage (en complément de l’enseignant).

Bénéfices à partir du stade 4

Voici la liste des principaux bénéfices constatés sur les tribus de stade 4 :

  • Meilleure collaboration (autour de la noble cause).
  • Moins de peur et de stress grâce à l’absence de friction avec les autres (absence de compétition).
  • Basculement de la résistance au leadership vers son suivi par l’ensemble de la tribu.
  • Turn-over limité et conservation des talents.
  • Davantage d’engagement des membres de la tribu.
  • Formation sans effort grâce à l’enseignement apporté par la tribu à ses membres sur les dernières réflexions et pratiques.
  • Meilleurs indicateurs de santé : moins de blessure et d’arrêts maladie.
  • Meilleure compétitivité : créativité, connaissances, aspirations libérées.
  • Épanouissement des membres de la tribu (fun).

Conclusion

En guise de conclusion, voici un extrait du livre « Tribal Leadership » de Dave Logan, John King et Halee Fischer-Wright:

Alors que les leaders tribaux travaillent pour le bien du groupe, non pas pour eux même, ils sont récompensés par la loyauté, le travail acharné, l’innovation et la collaboration. La tribu produit un travail de la plus grande qualité en moins de temps. […] L’avenir de l’entreprise est le stade 5.

Pour aller plus loin

Source : agiliste

Catégories
Non classé

The Joel Test : ou comment évaluer votre environnement de travail (ou tester votre équipe)

Je vais tenter ici de vous expliquer une méthode qui vous permettra d’évaluer très rapidement la qualité de l’environnement de travail d’une équipe de développement.
Il s’agit du « Joel Test ». Une méthodologie imaginée par Joel Spolsky ( http://www.joelonsoftware.com) qui est notamment co-fondateur de http://stackoverflow.com/. Si vous voulez lire l’article original c’est ici : http://www.joelonsoftware.com/articles/fog0000000043.html
Ce test est basé sur 12 simples questions. Chaque question donnant un point si la réponse est « oui ». Si vous obtenez un score de 12 c’est que vous avez tout bon. Un score de 11 est tolérable mais d’après lui un score de 10 ou moins dénote de gros problèmes.

The Joel Test
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

Évidemment ce n’est pas la seule métrique à prendre en compte, ni un indicateur de réussite. Vous pouvez avoir un score de 12 et une super équipe, mais un produit dont personne ne veut avec des technologies qui ne vous intéressent pas. Et inversement, un score inférieur à 10 avec une équipe qui n’a pas trop de rigueur, mais faire des choses fantastiques où vous vous sentirez super bien.
Je vais maintenant décrire ces 12 questions.

1. Do you use source control?
Autrement dit : utilisez-vous un outil de gestion de version des sources (cvs, svn, git…)? Il me parait essentiel d’avoir un outil de versionning, pour pouvoir travailler de manière collaborative et également garder un historique du travail effectué. Ceci peut nous éviter bien des problèmes (notamment la perte de code) et nous aider à réparer des erreurs en récupérant facilement une ancienne version.

2.Can you make a build in one step?
Considérant le build comme un livrable issu des dernières versions snapshot. Joel part du principe que si votre application nécessite plus d’une étape pour construire votre livrable, les risques d’oublier l’une de ces étapes lorsque vous livrez ne sont pas négligeable. Par ailleurs lorsque la deadline de livraison approche vous n’avez pas envie d’avoir 15 étapes à faire. Vous voulez livrer rapidement et ne pas perdre de temps sur cette tâche.

3.Do you make daily builds?
L’idée est surtout d’avoir un outil d’intégration continue effectuant un build quotidien. On a tous un jour ou l’autre eut cette conversation avec un collègue :
Vous : « Je pense que tu as oublié de commiter un fichier, je n’arrive pas à builder sur mon environnement. »
Votre collègue : « Non, j’ai tout commité, tu n’es peut être pas à jour ou alors c’est toi qui a cassé le build »
S’en suit une discussion stérile ou chacun reste persuadé que l’autre a oublié quelque chose et ne veut pas l’admettre.
L’avantage majeur d’un tel outil est de travailler uniquement sur ce qui a été commité. Vous pouvez donc à tout moment connaître les sources que vous pouvez ou non récupérer. Joel suggère un build pendant le déjeuner pour que chacun commit son travail avant de déjeuner et récupère toutes les modifications au retour de la pause. C’est une solution envisageable mais je préfère l’idée de réparer un build cassé le plus rapidement possible. Ce qui implique de le détecter le plus rapidement possible. La plupart des outils d’intégration continue permettent de programmer les builds tous les X temps ou sur évènement (par exemple à chaque commit). Après, à chaque équipe d’adopter la solution qui lui convienne le mieux.

4. Do you have a bug database?
Effectivement pour ce point je rejoins l’opinion de Joel qui explique que les cerveaux des développeurs ne peuvent pas constituer une base fiable de toutes les anomalies connues et/ou corrigées. Il existe beaucoup d’outils sur le marché (Jira, Mantis, …)

5. Do you fix bugs before writing new code?
Joel nous explique avec une anecdote enrichissante sur le développement de Microsoft Word l’intérêt de cette méthodologie. En résumé leurs équipes étaient tellement en retard dans le planning qu’ils ont développé chaque fonctionnalité rapidement pour passer à la suivante et respecter le planning. Toutes les anomalies seront détectées et reportées, mais feraient l’objet de corrections prévues une fois la deadline passée. Cette façon de reporter à plus tard été baptisé « infinite defects methodology » ou comment fabriquer une roue couverte de rustines.
Suite à cela, Microsoft a appliqué la « zero defects methodology » la priorité étant de corriger chaque anomalie connue avant de développer de nouvelles fonctionnalités.
Ce concept permet sur le long terme de gagner beaucoup de temps pour différentes raisons :
– plus rapidement vous corrigez le problème, plus le code est frais dans votre mémoire, ce qui vous permettra de le corriger plus vite que si vous devez d’abord vous rappeler du code écrit.
– si l’anomalie à corriger a déjà été livrée il vous faudra plus de temps pour la corriger (vous devrez potentiellement relivrer, créer une branche, reporter sur le tronc …)
– le temps de correction n’est pas toujours prévisible : on a parfois des bugs dont le temps de correction variera selon le temps de détection de la cause. Par contre, le temps de développement des nouvelles fonctionnalités est estimable. Si l’on développe toutes les fonctionnalités et que l’on s’occupe de corriger les anomalies à la fin, on aura respecté le planning initial mais la date de bouclage sera très difficilement prévisible. Corriger les bugs avant de faire de nouveaux développements permet d’avoir un planning plus proche de la réalité.
– cela permet également d’avoir une application de qualité dans un état quasiment toujours livrable, ce qui permet d’être réactif au marché.

6. Do you have an up-to-date schedule?
Avoir un planning à jour apporte une aide précieuse. Grâce à lui nous pouvons organiser les évènements et les décaler si besoin. L’autre atout s’affilie à l’un des avantages de scrum : si l’on a du retard mais que la date finale ne peut être déplacée, nous devons réévaluer la nécessité des fonctionnalités et ainsi travailler par ordre de priorité en fonction de l’importance des celles-ci.

7. Do you have a spec?
Tout le monde est d’accord pour dire que l’on a besoin de traces écrites sur le fonctionnel d’une application. Que ce soit une spécification fonctionnelle détaillée en bonne et due forme, ou bien une liste d’US rédigées de manière concise et claire. En tant que développeur, on pense tout d’abord à la façon dont on implémentera le code. Si l’on n’a pas, en amont, rédigé la description de la fonctionnalité, même de façon sommaire, on risque de découvrir les éventuels problèmes fonctionnels une fois le code écrit. Ce qui implique que l’on devra repasser sur ce code, voir également sur la spécification de la fonctionnalité.
Si l’on définit par écrit le besoin et le fonctionnement d’une nouvelle fonctionnalité, on aura plus de facilité à corriger les éventuels problèmes fonctionnels lors de la rédaction. Ainsi le code pourra être implémenté pour répondre au besoin dès le départ. Corriger des anomalies sur une application non documentée peut devenir tellement complexe que certains décident de tout jeter pour recommencer de zéro. Joel préconise d’appliquer la règle « no code without spec » pour éviter ce genre de problème.

8. Do programmers have quiet working conditions?
Lorsqu’un développeur est au meilleur de ses capacités, on dit qu’il est dans la « zone ». Cette zone (cf article : 7 idees pour transformer une bonne equipe, en equipe exceptionnelle) est atteinte au moment où il est complètement concentré sur son travail et ne prête aucune attention à l’environnement qui l’entoure. Il faut en moyenne 15 minutes pour atteindre la zone de travail optimale. Mais le fait est que l’on peut en sortir très rapidement. Que ce soit à cause du bruit, d’un coup de téléphone, d’une pause, d’une interruption par un collègue etc. Dans les open space et autres bureaux partagés, la principale raison est l’interruption intempestive de nos collègues. Du coup lorsque l’un de vos collègues pense gagner du temps en vous posant une question qui vous prendra 1 minute à chacun, au lieu de prendre 5 minutes à chercher seul, il fait en réalité perdre 15 minutes de votre temps pour gagner 4 minutes du sien. La meilleure solution est de considérer que vos collègues sont dans un bureau fermé avant de les déranger et également de se demander si cela ne nous prendrait pas moins d’un quart d’heure pour trouver une solution seul.

9. Do you use the best tools money can buy?
On ne parle pas d’avoir toutes les licences des dernières applications à la mode mais uniquement d’avoir des outils adaptés au travail demandé. En réalité un développeur perd parfois beaucoup de temps car sa machine n’est pas assez performante. Si sa machine prend par exemple 15 secondes à la compilation, ce temps est perceptible et fera perdre patience au développeur. Il pourrait s’en lasser, être démotivé et décider régulièrement d’aller sur internet pendant ce temps. Mais puisqu’il y passera certainement plus de 15 secondes c’est au final de nombreuses heures de productivité qui seront perdues.
Si l’on doit travailler sur des IHM, avoir deux écrans peut rendre la tâche beaucoup plus facile. Idem pour les retouches d’images, utiliser Paint au lieu d’un outil spécialisé pour cela rend la tâche plus fastidieuse.
Fournir à ses équipes le matériel et les outils les plus adaptés peut représenter un coût important à première vue. Mais un meilleur environnement de travail, rendra vos équipes plus heureuses sur le long terme. En répercussion, cet investissement pourra vous faire gagner une meilleure productivité.

10. Do you have testers?
Ici, Joel explique que si l’on n’a pas un ratio d’un testeur pour deux à trois développeurs on s’expose à une forte probabilité que, soit nos produits ne sont pas de qualité, soit nos produits coûtent extrêmement cher pour être de qualité. Cette déduction est moins évidente en France car la différence de coût entre un développeur et un testeur n’est pas aussi flagrante qu’aux Etats-Unis (il parle d’un coût de 100$/heure contre 30$/heure pour un testeur). À mon avis, il est effectivement important d’avoir des personnes qui font des tests. Que ce soit les développeurs eux-mêmes en changeant de rôle temporairement ou bien qu’il y ait une équipe de test spécifique. Le principal problème est qu’il est très difficile de recruter de bons testeurs. Il faut donc parfois se construire une équipe avec des profils mixtes pour pouvoir faire des tests croisés entre développeurs. Ce qui est important ici n’est pas que chacun ait un rôle définit et ne puisse pas en sortir mais que le rôle de testeur existe dans chaque équipe même de manière temporaire. Il vaut mieux, par exemple, avoir des développeurs qui testent un jour par semaine qu’aucun testeur ou même un mauvais testeur.
J’ajouterais également que l’existence d’une équipe d’intégration est un vrai plus. On a tendance à livrer son produit et oublier qu’il doit potentiellement interagir avec d’autres applications. Lorsqu’un échange est en échec, souvent chaque équipe accuse l’autre. Une équipe d’intégration permettra de tester ces interactions et vérifier que chaque partie a bien fait les choses.

11. Do new candidates write code during their interview?
Il est vrai que souvent lors des entretiens, nous avons droit à une batterie de questions techniques. Nous préparons donc nos entretiens pour pouvoir répondre correctement à toutes ces éventuelles questions. Il est également très rare d’avoir un test écrit. Que ce soit sur ordinateur ou sur un tableau, on nous demande rarement de coder ou d’écrire un algorithme.
Ce qui est en théorie absurde car nous sommes alors recruté sur l’hypothèse de correspondre au profil recherché. C’est pourtant l’un des rares métiers où cela est très fréquent. Joel prend l’exemple d’un magicien. En effet, on n’embaucherait pas un magicien sans avoir vu quelques tours. Alors pourquoi continue-t-on à embaucher des développeurs sans les avoir vus coder ? Cela permettrait d’éviter parfois de grosses surprises et donc la perte de temps à vos équipes.

12. Do you do hallway usability testing?
Ce point est très enrichissant. “Hallway usability testing” est le fait d’arrêter des personnes que vous croisez dans le couloir et leur demandez d’utiliser le code que vous venez de développer. En faisant cela avec cinq personnes, on devrait découvrir 95% des problèmes de conception de son code.
On peut également utiliser cette méthode pour les IHM. En prenant cinq ou six personnes et en leur demandant d’utiliser notre IHM, on découvrirait les plus gros problèmes ergonomiques. Cela nous permettra d’avoir une application plus facile d’utilisation et plus rapide à prendre en main pour les nouveaux utilisateurs.
Ce point est à mon sens le plus difficile à mettre en œuvre car comme le pair-programming, il est souvent ardu de faire comprendre sa valeur ajoutée à la hiérarchie, qui d’un œil extérieur ne verra que du temps gaspillé par cinq personnes alors qu’une seule aurait pu faire ce travail. Mais s’il est compris, vous arriverez certainement à sortir un meilleur produit.
D’une manière plus poussée, certaines équipes font ça sous forme de réunion informelle. En réunissant un panel d’un certain nombre de personnes issus de différents services de l’entreprise, on leur fait utiliser l’application et on récolte leurs avis et suggestions. Vous pourrez ainsi avoir une application qui sera utilisable par tout type de personnes qu’elles soient techniques ou non.

Conclusion
En conclusion, je dirais que ces 12 points sont effectivement importants. Mais d’autres points sont également à considérer. Certaines équipes atteignent un score très bas mais auront la volonté de l’améliorer. D’autres pourraient avoir un score moyen et seraient tentés de se reposer sur leurs acquis. Il faut donc également essayer de déceler cette part de volonté. Il sera plus facile pour une nouvelle équipe et une entreprise récente d’atteindre plus de 10 points, comparée à une société ayant de nombreuses applications à maintenir depuis des années. Mais ce qui compte également est votre implication. Si travailler dans un environnement qui applique un certain nombre de ces points est important pour vous. Si vous pensez que cela pourrait vous enrichir professionnellement. C’est à vous de faire en sorte que cette métrique augmente et d’en convaincre vos collègues. En quelques mots : soyez acteur de votre carrière.