Amélioration de la maturité d'une équipe

Communauté Scrum Life
,
1

Bonjour tout le monde,

Je suis à la recherche d’outils ou de recommandation de lecture. Afin d’améliorer, et ce, de manière transparente la maturité de mon équipe.

Je cherche non pas à les « amener » vers une meilleure maturité. Mais, de les « emmener » vers cette nouvelle maturité.

• Peut-être, en leur offrant des outils qu’ils pourront choisir de prendre ou pas.
• Peut-être en changeant mon approche dans certaines interventions.
• Oui, en leur posant des questions ouvertes. Dans, ce cas-là ça va me prendre de nouvelles idées.
• Allez réfléchissons ensemble.

P.S. Je n’ai volontairement pas décrit certains problèmes de maturité en détail. Car, possiblement, certains éléments ont peut-être passé sous mes radars dans mon accompagnement de cette équipe. Je ne veux pas orienter vos réponses non plus.

MERCI à l’avance,

Bruno Larouche

2

A mon avis le premier problème c’est déjà d’être d’accord sur la définition de maturité …

2 « J'aime »
3

Parfait, et tu suggères quoi comme grande lignes de la définition de maturité ?

4

Je propose autre chose : ne pas parler de maturité. Il est impossible de se mettre d’accord, car chacun voit la maturité d’une autre manière. Discuter de la maturité peut devenir le problème, plutôt qu’être une solution, d’expérience.

Donc idée, si tu cherches à le savoir quand même : Demande à chaque personne de ton équipe ce qu’est une personne mature, puis ce qu’est une équipe mature. Montre les résultats en même temps et lance une discussion là-dessus !

Sinon, sur comment emmener des équipes vers une autre manière de fonctionner, c’est un peu toujours la même logique :

  • Définir l’état à atteindre.
  • Regarder notre état actuel.
  • Commencer à regarder les premières étapes pour y arriver.
  • Les mettre en place.
  • En discuter et voir ce qui peut être amélioré.
  • Revenir au début.

Il n’existe pas de balle en argent. Chaque équipe est totalement différente. Le contexte est différent. Donc je propose d’arrêter de penser « maturité » mais plutôt « quels sont les problèmes que l’équipe cherche à résoudre ? » et de les résoudre avec eux.

Ca va plaire à certains ici : n’hésite pas à t’intéresser à Cynefin pour ça. En fonction de là où tu te trouves dans le modèle, tu n’utiliseras pas les mêmes outils.
Par exemple, un diagramme d’Ishikawa marche pas trop mal dans une problématique simple à compliquée. Si le problème est complexe, ça empire les problèmes…

Globalement le livre de Lyssa Adkins « Coaching Agile Teams » a été un début de révélation pour moi à l’époque.

EDIT : pour répondre à la question, si la maturité t’intéresse les travaux de Clare Graves peuvent être intéressant. Il a pas fait les choses d’une manière purement scientifique sur la « maturité » mais au moins ça donne à réfléchir.
Côté outils, sur la technique « Accelerate » est une valeur sûre.
Sur la partie accompagnement d’équipe, les travaux de coachs pros comme Lyssa Adkins, Alain Cardon, François Délivré, Michel Moral… renferment de très bonnes idées.
Pour aller encore plus loin sur le changement et la psychologie, j’aime beaucoup Arnaud Tonnelé sur le changement organisationnel, ainsi que la TCC (thérapie cognitive et comportementale) et la stratégie systémie de palo alto comme modèles utilisables concrètements.
Sur la partie agilité, le modèle « Agile Fluency » peut t’aider à emmener l’équipe vers la prochaine direction, si elle ne sait pas elle-même où aller.

2 « J'aime »
5

Tout à fait d’accord avec la position de Benjamin. Cependant, discuter avec chaque membre de l’équipe de « c’est quoi la maturité pour toi ? » risque surtout de lancer un débat d’idées sans fin.

Une question - à mon avis - plus concrète à se poser dans un premier temps : Quel comportement actuel de l’équipe associes-tu à de l’immaturité et voudrais-tu faire évoluer ?

1 « J'aime »
6

Bonjour,

Je vais donner un peu de précision. C’est une équipe dans un organisme du Gouvernement du Québec. Ils sont blindés d’une permanence presque à tout risque. Comme on dit par chez nous " Bien assis sur la chaise".

L’idée du sondage ou du questionnement individuel de Benjamin n’est pas mauvaise en soi. Mais, elle ne pourra pas fonctionner. Première, elle briserait l’idée de la transparence que je veux avoir. D’autre part, je n’ai pas de lien hiérarchique avec eux. Donc, je ne peux pas me lancer dans interrogation ou évaluation d’une manière ou d’une autre. Ils ne participeraient pas efficacement sans ce lien hiérarchique. Donc, je dois l’éliminer.

C’est vrai, je devrais relire "Coaching Agile Teams ". Ma première lecture remonte à trop longtemps. Merci aussi pour les autres références, je vais être obligé de me passer un de sommeil pour les lire :wink:

Adrien pour réponse à ta question : Quel comportement actuel de l’équipe associes-tu à de l’immaturité et voudrais-tu faire évoluer ?

Une somme de détails, en voici quelque exemple sans pour autant être limitatif.

  • Arrivé sans bonne préparation aux évènements Scrum

*Auto-Gestion, Auto-Organisation au cœur de Scrum

  • Manque de suivi généralisé, n’avance ou ne documente pas les éléments de travail.

  • Manque d’initiative généralisée

Une particulière, nous sommes en train de passer certain environnement au « Cloud » et la construction de ces environnements « Cloud ». Elle est faite par une autre équipe dédiée. Pour différentes raisons, l’équipe "Cloud’ a pris beaucoup de retard dans cette mise en place de nos environnements. Ce qui a eu pour conséquence de mettre en pause le projet de développement. Je me serais attendu de la part des membres de l’équipe dans ce temps de disponibilités certaines choses.

  • Nous avons déjà plusieurs applications avec mes technologies (SLES/Typpo3/PHP) et personne de leur initiative, a pris les devants de vérifier la désuétude de nos environnements. Elles le sont, j’ai vérifié. Ça m’a pris 10 minutes, une après-midi. Car, nous avons un référentiel technologique de nos applications et quelques recherche Web.

  • Manque d’initiative vers la formation ou veilles technologique, exemple c’est quoi les nouvelles fonctionnalités de Typo3 ou les impacts possibles sur nos environnements.

  • Nous travaillons en mode Scrum, Lire de Guide Scrum, se former sur la méthode pour la comprendre.

  • Réfléchir et s’outiller pour mieux effectuer leur travail, c’est eu les spécialistes Typo3/PHP.

Quant aux solutions, elles, je n’en ferai pas d’énumération. Car, je veux qu’ensemble on effectue une réflexion sur l’amélioration de cette maturité. Oui, je me base sur le cas de mon équipe. Mais, je suis à quête de solution plus générale qui pourront aider plus large que moi et mon équipe ! En expliquant, mes pistes de solutions, j’ai peur de biaiser vos pistes de solutions.

Je ne cherche pas un encrage pour fixer le tableau. Mais, des graines et des jardiniers pour faire fleurir encore notre jardin de l’agilité.

Bruno Larouche

7

Bonjour,

Un détail que j’ai oublié au sujet de la maturité.

Un jour, un sage m’a dit : « Arrête de dire que tu es quelque chose ou que tu es rendu à niveau de quelque choses. Soit, le cette choses. Et tu n’auras plus besoins de le dire. Ça sera transparent dans ton attitude ou ta manière d’être. »

Donc, Je rêve de voir cela avec mon équipe. Arrête d’affirmer qu’elle a un certain maturité. Et, que cette maturité soit transparente dans leur actes et actions.

Bruno Larouche

8

Certains éléments sont assez génériques dans leur formulation, il est donc difficile d’y répondre autrement qu’avec des généralités. Ces situations et attitudes problématiques peuvent-elles être priorisées et abordées en rétrospective ? L’ont-elles été et si oui pourquoi ça n’a pas été suivi d’effet ?

Beaucoup d’éléments ont trait à l’implication des développeurs, plutôt qu’à la maturité. Avez-vous fait un état des lieux des pratiques actuelles à ce sujet dans l’organisation ? L’attitude positive de certaines équipes et certains développeurs (dans d’autres équipes) est-elle mise en avant ? Est-ce une attitude valorisée par l’organisation ?

Remarque assez classique.

En général les développeurs éludent ce partie travail parce que la valeur perçue de ce travail de documentation est considéré comme mauvaise. Ce que je veux dire, c’est qu’une équipe performante - la cible vers laquelle on devrait aller - ce n’est pas une équipe qui communique mieux l’avancement, mais une équipe qui n’a pas besoin de communiquer l’avancement. Si on a besoin de se communiquer de l’avancement, alors c’est qu’on est un groupe d’individus et non une équipe. Quand on travaille en collaboration étroite, on n’a pas besoin de se communiquer l’avancement parce qu’on est directement en train d’avancer ensemble.

Comment le travail de l’équipe s’inscrit-il au regard du « stream » applicatif ? Cette attitude est assez classique pour les équipes de développement qui sont en mode codage. Le mode codage, c’est quand on nous donne une spécification à implémenter. On ne peut donc pas aller plus loin, intellectuellement que de se demander si on a fait un codage conforme ou non-conforme à la spécification. Or ce point est indépendant d’avoir une application utilisable ou non. En effet, ça dépend si le bureau d’étude à fait une bonne conception en amont, ou non, et si l’équipe d’exploitation a réalisé le déploiement correctement en aval.

L’implication est meilleure quand on fonctionne en mode ingénierie. Cette fois on nous donne un besoin (et non une solution). L’équipe doit donc à la fois prendre la responsabilité de la conception, du codage, du test, du déploiement, et du support. On bascule sur un mode beaucoup plus stream-aligned. Dans ce contexte, comme on est en prise directe avec les utilisateurs (à la fois en amont et en aval), il y a plus d’enjeu à faire un produit utilisable.

Par contre, il faut parfois un petit coup de pouce sur certaines pratiques organisationnelles. Par exemple, l’erreur que beaucoup de gens font avec Scrum c’est de mettre des « tech stories » dans le backlog. Soit on parle d’une amélioration technique, dans ce cas il faut savoir la traduire en impact business pour la prioriser au même titre que n’importe quel story, soit c’est un exigence (par exemple une version obsolète d’un composant) et à ce moment là il faut la mettre dans la DOD.

1 « J'aime »
9

« ne documente pas » me fait sourire lorsque je repense aux valeurs agiles :slight_smile:

10

Du point de vue du manifeste agile, « ne pas documenter » ça reste un problème.

Ce que le manifeste dénonce c’est quand une documentation exhaustive est plus importante qu’un logiciel fonctionnel. Dit autrement, c’est quand les développeurs ont plein de bugs à corriger mais qu’ils font l’effort sur la documentation (en particulier sur les aspects secondaires de celle-ci) plutôt que sur la correction du produit.

1 « J'aime »
11

Je suis d’accord. Mais jusqu’ici aucune information ne confirme que le logiciel n’est pas fonctionnel et/ou que la documentation n’est pas suffisante, enfin je ne le crois pas.
Il y a également d’autres pratiques de documentation que la création de pages confluence par exemple (ce que je traduis de la lecture des messages de Bruno)

12

MERCI de vos commentaires. Je sais que je n’ai pas répondu à chacun ou encore, j’ai manqué de détail (Volontairement).

Mais, je crois que vos différents commentaires ou questionnements ont permis de poursuivre la réflexion sur comment « Emmener » l’équipe vers une nouvelle maturité.

J’ai continué mes recherches et ma veille pour emmener l’équipe vers cette nouvelle quête. En élargissant mes recherches. J’ai pensé au Management 3.0. Ca répond le comment améliorer la Maturité. Mais, le comment l’emmener vers cette nouvelle étape.

Je vous propose cette liste de lecture d’une autre chaine en langue française : https://www.youtube.com/playlist?list=PL9Q_Ei1JWJ4ddMb00Y1zBvW_2VND9I1mr

et une vidéo de cette chaine : https://www.youtube.com/watch?v=lX4YQv03Kl0

Bruno Larouche

13

:100:

Absolument pas. Sauf dans des cas où on est sûr qu’il existe une bonne pratique applicable dans le contexte, l’amélioration du fonctionnement est un problème complexe. Selon Cynefin, il est contre-productif de définir un état à atteindre pour deux raisons :

  • On ne sait pas si l’état désiré est atteignable.
  • Même si l’état désiré est atteignable, on ne sait pas quels effets secondaires nous attendent en arrivant. (cf. La patte de singe)

OK, mais il faut être psy pour pouvoir l’appliquer correctement. Il y a une déontologie à intégrer et à respecter.

Ca fait des années qu’on essaie et que ça ne marche pas (cf par exemple Complexity theories and Systems Thinking: parallels and differences)

:+1:

1 « J'aime »
14

:scream: :x: Non, mais vraiment non. Le Management 3.0, c’est un des pires trucs pseudoscientifiques. Tu ferais mieux de lire les Lost in Management de François Dupuy ou le plus récent Leadership, agilité, bonheur au travail…bullshit ! de Christophe Genoud.

15

Le seul moment où je m’autorise à parler de maturité, c’est quand il y a des personnes qui n’ont pas un comportement digne d’un adulte sur un lieu de travail. Si l’on parle de cette maturité-là, alors je recommanderait des livres sur la parentalité.

Sinon, @Bruno_Larouche, d’après les détails que tu donnes, j’ai l’impression que tu es trop gourmand dans ce que tu veux faire faire aux équipes. Tu ne peux pas sauver tout le monde et le changement des autres n’arrivera jamais au rythme que tu le voudras. Est-ce que tu remontes les lacunes que tu observes au management ?

Enfin, je te conseille une fois de plus de t’intéresser un peu plus à Cynefin, en commençant par https://youtu.be/MsLmjoAp_Dg.

16

Un message a été scindé en un nouveau sujet : Commençons par définir

17

Juste sur la stratégie systémique : je fais une nette différence entre l’approche systémique de palo alto et la pensée systémique. Ce ne sont pas les mêmes choses et les mêmes approches. Ce que je dis n’a rien à voir avec Peter Senge & Donella Meadows, mais plus avec les approches de Bateson et Watzlawick. D’ailleurs, les approches de ces 2 là se rapportent plus au CAS qu’à ST.
Juste pour être sur qu’on parle bien de la même chose !

18

Bonjour M. William,

Ça doit être les jeux Olympiques de Parie qui m’ont inspiré d’en faire tous des olympiens. :upside_down_face:

Oui, je sais, je vise l’excellence, mon objectif ultime. C’est mon rêve fou, un rêve que je poursuis peut-être longtemps (et je radote peut-être, j’ai passé la cinquantaine et plus de 20 ans à vivre l’agilité… :crazy_face:).

Mais, mon objectif ce n’est pas de l’atteinte que cette équipe atteigne les plus sommet de la maturité. Mais de leur donner les plus grandes aspiration possible et d’essayer des les outils en conséquence.

Ma mère, nous disait à moi et mes 2 sœurs, ce n’est pas important à quelle niveau d’étude que vous rendrez. L’important c’est que vous irez au maximum de vos capacités et que cela vous rendra heureux. J’avoue, que je n’ai pas encore atteint cette limite perso (pas de limites). Je ne serais jamais lanceur de marteau (Oui, je suis Canadien) et encore, moins nageuse olympienne ! J’ai seulement cœur à croire que j’aide et j’accompagne, les individus et leur organisation, à atteindre, voir dépasser leur objectif. Un pas à la fois !

Bruno Larouche

1 « J'aime »
19

Ca marche.
Je te propose de continuer à noter les moments où les équipes ne font pas les choses comme tu les aurais vu faire et de les décortiquer avec la typologie ASHEN (ou ACHET en français) :

  • Artefacts : documents, outils, applications…
  • Compétences : tout ce qui peut être enseigné et acquis
  • Heuristiques : habitudes, rituels, règles de jugeote…
  • Expérience : le vécu qui, par la pratique et l’observation, a fait grandir
  • Talent naturel : les capacités innées ou inexpliquées qu’on a de façon singulière

Après avoir cartographié ça, toi, les équipes, le management, peuvent réfléchir à comment apporter ces différents savoirs.

2 « J'aime »
20

MERCI, c’est outils que je ne connaissais pas et qui pourra surement intéresser la communauté.

Vous donnez un bel exemple d’outils, une conséquence positive, pour cette réflexion de l’augmentation de maturité l’équipe. En lançant cette discussion, je voulais qu’on réfléchisse ensemble sur cette amélioration de la maturité, qu’on s’outille ensemble.

Bruno Larouche