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
Non classé

Être un multipotentiel dans le monde du travail

Du plus loin que je me souvienne, j’ai toujours eu une motivation et une excitation hors norme dès que j’abordais quelque chose de nouveau, que j’avais personnellement choisi, et inversement, un sentiment d’ennui allant même à la dépression quand il s’agissait de tâches répétitives sur des sujets non stimulants.

Je fais partie de ceux qui, une fois les grandes lignes saisies, ainsi que le but profond, aiment passer à un autre sujet, plutôt que de s’essouffler sur les détails.

Le truc avec les multipotentiels, c’est la soif de savoirs, et par conséquent la transdisciplinarité. J’aime apprendre de sujets totalement différents, et cette soif me permet d’innover plus facilement en connectant des choses qui, pour la plus part des gens n’ont pas de lien. C’est là que s’exerce notre réel talent créatif.

Devoir rester sur un projet, sur un produit, ou sur une prestation qui ne m’intéresse pas, est une réelle torture. Le temps se fige, et les sentiments d’ennui et de perte de temps me submergent. Tout ce temps perdu que je pourrais utiliser pour grandir, apprendre, fabriquer, expérimenter, et qui me serait utile, mais aussi aux autres.

Et au contraire, lorsque le sujet du boulot m’intéresse, je m’investis à un point que j’atteins souvent mes limites, autant physiques que mentales.

Aujourd’hui on pourrait espérer que la plupart des employeurs recherchent des potentiels plutôt que des acquis, car dans la société en perpétuel changement qui nous entoure, il va falloir connecter entre elles des choses qui ne le sont pas encore, et il va falloir être capable d’apprendre vite afin de s’adapter.

Mais la France fonctionne encore de manière assez rigide sur le plan de l’emploi. Du coup gagner sa vie en étant multipotentiel est un vrai problème. D’autant plus que la plupart des multipotentiels, mais aussi des hauts potentiels adultes (souvent les mêmes) s’ignorent. Ils et elles naviguent donc à l’aveugle, poussés par la pression sociale et matérielle à devoir gagner de l’argent, se conformer, sans outil ni arme pour se construire une vie « normale » tout en respectant leur personnalité profonde.

Il faut aussi savoir que nous, les multipotentiels, doutons par nature. Nous somme aussi des introvertis, qui sont plus enclin à collaborer, harmoniser et à travailler soit totalement seul, soit au contraire en intelligence collective. Nous nous plaçons en explorateur des savoirs, et nous ne pouvons donc jamais être surs de rien tant que nous ne nous sommes pas aventurés sur toutes les voies. Nous sommes souvent dépeints comme hésitants, des personnes auxquelles on ne peux pas confier trop de responsabilité, et qui sont de mauvais leaders. C’est à cause de la norme « extravertie », qui joue en notre défaveur. On a toujours cru qu’il fallait être une grande gueule pour être un bon leader. Mais aujourd’hui on commence à se rendre compte que le monde aurait beaucoup à gagner si les introvertis prenaient les commandes. On se rend aussi compte que les métiers de demain sont beaucoup plus complexes et transdisciplinaires qu’aujourd’hui.

Un grand terrain devrait donc enfin s’ouvrir pour permettre aux multipotentiels, aux hauts potentiels et aux intravertis d’enfin prendre la place qu’ils méritent.

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
Non classé

Clean code

N’importe quel logiciel est constitué de code, nous pouvons créer des langages qui sont au plus près des besoins business, nous pouvons créer des outils qui nous aident à analyser et traduire ces exigences, mais il y aura toujours du code, et plus ce code est clean plus le logiciel est maintenable et évolutif.

Mais comment doit être un code clean?

Bad Code

Vous avez déjà été considérablement gêné par un mauvais code, vous avez sûrement fait face à cet obstacle plusieurs fois, mais pourquoi l’avez-vous écrit ? Si vous êtes développeurs, vous avez forcément écrit un jour du mauvais code, c’est inévitable, et les raisons sont multiples, et certainement bien claires dans vos têtes:

  • Essayer d’aller vite.
  • Pas de temps à perdre sur cette feature.
  • Vous n’avez pas eu le temps de faire un bon travail.
  • Votre patron serait en colère contre vous si vous preniez le temps de nettoyer votre code.
  • Peut-être que vous étiez fatigué de travailler sur ce programme et vous vouliez que ce soit fini.

Peu importent les raisons, le point commun à cette session de mauvais code est toujours une promesse malheureusement vite dite et vite oubliée, « je nettoierai plus tard ».

Une fois que notre code marche, on se dit : « un mauvais code qui marche, c’est mieux que rien », puis on passe à autre chose avec l’idée de nettoyer plus tard, sauf que Plus tard est égal à jamais.

Seulement voilà, plus les features s’accumulent, plus le mauvais code est présent, et moins votre logiciel est maintenable, ce qui se traduit par une productivité de l’équipe qui ne cesse de diminuer, et qui tend finalement vers zéro. Ce qui nous mène à la nécessité de réécrire le code, proprement cette fois ci, afin d’y voir plus clair

Clean code ?

Vous êtes bien conscient qu’un mauvais code est un obstacle important, et la seule façon d’aller vite est de garder le code propre.

La question qui se pose est « Comment pouvez-vous écrire du code propre », il n’est pas possible d’essayer d’écrire du code propre si vous ne savez pas ce que cela signifie!

  • Un code propre est avant tout un code qui doit être agréable à lire.
  • Un mauvais code permet au désordre de grandir! Plus on a des bouts de code mauvais, plus la qualité de notre logiciel tend vers la décadence.
  • Un code propre doit prêter attention aux détails et doit être est focalisé, chaque fonction, chaque classe, chaque objet expose une attitude simple qui reste entièrement indépendante, et non polluée par les détails non nécessaires.
  • Un code propre doit clairement exposer le problème à résoudre et ne doit contenir que ce qui est nécessaire.
  • Il y a une différence entre le code qui est facile à lire et le code qui est facile à changer, un code propre doit être facile à améliorer par d’autres personnes.
  • Un code non testé n’est pas un code propre, peu importe s’il est lisible et accessible.
  • Un code propre est un code qui a été pris en charge par quelqu’un qui a pris le temps de rester simple et ordonné.
  • Ne contient pas de duplication.
  • Un code propre est aussi un code qui réduit au maximum le nombre d’entités telles que les classes, méthodes, etc.
  • Évident, simple et convaincant: quand on lit un code propre, on ne doit dépenser trop d’effort pour le comprendre,
    Savoir si le code est propre ou mauvais n’est pas suffisant, comment peut-on écrire un code propre ?

Plusieurs techniques et bonnes pratiques faciles à adopter existent pour aider à écrire un code propre : nommage explicite de vos fonctions et variables – se passer de commentaires le plus possible, fractionnement de votre code en de multiples petites fonctions et bien d’autres, etc …

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
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.