Robert 'Bob' Galen
http://www.projecttimes.com/robert-galen/the-agile-project-managerfail-now-as-a-strategy.html
Par Robert ‘Bob’ Galen
J’étais à une conférence il y a peu de temps parlant et partageant sur divers sujets agiles. Comme il arrive souvent, un jeune homme m’a arrêté afin de me poser quelques questions après ma présentation. Nous avons entamé une conversation agréable qui a finalement débordé jusqu’au corridor de l’hôtel.
Nous avons commencé à parler de la dynamique de sprint dans des équipes Scrum et je suis arrivé de mentionner que je coache souvent des équipes vers la déclaration de leurs sprints en tant que succès ou… (pause pour plus d’effet) échec. Que nous faisons ceci comme partie intégrante de la revue de Sprint avec les équipes, le Propriétaire de Produit étant le décisionnaire final en se basant sur selon que l’équipe a atteint les Objectifs de Sprint ou pas.
Il a été visiblement énervé par mon avis. Il a dit qu’ils (il travaillait dans une société bien connue d’Atlanta) n’avaient jamais échoué de sprint. Jamais! Ils ne pouvaient pas, ni n’utilisaient ce MOT dans leur culture. Je lui ai demandé catégoriquement : n’avez-vous jamais échoué un sprint ? Il a dit bien sûr qu’ils l’avaient. Plusieurs fois. Mais au lieu d’utiliser le terme échec, ils ont utilisé le terme ‘challenge’. De cette façon, les parties prenantes ne se feraient pas de fausse idée et ne mettraient pas en doute les compétences ou la motivation de l’équipe.
Nous avons tourné en rond pendant 10 à 15 minutes de plus dans notre discussion, mais nous n’avons jamais vraiment réglé nos différences. Nous avons simplement consenti à être en désaccord. Bien que ce ne soit pas un terriblement large abîme entre nous, je me rappelle distinctement revenir vers ma chambre en secouant la tête. Je n’avais tout simplement pas compris le grand cas fait de l’échec. De l’utilisation du mot. D’une équipe disant…nous avons échoué. Dans mon job de coach et dans mes “tâches journalières”, j’ai pu diriger et développer nos idées pour que l’échec ne soit pas un gros mot. C’est-à-dire l’échec est bon. L’échec est ok. L’échec mène à l’amélioration. L’échec fait partie de la vie.
Aussi, dans ce billet, je veux discuter de l’échec depuis quelques perspectives différentes. La discussion n’est pas destinée à être complète. Au lieu de cela, je veux juste partager quelques pensées avec vous et vous faire réfléchir sur l’échec… sur comment vous le percevez dans votre organisation, quelle est votre tolérance à l’échec et reconsidérer vos réactions normales face à lui. Je pense que cela vous mènera aussi à considérer votre management de risque, parce que je pense que les deux sont inextricablement liés.
Coacher pour éviter l’échec
Dans son blog du 20 juin 2011, s’intitulant Coaching is Not Letting Your Teams Fail (Coacher c’est ne pas laisser vos équipes échouer), Giora Morein justifie que des coach agiles devraient amener ou guider leurs équipes loin de l’échec. Il donne l’analogie d’un Sherpa guidant des alpinistes. Et oui, dans l’exemple de l’alpinisme en montagne, je dois reconnaître que l’échec n’est probablement pas le résultat que nous voulons.
Cependant, dans les environnements qui ne mettent pas la vie en danger, je pense que je ne suis pas d’accord avec Giora. Je crois de tout cœur que l’échec peut en réalité être bon pour une équipe. Je pense aussi que le rôle du coach est d’aider une équipe à regarder sa performance de deux perspectives. La plus facile des deux est la perspective de succès. C’est la perspective où vous donnez un retour d’information positif à l’équipe; où vous leur dites qu’ils ont besoin de répéter les pratiques qui marchent pour eux. En fait, quelles pratiques ils doivent amplifier et faire “davantage” afin d’atteindre des résultats de plus en plus importants.
Ces conversations sont clairement plus faciles.
Mais en ce qui concerne la perspective d’échec ? Comme coach, fournissez-vous une critique constructive ? Montrez-vous à une équipe où ils ont trébuché ? Tant individuellement que comme une équipe ? Je pense que vous le devez. Mais certainement pas de façon malveillante ou maladroite. Je pense si vous coachez efficacement une équipe vous devez explorer leurs erreurs et faux pas avec la même passion et énergie que quand vous traitez leurs succès.
Et je ne pense pas que vous le faites tranquillement, en vous cachant derrière des portes et sans reconnaître de leurs challenges. Non. Je pense que vous l’approchez de façon totalement transparente et pratique. En établissant au départ que l’échec est apprécié et bien accueilli. Que depuis l’échec, vos équipes cherchent des possibilités d’amélioration et avancent rapidement vers l’atteinte de meilleurs résultats.
Exposition Agile
Dans des équipes agiles, il y a deux cérémonies clés qui sont concentrées sur les résultats réussis ou pas de l’équipe. Dans Scrum, c’est la Revue de Sprint (la démonstration) et la Rétrospective de Sprint (les leçons apprises). Typiquement la revue de sprint est exposée au monde, donc vous pourriez vouloir être prudents sur comment vous énoncez vos échecs – pour que les parties prenantes n’interprètent pas mal l’impact ou l’effort consenti par l’équipe. Néanmoins, je crois que vous devriez déclarer des sprints succès ou échecs pendant l’introduction à la revue d’équipes.
Dans Scrum, c’est le rôle des Propriétaires de Produit de déterminer cela. Et c’est relatif aux objectifs sur lesquels l’équipe s’est engagée au début du sprint. On espère que ces objectifs étaient assez flexibles pour permettre à l’équipe d’ajuster leur travail pour les atteindre avec créativité.
Par exemple, je pense qu’un très mauvais objectif de sprint est quelque chose autour de l’équipe livrant un nombre d’histoires utilisateur – ou autres indicateurs d’exécution par cœur. Je pense que cela mène à un en-sablage potentiel de la part de l’équipe pour atteindre un but numérique plutôt que de penser au vrai problème qu’ils essayent de résoudre. Au lieu de cela, je pense que de meilleurs buts tournent autour de la réalisation d’une sorte de démonstration d’un comportement qui résout un jeu spécifique de problèmes clients. Donc le succès est mesuré sur comment l’équipe a respecté l’esprit de l’objectif et combien ils ont appliqué les principes agiles dans leur exécution.
Par exemple, j’ai vu des équipes qui s’engagent sur 10 histoires utilisateur, mais qui avaient 3 jours de temps mort à la fin de leur sprint, rater leur sprint. Pour sûr, ils ont bien livré par rapport à leur engagement, mais leur engagement était faussé. Ils s’étaient protégés et avait surestimé. De plus, ils n’ont pas fait part de leur capacité supplémentaire disponible à leur Propriétaire de Produit ni demandé davantage de travail dans leur sprint. Au lieu de cela ils ont planifié d’avance ou « plaqué or » leurs produits.
J’ai aussi vu des équipes qui s’engagent sur 10 histoires, mais en livrent 7 et ont un sprint très réussi. En cela qu’ils travaillent dur dans la complexité et l’adversité. Ils sont incroyablement transparents et engagent leur Propriétaire de Produit à faire des ajustements quotidiens sur les priorités en fonction de leur actuelle compréhension de leur capacité. Et en tant qu’équipe, bien qu’ils n’aient pas livré la quantité prévue à l’origine, ce qu’ils ont vraiment livré est aligné sur leurs objectifs et respecte l’esprit et l’intention du Propriétaire de Produit.
Ces deux cas devraient être discutés pendant la rétrospective des équipes et les façons de s’améliorer discutées. Pas de petite façon et sans ignorer les premiers troubles du comportement de l’équipe. Non. Tout cela, le bon, le mauvais (erreurs et échecs) et idées d’amélioration significatives, sera discuté pour que l’équipe décide de quels points sont dignes de leur attention pour amélioration dans le sprint suivant.
Mais l’échec est-il apprécié ?
En continuant sur mon exemple de coaching précédent, je me souviens qu’il n’y a pas longtemps je parlais à un groupe de nos Scrum Masters dans mon “travail de jour” chez iContact. Si vous ne connaissez pas Scrum, le Scrum Master est le coach et le guide principal et la voix du leadership agile dans l’équipe Scrum agile. Il est aussi responsable d’entretenir des valeurs agiles clés dans l’équipe et e la performance générale des équipes. Ce que j’entends par cela est qu’il guide les équipes vers une performance qui s’améliore dans la durée. Posant continuellement des questions comme : son équipe s’améliore-t-elle dans sa performance globale ? Sa vitesse s’améliore-t-elle ? Sa qualité de travail s’améliore-t-elle ? La collaboration et le travail en équipe s’améliorent-ils ? Et, leur focus est-il sur l’amélioration de la valeur livrée pour le client ?
Donc mon point auprès des Scrum Masters était que j’estimais que nous n’avions pas échoué depuis quelque temps. J’ai défini l’échec dans ce cas comme un échec de sprint ou un incident dans lequel une équipe s’est essentiellement heurtée à un obstacle et a eu besoin de re-planifier ou revoir l’alignement son sprint.
Ils ont tous été d’accord avec moi que les choses s’étaient déroulées sans à-coups. Et j’ai reçu plus que quelques regards interrogateurs fixes quant à pourquoi c’était un problème. J’ai essayé d’être prudent dans ma réponse, mais ma préoccupation était qu’il se pourrait que nous la jouions un peu trop sûrs. Que nous devenions complaisants dans nos pratiques agiles et que nous ne nous challengions pas assez. Que nous ne tentions rien. Et ne courrions pas de risques.
J’ai expliqué que ces caractéristiques sont fondamentales pour la croissance et la progression d’équipes agiles. Et le fait que nous ne rencontrions pas d’échecs indique que nous avons atteint un plateau dans notre croissance et notre performance. J’ai estimé que c’était un problème…et pour lequel j’ai demandé s’ils pourraient obtenir davantage d’échecs des équipes.
Pouvez-vous imaginer le reste de cette discussion ?
Me voilà le Directeur de R&D dans une société qui réussit en train de parler à mon équipe de Scrum Masters et leur demander d’amener plus d’échecs, pour inciter leurs équipes à davantage de prise de risques et inspirer des objectifs plus agressifs. Le point que j’essaye de faire passer est que j’apprécie vraiment l’échec. Que j’ai appris à le voir comme un critère critique de succès et que son absence est un problème pour moi. Je me demande combien d’organisations et de leaders ont la même position.
La notion de “Chuter en avant”
Un de mes auteurs préférés est John C. Maxwell. Il est relativement bien connu comme un coach en leadership et un prolifique auteur avec plus de 50 livres sur divers sujets de leadership. Il a un fort contexte Chrétien dans sa vie et dans son écriture, mais si vous n’êtes pas aussi enclins, ne laissez pas cela vous rebuter. Il maîtrise pleinement l’art du leadership.
Il y a quelques années il a publié un livre : Failing Forward—Turning Mistakes Into Stepping Stones to Success. Dans celui-ci, il souligne l’échec comme un facteur de réelle transformation dans nos vies personnelles, professionnelles et en équipes. Mais il place soigneusement l’échec dans une position d’avancée. Au lieu de voir l’échec comme un état final négatif et nous en plaindre, nous devrions l’embrasser comme une expérience à portée pédagogique positive. Que nous nous “penchions en avant” en démultipliant les leçons apprises pour nous améliorer.
Je ne pense pas que Maxwell souffle simplement un nuage de fumée positive dans notre direction. L’histoire est clairement encombrée d’exemples de succès qui ont été inspirés, forgés et durcis par le feu de l’échec. Thomas Edison en est un exemple célèbre quand il a persévéré pour inventer l’ampoule électrique.
Dans mon coaching agile j’utilise de manière consistante la terminologie “chuter en avant” quand je discute des échecs d’équipes. Oui, je veux qu’une équipe soit honnête avec elle-même et reconnaisse qu’elle a échoué. Mais je veux aussi que ses membres embrassent leurs erreurs au lieu de devenir défensifs, blâmer d’autres personnes ou être dans le plein déni. Et je veux que leur position les fasse se « pencher vers l’avant ». Désireux d’essayer quelque chose de nouveau qui amènera des résultats différents. Sans avoir peur de l’échec.
Je constate qu’en utilisant cette terminologie, j’aide des équipes à comprendre la nature de l’échec et à se comporter convenablement. Mais au-delà de la terminologie, les leaderships de projet et fonctionnel doivent aussi pleinement supporter l’idée. CE qui signifie que l’équipe de direction toute entière doit supporter l’échec. Voilà…je l’ai dit.
En conclusion – Mais, je suis un peu étrange …
Tout ceci étant dit, je me demande si j’ai une vue étrange et largement minoritaire envers l’échec ? Je me demande si la bonne réponse doit en effet de le craindre, de nier son existence, de passer d’innombrables heures à essayer de le prévoir, de ne jamais le mentionner en public. Est-ce que de telles actions sont les bonnes réponses ?
À cette fin, je ferme ce billet avec une requête auprès de tous les lecteurs. J’ai préparé une brève enquête, que je voudrais vous proposer. Je sais, je sais, vous êtes occupés. Mais je pense vraiment que vos idées seront ici utiles. L’enquête est centrée sur la construction d’une vue sur l’acceptation organisationnelle, de groupe/équipe et individuelle de l’échec et du risque. J’essaye d’obtenir à une compréhension profonde de cette acceptation et aussi de ses causes racines. Même si je suis particulièrement intéressé par les équipes agiles, ne laissez pas votre manque d’expérience agile vous empêcher de répondre.
Enter Survey Here…
)
