Catégories
Agile Rétrospective

Rétrospective Squad Health Check

La rétrospective Squad Health Check, est une excellente rétrospective d’équipe agile, qui permet d’obtenir des indicateurs d’équipes, mais aussi de pouvoir suivre leur évolution.

En effet, il est intéressant de jouer cette rétrospective, de temps en temps, tout le long de la vie du projet, afin de suivre l’évolution de son équipe.

Voici le déroulé central, qui peut être adapté au besoin :

Recueillir les données :

  • Passer en revue les 11 critères du Squad Health Check
  • Pour chaque critère, lire le texte ainsi que les exemples, avant de procéder à un vote : l’équipe est-elle au Rouge, Orange ou Vert ?
    • Vert ne signifie pas parfait, cela signifie simplement que l’équipe est heureuse ainsi, et ne voit pas un besoin d’amélioration en ce moment
    • L’orange signifie qu’il y a des problèmes importants qui doivent être gérés, mais ce n’est pas une catastrophe.
    • Rouge indique ce qui ne fonctionne vraiment pas, et doit être amélioré très rapidement.
  • Discuter également de la tendance (les choses s’améliorent, elles sont stables, ou elles empirent), en commençant par un vote au pouce.
  • Bien timeboxer l’exercice, et se forcer à répondre pour chaque thème en 2 minutes.

Générer des idées :

  • Chacun écrit en privé 1 post-it par thème, de proposition d’action pour ce thème
  • Timeboxer à 5 minutes cette rédaction de post-it.
  • Faire le tour des thèmes :
    • Chacun présente sa proposition d’action, et place le post-it à coté, ou au milieu
    • Puis chacun vote pour la proposition à garder en la pointant du doigt
    • Ne garder qu’une seule proposition par thème
    • A défaut d’un consensus, il est possible de faire émerger une nouvelle proposition à la place des propositions rejetées

Si vous manquez de temps, vous pouvez aussi proposer un dot-voting, afin de cibler les thèmes prioritaires, et vous focaliser sur ce qui en ressort.

Décider des actions :

  • Suite à l’étape précédente, il reste 11 propositions à départager (une par thème)
  • Procéder à un dot voting
  • Prendre les actions les plus votées

 

 

En bonus les supports des thèmes, traduits :

Rétrospective tirée du blog spotify : https://labs.spotify.com/2014/09/16/squad-health-check-model/

Catégories
Agile

Chaos Report 2015 : Agile Vs Cycle en V

Le « Chaos Report 2015 » du Standish Group a été publié le mois dernier. Pour rappel, le Standish Group recueille des données à partir de projets réalisés parmi un panel d’industries. Il classe les projets en trois groupes : réussis, contesté, ou qui ont échoué.
Après avoir lu le Chaos Report de 2015, je vous propose deux points intéressants :

Premier Point :
Le Standish Group a affiné la notion de « projet réussi » pour 2015. Auparavant, un projet réussi, ne dépassait pas son budget, arrivait au moment décidé, et avec le bon périmètre. Le Standish group soulève que « avec le bon périmètre » n’est pas vraiment une bonne mesure, puisqu’on ne possède pas de mesure de l’adéquation du projet vis à vis des attentes de ses clients. Ils notent quand même qu’il y a beaucoup de projets qui répondent aux trois critères, mais qui laissent le client insatisfait. Ils ont donc remplacé cette mesure avec une mesure de la valeur cliente perçue. Il en résulte une diminution de 7 % du taux de projets réussis.

Oui vous avez bien lu. Si nous mesurons notre manière de mener des projets de la même manière que nos clients nous mesurent, nous sommes 7% pire que ce que nous pensions. Cela devrait clore définitivement les sujets sur le management de projet traditionnel basé sur le périmètre, les coûts et le planning.

« Nous constatons que la satisfaction et la valeur sont plus importantes lorsque les fonctionnalités livrées sont plus simples qu’initialement spécifiées, et se focalisent sur les besoins évidents. »
— 2015 Chaos Report, Standish Group

Deuxième point :
Il existe trois choses simples que vous pouvez faire pour augmenter les chances de succès de vos projets :

1. Faire de petits projets.
Indépendamment d’autres facteurs, les petits projets sont les plus susceptibles de réussir. Avec un ratio allant de 10 à 30. Plus de la moitié des gros projets créent de la valeur faible, voire très faible . Arrêtez tout!. En sachant ça, je ne comprends pas pourquoi de gros projets continuent à être lancés. Prenez le temps de scinder ces projets en petits morceaux. Des lots importants et des longues périodes d’attente sont universellement mauvais.

2. Faite des projets agiles.
Quelque soit la taille du projet, les projets agiles ont 350 % plus de chances de réussir. Cette différence est minime avec de petits projets (32 % ). Mais pour les projets les plus gros, les projets agiles ont 600 % plus de chances de réussir. Ça s’explique par le fait que ce sont les méthodes de cycle en V qui ne sont pas adapté au scaling de projet.

« Les résultats globaux montrent clairement que les projets gérés en cycle en V évoluent mal, tandis que les projets agiles s’adaptent beaucoup mieux. »
— 2015 Chaos Report, Standish Group

3. Entraînez vos équipes agiles.
L’analyse des données montrent qu’a chaque fois que l’équipe « gagne en compétences », la probabilité de réussite du projet augmente de 23 %. Entre les équipes non agiles, et les équipes agiles les mieux outillées (humainement), les chances de succès augmentent de 224 %.

Conclusion
Si vous n’avez pas déjà commencé à faire évoluer votre organisation, commencer dès maintenant. Ce qui importe le plus, c’est la valeur perçue par votre client. Les indicateurs traditionnels basés sur le budget, le périmètre et les plannings ne sont plus adaptés. Et surtout, continuez à réaliser de petits projets agiles, en mettant l’accent sur ​​les compétences et les formations des équipiers.

Catégories
Agile Rétrospective

La rétrospective agile Star Wars

Avec la sortie de l’épisode 7 de Star Wars, je me suis dit que pour coller à l’actualité, j’allais organiser une rétrospective agile sur le thème de Star Wars.

Icebreaker :
En guise d’introduction, je présente le thème de la rétrospective, et je fais tirer au sort un papier, sur lequel est écrit une citation d’un des star wars. Le but pour chacun des coéquipier, est de placer la réplique au moment qu’il trouve opportun durant la rétrospective.

Exemples de citation :
« Autant embrasser un Wookiee
 » Leia à Han Solo dans L’empire contre-attaque
« Non, je suis ton père » Dark Vador à Luke dans l’empire contre-attaque
« La peur est le chemin du côté obscur. La peur mène à la colère, la colère mène à la haine, la haine mène à la souffrance… Je sens beaucoup de peur en toi… » Yoda à Anakin Skywalker dans La Menace fantôme
En bonus le fichier de citations que j’ai utilisé.

En bonus le fichier de citations que j’ai utilisé.

Ouverture :
Sur fond de musique du film, je demande à chaque coéquipier, quel personnage de star wars le représenterait le mieux lors de cette rétrospective, et d’expliquer pourquoi.

 

Recueillir les données :
En se remémorant l’itération qui vient de se terminer, je demande à chacun de considérer ce qui s’est produit, classé, soit du coté obscur, soit du coté lumineux. Puis chacun son tour ils viennent placer leurs post-it, en expliquant le cas échéant pour que tout le monde soit sur le même niveau de compréhension.

Générer des idées :
Il est temps de partir en mission, pour cela envoyez un éclaireur regrouper les post-its par thème afin de faciliter le vote. Une fois que les thèmes sont identifiés, demander à chacun de venir voter en plaçant un, puis deux, et enfin trois point sur les thèmes qu’ils voudraient aborder.

Décider des actions :
Une fois les thèmes votés, lancez la discussion sur les actions à mener lors de la prochaine itération. Aidez vous des cases en dessous, qui permettent de classer les actions :

  • Courage
  • Diplomatie
  • Apprentissage
  • Conseil/Aide

Le mieux est d’essayer d’avoir au final, une seule action par catégorie.

Clore la rétrospective :
Une fois les actions décidées, il est temps de terminer la rétrospective. Pour cela je demande à chacun de se mettre en cercle, et je demande « En quoi X est-il un Jedi pour l’équipe ? ». Chacun est libre de répondre. Et je passe à la personne suivante jusqu’à ce chacun soit encensé par les autres.

Source

Catégories
Agile Rétrospective

Rétrospective Agile : un peu de piraterie!

Je vous propose aujourd’hui un format de rétrospective qui a rencontré de très bons feedback sur les différentes équipes agiles avec qui je travaille : La rétrospective île au trésor.

Cette rétrospective agile se focalise sur un seul objectif, et sur la levée des obstacles pour atteindre cet objectif.

Première étape :
Dessinez, ou faites dessiner à l’équipe une carte au trésor. Il est important de laisser de la place sur les cotés de la carte, et d’identifier le trésor par une croix.
Vous pouvez pousser le détail jusqu’à dessiner le bateau qui a emmené l’équipe sur cette île.
En parallèle de la réalisation du dessin, commencez à raconter l’histoire qui permet de contextualiser la rétrospective : « Vous venez de naviguer durant 3 semaines (la durée de votre sprint), en mer, pour atteindre cette île (qui représente la rétrospective) sur laquelle se trouve un trésor, comme le mentionne la carte au trésor que voici. Cependant en approchant de l’île, vous vous rendez compte que bien des périples vous attendent pour arriver au fameux trésor. Rassemblant tout votre matériel pour atteindre le trésor, vous amarrez le bateau dans une crique. »

Deuxième étape :
Établir la liste des trésors que l’équipe aimerait trouver sur l’île. Vous pouvez de la même manière qu’a l’étape un, contextualiser le trésor : « Il est mentionné sur la carte au trésor, que vous allez découvrir quelque chose que vous n’aviez jamais vu! « .
Donnez quelques minutes à l’équipe pour écrire sur des post-its ce que pourraient être ces trésors. Une fois les post-its remplis, les placer sur le coté gauche de la carte, dans la colonne trésors. Proposez un dot-voting, afin d’identifier le trésor que l’on va essayer de trouver. Placer alors le post-it correspondant à coté de la croix identifiant le trésor sur la carte.

Troisième partie :
Une fois le trésor identifié, faites dresser à l’équipe la liste des obstacles qui pourraient les empêcher d’atteindre le précieux trésor. Faites positionner les obstacles sur la carte, tout autour du trésor. De la même manière vous pouvez contextualiser ces obstacles.
Ensuite demandez à l’équipe de faire l’inventaire des outils et compétences dont elle dispose. Faites placer les post-its sur le coté droit de la carte, dans le colonne outils. Une fois les outils placés, faites regrouper les obstacles par affinité. Ensuite pour chacun des obstacles, vérifier qu’un des outils ou une des compétences de l’équipe ne peut pas le lever. Si c’est le cas déplacez la carte d’obstacle sur la carte d’outil.
Une fois tous les obstacles passés en revus, proposer un dot-voting pour identifier les obstacles à lever en priorité.

Quatrième partie :
Maintenant il va falloir identifier les outils, ou compétences qui vont nous aider à franchir les dernier obstacles afin d’arpenter sereinement le chemin vers le trésor. Lancez donc les échanges en commençant par l’obstacle ayant reçu le plus de vote. On rentre alors dans la recherche classique d’amélioration des rétrospectives agiles.

Conclusion :
Cette rétrospective agile est parfaite pour se focaliser sur un objectif. Elle permet, de plus, d’offrir à vos équipes un format adaptable, et qui sort de l’ordinaire. Cette rétrospective agile, permet aussi de faire entrer un peu d’imagination dans le quotidien des équipes, et ainsi de lâcher prise plus facilement. Et n’oubliez pas, après avoir terminé votre rétrospective agile, de demander du feedback à vos équipes!

Catégories
Agile Rétrospective

Rétrospective scrum, l’amélioration continue

La rétrospective dans les méthodes agiles (Scrum)

La rétrospective est un élément essentiel de la méthode Scrum, qui permet à l’équipe d’appréhender sa propre amélioration continue. Pour ne pas tomber dans l’ennui et afin de s’améliorer en s’amusant, l’équipe dans laquelle je suis Scrum master m’a expressément demandé d’animer, pour chaque fin de sprint, une rétrospective différente à chaque fois.

Je vous propose donc un récapitulatif des différentes rétrospectives animées par mes soins, ainsi que leurs décryptages, en plusieurs épisodes :

Episode 1 :

La rétrospective super-héros :

Première rétrospective pratiquée avec l’équipe, basée sur la rétrospective Sailboat, elle était pour moi le moyen de proposer à l’équipe de se projeter sur le sprint parfait, tout en adaptant la forme de la rétrospective à l’identité visuelle que s’était donnée l’équipe : Les super-héros.
Le bateau est représenté par des super-héros, volant vers leur forteresse grâce à la lumière du soleil. Sur sa route, des super vilains les ralentissent.

Déroulement :

  • Dans un premier temps, l’équipe dessine les super-héros, le soleil, la forteresse et les super vilains.
  • Chacun des membres de l’équipe dispose de quelques minutes pour écrire sur des post-it ce qu’il a aidé et ce qu’il a freiné pendant l’itération pour atteindre l’objectif
  • Chacun vient placer ses post-it au bon endroit sur le dessin (les bonnes choses sur le soleil, les mauvaises sur les super-vilains)
  • Le scrum master reprend les post-it un par un en les lisant à voix haute, et regroupent ceux en commun
  • Une fois tous les post-it passés en revues, proposer un dot-voting afin de faire ressortir les points les plus importants
  • Discussions sur les 3 premiers points ressortant du dot-voting, pour en extraire des actions

Feedback :
Ce format de rétrospective, permet dans un premier temps, que l’équipe se projette dans la personnalisation de l’atelier. En faisant dessiner les différents acteurs (super-héros, super-vilains), on met l’équipe au même niveau, et on remarque des comportements intéressants. Certains, surement moins bon dessinateurs se positionnent en tant que coach vis à vis de ceux qui dessinent. Un bon levier pour appuyer un discours sur l’auto-organisation. Durant la phase de recherche d’actions, il est utile de recentrer les discussions sur l’objectif de la forteresse : Ne pas hésiter à reformuler les actions proposées en commençant la phrase par « Pour avoir un sprint parfait, il faudrait … » Cela permet au Scrum master de rappeler l’objectif de la rétrospective : s’améliorer.

La rétrospective Jeopardy :

La deuxième rétrospective proposée était sous la forme Jeopardy. J’ai voulu, à travers cette rétrospective, faire participer chacun des membres de l’équipe. Le but était de donner la parole à tout le monde, et pas uniquement à ceux qui ont une personnalité plus extravertie.

Déroulement :

  • Mise en place
    • Expliquer ce qu’est le Jéopardy : Vous avez seulement les réponses sur le tableau, et vous essayez de trouver la question qui correspond à la réponse.
    • Demander à chaque équipier de penser à un mot qui résume un problème ou une bonne chose. Le mot doit être une réponse à une question à laquelle ils pensent. Ce mot est écrit sur un post-it
  • Recueillir les données
    • Maintenant chaque équipier va vous donner leurs réponses. Ils ne disent pas encore la question.
    • Vous placez le post-it réponse sur le tableau
    • Lorsque toutes les réponses sont placées sur le tableau, vous demandez aux équipiers de deviner quelle pourrait être la question.
    • Sous le post-it réponse, vous écrivez chaque question proposée.
    • Lorsque plus aucune question n’est proposée, demander à la personne qui a écrit la réponse : « Quelle était la question originale ? »
    • Ecrivez la si elle n’a pas été donnée, et la mettre en gras sinon
  • Vote
    • Demandez aux équipiers de voter pour les trois questions qu’ils pensent le plus important
  • Décider quoi faire
    • Discuter des trois questions qui ont les plus de vote, et proposer de trouver une ou plusieurs actions

Feedback :
Ce format de rétrospective permet d’impliquer chacun des membres de l’équipe, en lui faisant trouver une réponse/question. C’est aussi le meilleure moyen de voir si l’équipe est à un bon niveau de communication. Si beaucoup de questions sont proposées pour une réponse, cela prouve que l’équipe ne communique pas assez durant le sprint. C’est un bon moyen de rappeler que durant le standup meeting, il faut aussi parler des problèmes que l’on rencontre, et que c’est pas uniquement un moyen de communiquer sur son avancé. De plus le format de cette rétrospective, sous forme de jeu, permet de s’éloigner des rétrospectives classique, en proposant une dynamique de groupe beaucoup plus ludique.

Catégories
Agile

Scrum guide version 2013, de la transparence !

Scrum guide 2013 :

Ken Schwaber & Jeff Sutherland, les créateurs de Scrum, ont mis à jour leur guide en juillet 2013. Cela faisait deux ans que les deux leaders du mouvement Scrum n’avaient pas publié de nouvelle révision du guide.

Si, lors des précédentes versions du guide, le cadre de Scrum était posé, il semblerait que cette nouvelle mouture affûte un peu plus les bords, et s’applique au poids et au choix des mots employés.

Transparence, inspection et adaptation.
La notion de transparence a été particulièrement renforcée dans le guide avec un paragraphe dédié. L’objectif étant de la  favoriser, en soulignant  que sans transparence, de mauvaises décisions peuvent être prises.

Le product Backlog :
On ne parle plus de prioriser le product Backlog mais de l’ordonnancer. Cela implique que les éléments peuvent avoir des liens entre eux, et que la nécessité d’établir ce lien est importante pour avoir une vision claire des objectifs. Le sprint Backlog devient aussi plus adaptatif, ce qui permet dans des contextes différents d’avoir un peu plus de souplesse.

Le terme « Grooming » est dorénavant remplacé par le terme de « Refinement » (affinage). Les éléments ainsi affinés sont suffisamment clairs, et avec une granularité telle, qu’ils peuvent être intégrés dans le sprint planning. Ces éléments du product Backlog sont donc « Ready », et Ken Schwaber & Jeff Sutherland insistent sur le fait que les états de Done et Ready renforcent la transparence.

Le daily scrum :
La réunion quotidienne s’oriente maintenant davantage vers un événement qui permet de planifier, plutôt qu’un événement ou l’on fait le point sur les états de chacun. L’équipe doit dorénavant se positionner par rapport a l’objectif de sprint, en reformulant les trois questions du daily scrum en :
– Qu’ai-je fait hier qui a aidé l’équipe de développement à atteindre l’objectif du sprint ?
– Que vais-je faire aujourd’hui pour aider l’équipe de développement à atteindre l’objectif du sprint ?
– Ai-je rencontré des obstacles qui m’empêcheraient, moi ou l’équipe de développement, d’atteindre l’objectif du sprint ?

Le sprint planning :
On aborde deux points lors du sprint planning :
– Qu’est-ce qui peut être fait durant le sprint ?
– Définir la notion de « Done » pour les éléments planifiés dans le sprint
C’est durant le sprint planning que l’équipe va devoir définir l’objectif de sprint.

Le timeboxing :
Avec cette nouvelle version du guide de Scrum, Ken Schwaber & Jeff Sutherland insistent sur l’importance de la régularité, et sur la minimisation des réunions non prévues par le cadre de Scrum. Ainsi tout les événements sont timeboxés, en analogie au sprint qui a une durée maximale.

Scrum-Guide

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
Agile

L’agilité, les grands axes

Les méthodes agiles, qu’est ce que c’est ?

On parle plus souvent de pratiques agiles, plutôt que de méthodes agiles. C’est la synthétisation d’un certain nombre de valeurs communes à différentes méthodes apportées par les fondateurs du manifeste agile.

Quelles sont ces valeurs ?

Les quatre valeurs fondamentales agiles sont de valoriser :

  • Les individus et leurs interactions plus que les processus et les outils.
  • Des logiciels opérationnels plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que le suivi d’un plan.

Les 12 principes :

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
  • Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • Un logiciel opérationnel est la principale mesure d’avancement.
  • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
  • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  • Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  • À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Traditionnellement les pratiques agiles sont opposées aux méthodes de cycles en V.
Les spécifications sont écrites par une personne, ensuite il y a une personne qui développe et enfin une personne qui met en production.
Le cycle est unique et dans un seul sens.

La méthode agile propose de faire des cycles itératifs plus ou moins courts, où, à chaque fin de cycle on va livrer un incrément du logiciel.
Au démarrage du projet, dans un univers Agile, les premiers cycles servent à adapter le contenu aux équipes, et à étalonner les différents indicateurs. Le cycle de release sera adapté par rapport à la vélocité de l’équipe, et à ce qu’attend le client final.

Kanban : Méthodologie orientée vers la gestion de livrable en continu. Au lieu de livrer un produit comme on le fait avec Scrum, la méthode est adaptée pour livrer des services, ou des outils par exemple. C’est une organisation des taches par un workflow d’exécution, qui vont prendre différents états (analyse, réalisation, validation, …). On va travailler sur les contraintes et sur l’exécution, ce qui va permettre d’avoir une fluidité de livraison. C’est une méthode adaptée aux projets en TMA, avec peu de nouvelles fonctionnalités et beaucoup de bugs. Cela permet de gérer le bug sans attendre qu’il entre dans une itération. Le kanban fonctionne aussi très bien sur les équipes qui sont sur plusieurs projets en même temps.

Extreme programming : méthode orientée développement (comme le TDD, le pair programming, le simple design, le collective code ownership), qui vise à livrer un meilleur logiciel. Le pair programming, par exemple, c’est un ordinateur pour deux, où la réalisation est partagée. Ça permet d’être mieux challengé, et d’avoir une meilleur qualité de code (puisque la revue du code se fait en temps réel). Cela permet aussi un meilleur partage des connaissances, puisque à la fin de la séance de pair programming, les deux développeurs sont au même niveau de connaissance. Cela permet enfin de faire monter en compétence les développeurs sur certaines méthodes, sur certaines pratiques, ou sur de nouveaux concepts.

Scrum : petites équipes auto-organisées et pluri-disciplinaires (design, code, testeurs, …). Les livraisons sont découpées en itération, et le développement suit ces itérations, appelées Sprints. Chaque semaine on optimise le processus par une rétrospective, pour améliorer les sprints suivants.
Scrum est davantage une organisation de projet plutôt que des pratiques techniques, d’où son attrait aujourd’hui.
Scrum est difficile à mettre en place en entreprise par des managers, parce que les managers font partie des couches qui dans Scrum n’ont plus lieu d’exister. Dans le Scrum il y a trois profils, le product owner, le Scrum-master, et l’équipe de développement. Pour qu’un projet puisse être correctement mené à bien avec Scrum, il faut sensibiliser toutes les parties sur le fait que les trois profils pré-cités font partie de la même équipe, et qu’ils travaillent ensemble pour produire un logiciel. C’est d’autant plus difficile à mettre en place en France, que les modèles utilisés dans les entreprises utilisent des archétypes MOA et MOE figés, et ne veulent pas migrer vers ce que préconise Scrum, c’est à dire une collaboration. C’est pour cela qu’il est important lors de la mise en place de Scrum, que tous les membres de l’équipe (Product Owner, Scrum Master et équipe de développement) soient physiquement dans le même bureau.

Le bilan :
Beaucoup d’entreprises s’essaient aux pratiques agiles, mais sans un changement de culture d’entreprise, et sans soutien des cadres dirigeants, peu réussissent à l’adopter pleinement. Pourtant chez les entreprises où le changement à été accepté, accompagné, et accueilli positivement, les bénéfices de la mise en place des méthodes agiles se sont fait rapidement ressentir : meilleure cohésion des équipes, meilleure adaptation aux changements, meilleur rendement, et une valorisation des personnes.