Le manifeste Agile : Pourquoi l’Agilité a du sens

Le 27 avril 20229 avril 2022 par mopertodans agileLaisser un commentaire

Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire.

The Agile Manifesto: Why Agile Makes Sense

https://www.benlinders.com/2021/the-agile-manifesto-why-agile-makes-sense/ by Ben Linders

Pourquoi l’agilité a du sens

Lorsque le manifeste agile a été publié en 2001, il était à la fois attendu depuis longtemps et bien en avance sur son temps.

Les méthodes de développement de logiciels axées sur des plans prédictifs ont échoué pendant de nombreuses années au cours du siècle dernier. Elles échouent toujours. Les rapports CHAOS du Standish Group montrent année après année que la plupart des projets informatiques échouent ou connaissent de grosses difficultés. Pour ceux qui réussissent, l’agilité y joue souvent un rôle. Au moment de la publication du manifeste, il était attendu depuis longtemps : nous savions depuis de nombreuses années que faire plus de plans et de meilleurs plans et gérer les projets dans les détails n’était pas la voie à suivre. Nous avions besoin d’une nouvelle approche, d’un nouvel état d’esprit.

Ensuite, des idées telles que travailler en équipe, collaborer étroitement avec les clients, livrer en cycles courts, faire des rétrospectives et adapter notre façon de travailler, challengeaient les personnes et les organisations en 2001. Le monde n’était pas prêt pour cela à ce moment-là. Je me demande en fait s’il est prêt pour cela maintenant, vingt ans plus tard ?

Quand le manifeste a été publié, ce n’était pas quelque chose de « nouveau » pour moi. Mais cela avait beaucoup de sens. J’ai commencé avec l’agilité avant l’invention d’Agile, dans les années 80s. J’ai adopté l’approche pour offrir de la valeur à mon client par incréments parce que cela avait du sens pour moi et mon équipe. Nous avons collaboré, fait des démonstrations de produits, réfléchi à notre façon de travailler et avons adaptée cette approche. Elle nous a aidé à livrer un meilleur produit plus rapidement. En 2001, elle a reçu un nom : Agile.

Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire. La publication du manifeste a supporté une vague de nouvelles réflexions sur la façon dont les humains collaborent et communiquent. Pourtant, de nombreuses personnes ont du mal à appliquer l’agilité dans leur contexte spécifique.

Pour aider à donner du sens au Manifeste Agile et l’appliquer pour réfléchir et apprendre, j’ai créé les Cartes de Questions Rétrospectives du Manifeste Agile. Elles peuvent être téléchargées dans ma boutique en ligne pour une somme modique.

Ces cartes contiennent des questions puissantes pour inspirer vos rétrospectives agiles et les garder précieuses et efficaces. Il y a 15 questions pour chacune des quatre valeurs du manifeste, à la fois pour les côtés gauche et droit de la valeur (c’est « ensemble » donc les deux côtés sont précieux). Et 12 questions bonus que vous pouvez utiliser pour aider les équipes à réfléchir à leur parcours agile, et des cartes vides que vous pouvez utiliser pour ajouter vos propres questions. Au total, il y a 78 cartes avec des questions puissantes.

Poser des questions peut aider à approfondir la compréhension et à mieux comprendre ce qui se passe. Le manifeste agile n’apporte pas de réponses ni de solutions. Il guide vers les choses qui ont du sens, qui comptent. Avec ces conseils, nous pouvons trouver des réponses et trouver des solutions qui fonctionnent pour nous.

En résumé, Agile avec le manifeste Agile me semble être du bon sens pour développer des produits. Malheureusement, le bon sens n’est pas si commun.

Comment les auteurs du manifeste agile m’ont inspiré

Au fil des ans, j’ai rencontré et parlé avec la plupart des auteurs du manifeste Agile. J’ai interagi avec eux lors de conférences où nous avons présenté et partagé nos histoires ou fait des interviews ensemble. J’ai lu leurs livres, articles, blogs et bien plus encore. J’ai eu des discussions avec eux sur LinkedIn, Twitter, Slack ou par e-mail. J’ai également interviewé la plupart d’entre eux en tant que rédacteur en chef pour InfoQ car je voulais partager leur expérience.

Voici comment je me suis inspiré d’eux : Vous trouverez ci-dessous mes histoires inspirées du deuxième bloc de six auteurs du manifeste agile (par ordre alphabétique).

James Grenning

J’ai rencontré James Grenning pour la première fois à la conférence OOP 2015. Nous avons parlé des odeurs du code, ce sur quoi j’ai travaillé en combinaison avec des revues de code. Inspiré par mon expérience, nos discussions et la réflexion sur la façon dont je facilite et enseigne en facilitant les rétrospectives agiles, j’ai trouvé le concept d’odeurs rétrospectives : Des signaux qu’il y a potentiellement quelque chose qui ne va pas dans votre rétrospective. J’ai écrit series of articles on retrospective smells et créé les Agile Retrospective Smells Cards.

J’ai fait un Q&R avec James sur Test Driven Development et Code Smells pour InfoQ où je lui ai demandé pourquoi les programmeurs doivent avoir un bon nez pour les odeurs du code :

Le programmeur qui veut améliorer le code sur lequel il travaille a besoin de trois compétences essentielles. Un bon nez pour le code, des compétences pour envisager un design amélioré et les compétences pour transformer le code malodorant en un meilleur code.

Dit plus simplement, si vous ne pouvez pas identifier avec une certaine précision un problème dans la structure du code, comment pouvez-vous le résoudre ? Je me souviens que les revues de code dans ma carrière n’étaient généralement qu’une question d’opinion. « Je n’aime pas ça, j’aurais fait ça », totalement non justifié. N’importe quel programmeur peut annoncer « ce code pue », mais ce n’est pas suffisant. Un chef dans la cuisine hume une bouffée d’air et dit « jetez les pommes de terre, elles sont mauvaises, et prenez-en des fraîches ». Les programmeurs doivent être en mesure d’identifier des odeurs spécifiques pour avoir une idée de la façon d’améliorer le code.

James Grenning sur InfoQ

James a eu l’idée du planning poker. C’est un excellent moyen d’appliquer la gamification et les jeux pour augmenter la participation des développeurs et créer un environnement sûr permettant aux gens de partager leurs idées et leurs sentiments sur quelque chose d’aussi délicat que les estimations. Dans le planning poker, tomber d’accord ne nécessite pas de débats inutiles. Mon expérience est la même avec des techniques telles que les estimations Delphi à large bande et les bilans de santé ; en utilisant ces techniques, je suggère de passer du temps à discuter des différences car c’est là que se trouvent les apprentissages.

Jim Highsmith

J’ai vu Jim Highsmith faire une présentation à l’une des premières conférences SM/ASM auxquelles j’ai assisté, je crois que c’était en 2001 ou 2002. Ce sont les premières grandes conférences américaines auxquelles je suis allé et dans lesquelles j’ai ensuite pris la parole. J’ai beaucoup appris lors de ces conférences que j’ai utilisées au fil des ans pour mesurer et améliorer la qualité des logiciels lorsque je travaillais chez Ericsson, et j’ai étendu mon réseau professionnel à de nouveaux domaines.

En 2004, Jim Highsmith a publié le livre Agile Project Management. Il est recommandé de lire si vous devez faire des projets et que vous voulez apprendre à mieux les faire :

Dans un projet agile, l’équipe s’occupe des tâches et le chef de projet s’occupe de l’équipe.

Gestion de projet agile par Jim Highsmith

Appliquer le concept d’agilité à la façon dont les projets sont gérés avait du sens au départ pour moi, mais j’ai vu cela échouer beaucoup plus souvent que réussir. L’échec était le plus souvent dû au fait de ne pas adopter l’état d’esprit agile, mais plutôt d’utiliser à mauvais escient l’agilité comme excuse pour répartir le travail de planification entre les membres de l’équipe tout en essayant de tout micro-manager.

La gestion de projets avec agile est un sujet complexe sur lequel j’ai écrit plusieurs articles au début de mon entreprise unipersonnelle : Agile project management, Managing and reporting agile projects, Fixing scope in agile projects, and Managing projects with agile teams. Au fil des ans, je me suis éloigné de la gestion de projet, et mon attention s’est déplacée vers le management des produits et des équipes, ce qui, selon moi, est une approche plus viable et durable pour générer de la valeur. Au cours des dernières années, j’ai présenté et écrit sur les choses Dos and Don’ts of Agile Management.

Andrew Hunt

Andrew Hunt a écrit le livre The Pragmatic Programmer (avec Dave Thomas). Il a été publié à l’origine en 1999, mais la version que j’ai lue est l’édition du 20e anniversaire publiée en 2019.

L’essence de l’agilité, comme indiqué dans « le programmeur pragmatique »

Agile est un adjectif : c’est comment on fait quelque chose. Vous pouvez être un développeur agile. Vous pouvez faire partie d’une équipe qui adopte des pratiques agiles, une équipe qui réagit au changement et aux revers avec agilité. L’agilité, c’est votre style, pas vous.

David Thomas et Andrew Hunt dans The Pragmatic Programmer – Édition du 20e anniversaire

Je partage ce point de vue ; agile n’est pas ce que vous êtes, mais ce que vous faites et comment vous le faites. Le manifeste ne fournit qu’un ensemble de valeurs et de principes, il appartient à chaque individu de réfléchir à la façon de les appliquer et d’agir d’une manière qui a du sens.

En lisant ce livre, je voulais faire un Q&R (interview écrite) avec Andrew et Dave. J’ai posé des questions sur des sujets dans lesquels se plonger. Il s’est avéré qu’Andrew et Dave préféraient faire un podcast ; Voici l’interview que mon collègue rédacteur en chef d’InfoQ, Shane Hastie, a réalisé avec eux : Dave Thomas & Andy Hunt on the 20th Anniversary Edition of The Pragmatic Programmer.

Andrew a fondé la série Pragmatic Bookshelf avec Dave. Il s’avère que j’ai lu beaucoup de livres publiés par eux :

Create Your Successful Agile Project by Johanna Rothman
Code with the Wisdom of the Crowd by Mark Pearl
Liftoff, Second Edition by Diana Larsen and Ainsley Nies
Creating Great Teams by Sandy Mamoli and David Mole
Agile Retrospectives by Esther Derby and Diana Larsen
Become an Effective Software Engineering Manager by James Stanier
Competing with Unicorns by Jonathan Rasmusson

Ron Jeffreys

J’ai été en contact avec Ron Jeffries au fil des ans par courriel. Nous avons eu de brefs échanges liées à des discussions sur Twitter, des publications sur InfoQ ou l’un de mes livres. Ron est assez direct sur ce qu’il peut ou ne peut pas faire, quelque chose que je reconnais et apprécie (je suis néerlandais).

Ron Jeffries a « inventé » les Story Points comme un concept pour estimer la taille des histoires dans XP. Avec les Story Points est venu la vélocité comme un moyen de suivre le nombre de Story Points qu’une équipe peut livrer. Oui, livrer : La seule façon d’obtenir des Story Points est lorsqu’une histoire est terminée, le logiciel livré, et donc la fonctionnalité décrite dans l’histoire est disponible pour les utilisateurs.

Au fil des ans, j’ai vu de nombreuses discussions sur l’attribution de Story Points lorsque les histoires sont partiellement terminées (aucune valeur livrée, alors ne le faites pas), l’obtention de Story Points pour résoudre les bogues (encore une fois aucune valeur car le bug n’aurait pas dû être là en premier lieu) et la normalisation des Story Points à travers plusieurs équipes (ce qui conduit généralement à comparer les équipes, ne le faites pas). Il semble y avoir beaucoup de choses qui vont mal et les gens ont du mal à comprendre. Ce qui est dommage.

Le véritable avantage que j’ai vu dans les Story Points est les discussions qu’ils déclenchent. Si tout le monde arrive avec le même nombre ou si les estimations sont proches les unes des autres, ma suggestion est de convenir rapidement d’un nombre et de passer à autre chose. Ne passez pas de temps à savoir si cela devrait être un 3 ou un 5, cela n’en vaut pas la peine. Lorsqu’il y a un écart plus important dans les estimations, discutez pour augmenter une compréhension partagée de l’histoire et non pour estimer. Une fois que les gens s’alignent sur le contenu de l’histoire, il est facile de l’estimer. Si c’est difficile à estimer, alors il y a un manque de bonne compréhension. Travaillez là-dessus.

En 2019, Ron a publié l’article Story Points Revisited où il a exploré comment les Story Points sont mal utilisés. J’aime cette déclaration sur la pression sur les équipes :

La meilleure façon de créer de la valeur n’est pas plus, plus, plus, c’est de faire de petites choses précieuses fréquemment. Si, au lieu d’estimer les histoires, nous les rendons « suffisamment petites », nous pouvons arriver à un flux de valeur fluide, livrant tout le temps.

Ron Jeffries dans Story Points Revisited

Compte tenu du temps perdu avec l’estimation, je suis devenu un fan de l’approche d’estimation que Pawel Brodzinski a mise au point (1 / TFB / NFC) et de #NoEstimates. Ce n’est pas une question d’estimation. Il s’agit de découper les choses jusqu’à la plus petite pièce qui a encore de la valeur et de fournir un flux continu de valeur qui compte.

J’ai fait une séance de questions-réponses avec Ron Jeffries sur la nature du développement logiciel pour InfoQ, où je l’ai interrogé sur le rôle du management lorsqu’une organisation adopte l’agilité :

Tout d’abord, les organisations ne doivent pas « adopter » l’agilité. Elles devraient créer des équipes vraiment agiles et apprendre d’elles. Deuxièmement, les méthodes agiles visent à donner aux équipes les moyens de travailler directement avec les gens du métier et les besoins de l’entreprise. Cela implique que bon nombre des choses faites généralement par les cadres intermédiaires sont prises en charge par l’équipe et son product champion. Les managers doivent l’accepter.

Ron Jeffries sur The Nature of Software Development

J’aime la façon dont il met l’accent sur l’autonomisation des équipes, la collaboration avec l’entreprise et ce que le produit doit faire. Il ne s’agit pas de devenir agile, cela revient aux valeurs du manifeste et à la façon de les mettre en pratique.

Jon Kern

J’ai rencontré Jon Kern lors de l’Agile Greece Summit 2018, une conférence avec de nombreux auteurs du Manifeste Agile. C’était formidable de parler avec lui et d’entendre ses expériences dans sa conférence A Day in the Life of a Jon Kern Agile Project.

Après la conférence, j’ai travaillé avec lui sur l’article d’InfoQ Agile in the Context of a Holistic Approach. C’est un excellent article avec de nombreuses idées pratiques sur l’agilité et l’utilisation de pratiques agiles.

Dans l’article, Jon a partagé son point de vue sur l’état du Manifeste Agile :

Parfois, on me demande si je reviendrais en arrière et changerais le manifeste si je le pouvais.

« Non » est ma réponse.

Au contraire, nous devons nous efforcer de (ré)éduquer les gens sur ce que nous avions l’intention de faire lorsque nous avons écrit le Manifeste.

Jon Kern dans Agile dans Agile in the Context of a Holistic Approach

Je suis d’accord avec lui. Les valeurs du manifeste agile sont grandes et elles n’ont pas vieilli avec le temps. Débattre si elles doivent être mis à jour ou remplacer quelques mots ne nous aide pas beaucoup. Comprendre de quoi il s’agit et le mettre en pratique est ce qui compte.

Brian Marick

Après avoir fait une interview pour Leanpub Frontmatter Ben Linders: Auteur de What Drives Quality , j’ai été présenté à Brian Marick. Après avoir publié ses livres via Leanpub (tout comme moi), il a également fait une interview avec Leanpub Frontmatter: Brian Marick, auteur de An Outsider’s Guide to Statically Typed Functional Programming où le cofondateur de Leanpub, Len Epp, lui a posé des questions sur les arguments de vente de Agile et du manifeste agile:

Ce que nous avons promis, c’est : « Nous vous donnerons des logiciels fonctionnels tous les mois, toutes les deux semaines, que vous pourrez réellement utiliser et montrer. Vous comprenez. Nous vous promettons que si vous décidez à mi-chemin du projet que nous avons en réalisé toutes les fonctionnalités que vous vouliez, vous pouvez simplement vous arrêter, livrer ce que vous avez à ce moment-là et licencier tout le monde, et ne pas aller plus loin dans le projet » – ce qui est très attrayant pour les managers.

Ce que nous n’avons pas promis, c’est : « Nous ne prétendons plus vous dire exactement quel type d’éditeur de texte vous aurez à la fin de l’année. Mais nous vous promettons que vous aurez le meilleur éditeur de texte, l’éditeur de texte le plus complet, avec les fonctionnalités les plus importantes que vous pouvez avoir avec cette équipe à la fin de cette année. Nous ne pouvons tout simplement pas vous dire maintenant ce que ce sera. Vous pourrez le faire, vous apprendrez à le savoir, parce que nous allons vous laisser nous dire quelles sont les choses les plus importantes, et nous les ferons tout de suite, plutôt que de passer un an à en écrire les fondations avant que vous puissiez voir quoi que ce soit. C’est à la fois un bon moyen de développer des choses pour la plupart des types de choses, la plupart des types de logiciels, et c’est aussi un argument de vente très puissant.

Brian Marick dans l’interview de Leanpub Frontmatter

Tenir cette promesse était et a été un élément clé dans de nombreuses entreprises qui envisageaient d’adopter l’agilité. Agile consiste à fournir de la valeur là où vous devez investir du temps pour découvrir quelle devrait être cette valeur. Il ne s’agit pas de spécifications ou d’exigences de projet. Ce qui compte, c’est une discussion intensive et transparente continue qui aide à déterminer ce dont les utilisateurs ont le plus besoin maintenant et à le faire. Si une organisation n’est pas prête à en discuter, alors ne faites pas d’agilité.

En 2018, j’ai été invité à la conférence eXperience Agile 2018 où j’ai parlé avec Brian Marick. Après la conférence, Brian a commencé à travailler sur un article sur la cognition incarnée. Malheureusement, nous ne l’avons jamais terminé et publié. Mais nous avons eu d’excellentes discussions.

Agile a du sens

Les idées mentionnées ci-dessus ne sont que quelques-unes des choses auxquelles je pouvais penser en écrivant ce billet. Cela résume à quel point l’agilité a eu du sens et a encore du sens pour moi. Comme vous pouvez le constater, les auteurs du manifeste agile ont été une source d’inspiration tout au long de ma carrière et à bien des égards.

Une série de vidéos introductives gratuites sur Scrum !

Le 13 avril 202230 mars 2022 par mopertodans agile, formations et certificationsLaisser un commentaire

Voici une série de vidéos courtes qui peuvent vous être utiles pour répondre aux questions de certaines de vos parties prenantes sur Scrum et Agile.

Dans la première de ces 18 brèves vidéos, une formateur professionnel, Ryan Brook, décompose l’approche pas à pas et présente cette série de vidéos.

La playlist sur Scrum.org s’appelle Scrum Tapas

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Avec Scrum, quand un sprint est-il terminé ?

Le 7 avril 202227 mars 2022 par mopertodans agileLaisser un commentaire

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé.

In Scrum, when is a sprint over?

https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/ par Leon Tranter

Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).

Qu’est-ce qu’un sprint ?

Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.

Il n’y a pas d’activité en dehors du sprint.

Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.

Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.

**Pourquoi est-il timeboxé ?**

La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.

Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !

Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !

La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).

Quand un sprint est-il terminé ?

La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).

Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).

Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).

Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.

L’important est que la timebox régulière soit respectée.

De quelles autres façons un sprint peut-il se terminer ?

Il n’y a que deux autres façons dont un sprint peut se terminer.

La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.

Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.

L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.

7 péchés des revues de projet que vous pouvez éviter !

Le 16 mars 202216 mars 2022 par mopertodans agile, pmo et portofolioLaisser un commentaire

Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.

Seven Sins of Reviews

https://kbondale.wordpress.com/2021/04/18/seven-sins-of-reviews/ par Kiron Bondale

Votre équipe suit un framework Agile spécifique ou a adopté une approche mixte dans ses pratiques, un principe d’Agile est l’utilisation de courtes boucles de rétroaction pour soutenir l’inspection et l’adaptation.

Que votre équipe fixe une cadence régulière pour les évaluations externes des livrables ou qu’elles soient effectuées dans la foulée, il est important d’obtenir des retours exploitables. Mais mener une revue n’est pas seulement une question de rassembler les gens.

Bien qu’il y ait probablement plus que ces façons de gâcher les revues, en voici sept dont j’ai été témoin.

#1 – Le seul participant est un Product Owner (ou un rôle similaire représentant la voix du client).

Bien que nous nous attendions à ce que les Product Owners soient bien informés, leurs retours sont à un pas de distance de celui des véritables parties prenantes externes. Le Product Owner peut juger si le produit répond aux besoins, mais l’équipe perd l’avantage de poser des questions comme « Quelles nouvelles idées cette fonctionnalité vous donne-t-elle pour le produit ? » ou « Comment pourrions-nous faire en sorte que cette fonctionnalité ajoute plus de valeur pour vous ? ». De plus, les retours du Product Owner devraient (idéalement) être reçus par l’équipe quotidiennement plutôt que d’organiser un événement spécial uniquement à cette fin.

Visitez le site de notre partenaire Virage Group

#2 – Trop en mettre dans une seule revue et ne pas laisser suffisamment de temps aux parties prenantes pour digérer ce qu’elles ont vu.

Au fur et à mesure que les équipes s’améliorent dans la livraison, elles peuvent être en mesure d’effectuer plus de travail sur un même laps de temps.

Dans ce cas, la fréquence des examens externes devrait être rapprochée afin que le contenu examiné soit moins important et que le contenu couvert soit organisé par ordre de priorité.

#3 – Organiser une démonstration plutôt qu’un échange bidirectionnel.

Si le seul but d’une revue est de montrer ce que l’équipe a accompli, cela pourrait être enregistré et envoyé aux parties prenantes pour qu’elles les regardent à leur guise.

La vraie valeur d’un examen réside dans la richesse des discussions entre les membres de l’équipe et les parties prenantes et entre les différentes parties prenantes en fonction de ce qu’elles voient.

L’utilisation de questions puissantes et ouvertes est un moyen de s’assurer que le partage des connaissances ne se fait pas dans une seule direction.

#4 – Avoir les mauvaises personnes dans la revue.

Il est presque aussi mauvais d’avoir les mauvais intervenants externes dans la salle que de n’en avoir aucun. Si des personas sont utilisés pour faciliter la découverte des exigences, il devrait y avoir au moins un représentant pour chaque persona si le contenu de ce qui est examiné les affecte.

Et parce qu’une revue est une séance de travail et pas seulement un forum de partage d’informations, nous ne voulons pas non plus avoir trop de monde dans la salle.

#5 – Prendre des engagements pendant la revue.

ne prenez pas d’engagements trop rapidement

Il peut être tentant pour un membre de l’équipe ou le Product Owner d’essayer de s’attirer les faveurs d’une partie prenante externe puissante en s’engageant à un changement spécifique du livrable ou sur une date de livraison, mais ce n’est pas le bon forum pour cela.

Le contenu et les dates souhaités peuvent être notés, mais le Product Owner et l’équipe doivent prendre le temps de comprendre les impacts de ces changements.

#6 – Critique ouverte du travail de l’équipe.

Il est naturel qu’une partie prenante externe soit frustrée si ses attentes n’ont pas été satisfaites pour le contenu examiné. Ces critiques sont essentielles pour aider l’équipe à s’améliorer au fil du temps.

Mais si cette critique est fournie de manière abusive, le moral et la productivité de l’équipe en prendront un coup.

#7 – Ne pas prendre suffisamment de temps pour analyser ce qui a été appris lors d’une revue.

Si nous mobilisons un temps précieux pour les parties prenantes, il nous incombe de bien utiliser leurs retours. Il peut être pratique d’organiser une rétrospective ou un artefact similaire immédiatement après une revue, mais cela peut ne pas laisser le temps nécessaire à l’équipe et au Product Owner pour digérer correctement les retours qu’ils ont reçus.

Des critiques bien managées sont un ingrédient clé de la construction du bon livrable pour nos clients, donc éviter ces sept péchés contribuera grandement à tirer une valeur réelle de ces rencontres critiques.

Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

Le 22 février 202222 février 2022 par mopertodans agile, best practices, experience sharingLaisser un commentaire

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :

Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

« La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »
Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?

Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.

En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.

CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Ayez une attitude constructive et une approche communicative

Une grande partie des problèmes se résument à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».

Une discussion en face à face est souvent plus efficace.

En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.

Coachez les autres membres de l’équipe sur les aspects pertinents du test .

En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.

L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.

Collaborez avec les développeurs, le Product Owner et les stakeholders pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.

Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.

Les testeurs doivent être impliqués dans les sessions de Pré-planification et de user stories grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :

Définition des user stories et des critères d’acceptation
Participation aux analyses de risques et de qualité de projet
Création de tests d’acceptation pour les user stories

Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .

Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.

Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.

Reportez les défauts et travaillez avec l’équipe pour les résoudre.

Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise temps et budget.

L’art perdu de demander de l’aide.

Le 16 février 202216 février 2022 par mopertodans agile, experience sharingLaisser un commentaire

Les gens attendent bien trop longtemps avant de demander de l’aide !

Lost Art of Asking for Help

https://rgalen.com/agile-training-news/2021/2/16/lost-art-of-asking-for-help par Robert Galen

J’ai été impliqué dans Agile depuis environ 20 ans et j’ai remarqué un anti-modèle répétitif qui semble ne jamais changer.

Les gens attendent trop longtemps pour demander de l’aide !

Je l’ai remarqué dans mon activité de coach. D’habitude, au moment où je suis appelé dans une organisation qui essaye de mettre en œuvre Agile, la situation est (j’ose le dire) que les wagons sont sortis des rails. Bien sûr, une partie de moi pense que c’est une chose bonne ou normale. Mais c’est seulement la partie de génération de revenus qui parle.

La partie principale de moi qui est coach agile regrette toujours qu’ils ne se soient pas venus plus tôt. Ceci aurait évité tant d’aggravation et de frustration, de gaspillage de temps et d’efforts et de coûts en bout de ligne.

Mais ce n’est pas seulement en tant que coach. Ceci s’applique aussi à mon expérience de leader.

Si un projet avait déraillé ou qu’un engagement était manqué, je le découvrais le plus souvent à la dernière minute. Bien plus tard que quand j’aurais encore pu faire quelque chose ou aider. Je travaille toujours dur comme leader pour créer de la sécurité pour l’annonce de mauvaises nouvelles, être accessible et être reconnaissant de cela. Très dur. Mais cela me choquait toujours de constater combien de fois les gens attendaient trop longtemps pour partager quelque chose avec moi. Je me demande souvent, que devrais-je faire pour créer une culture où le partage des problèmes serait récompensé, serait la norme et ne serait pas craint ?

Cela s’applique même à mon coaching et à mes collègues agiles dans les diverses communautés agiles dont je fais partie. Je m’assimile souvent “à un coach de coaches” et c’est ce que je suis. Mais de nouveau, presque 100 % des gens attendent trop longtemps pour m’appeler à l’aide.

Je ne leur dis normalement rien directement parce qu’il est trop tard pour cela. Mais je pense souvent par devers moi que les résultats pourraient être significativement différents s’ils étaient seulement venus me voir plus tôt. Mon coaching, ou celui de qui que ce soit, pourrait avoir évité tant de frustrations et d’aggravation en évitant des erreurs coûteuses.

Vous m’avez compris. Avant que nous n’allions plus loin, je souhaiterais partager avec vous l’une de mes métaphores préférées autour de ce sujet …

Le Statut Pastèque

Je ne peux pas me rappeler la première fois quand je l’ai entendu mais j’aime la notion de « statut pastèque ».

C’est un projet qui est vert à l’extérieur (annoncé comme étant sur les rails, excellent) et rouge à l’intérieur (déraillé, en retard sur les délais, dépassant le budget).

Une fois que j’ai entendu cette métaphore, elle a résonné sur CHAQUE projet que j’avais mené comme leader. 90 % du temps, les membres de mon organisation annonçaient un statut pastèque.

Et, vous découvrez que c’est rouge SEULEMENT à la toute dernière minute. Au point que, en tant que leader, vous n’avez que très peu d’options pour aider ou faire quoi que ce soit.

QRP est partenaire de DantotsuPM, visitez leur site et leur blog

Les Raisons Possibles

J’ai alors mis mon chapeau remue-méninges / brainstorming et essayé de penser à toutes les raisons pour lesquelles on pourrait ne pas vouloir demander de l’aide.

Optimisme – Espoir
Crainte …
- D’échec, de ramifications, de sembler mauvais, de perdre son travail, ou d’être rétrogradé
Ignorance
Sentiment de propriété – c’est mon travail
Apathie
Réparer, c’est mon défi …
Manquer de …
- Compétences, connaissances, expériences, sécurité, ou courage
Orgueil ou Obstination
Budgets serrés
Timidité
Ne pas vouloir « déranger » qui que ce soit
Responsabilité ou Devoir
Recherche d’un nouveau travail
Sabotage

Voici certaines raisons qui me sont venues à l’esprit. Mais je suis sûr qu’il y a d’autres et j’espère que vous en ajouterez dans les commentaires.

Certaines d’entre elles sont liées à nos opinions ou à des bagages historiques et d’autres plus dépendantes de notre culture actuelle. Quoi qu’il en soit, j’ai voulu illustrer un large spectre de raisons et que je me rends compte que ce sujet est complexe et nuancé.

Je veux rediriger cette discussion sur un jeu de 5 leçons durement apprises que j’ai expérimentées dans ce domaine. J’espère que vous pouvez les prendre avec vous et qu’elles pourront vous servir d’encouragement pour à aller chercher plus d’aide.

#1 – Typiquement, le temps n’améliore pas les choses …

Laisser-faire est rarement une bonne approche. (relisez ce billet)

Une de mes leçons apprises à travers toute ma carrière est que quand vous faites face à un challenge :

Challenge de client;
Challenge de personnel;
Challenge de projet;
Challenge personnel;
Challenge de direction;
Presque n’importe quel Challenge …

Attendre ne semble pas aider. Cela rend typiquement les choses plus mauvaises. Bien pires !

Leçon : N’attendez pas trop longtemps pour demander de l’aide. Faites-le maintenant!

#2 – Comment vous commencez est critique

Rappelez-vous pourquoi vous avez commencé.

Le début de toute entreprise est critique. C’est là que votre stratégie est définie. C’est là que le pourquoi et les objectifs sont établis. S’il y a un meilleur moment pour demander l’aide, c’est au début d’un effort. Et plus l’effort est important (dans sa portée, sa valeur, son impact, etc.), plus critique il est de demander de l’aide au commencement.

Leçon : quoi que ce soit qui mérite d’être fait, particulièrement dans des initiatives critiques, il vaut mieux bien démarrer. Commencez en ayant la finalité à l’esprit.

#3 – Trop d’espoir et d’orgueil …

L’espoir n’est pas une stratégie et il y a trop d’orgueil dans le monde. Ces deux-là empêchent de demander de l’aide. Vous devez regarder au-delà de votre propre personne quel sera l’impact de ce challenge sur les autres. Autrement dit, rendez-vous compte que ce n’est pas de vous qu’il s’agit. Il en va de votre équipe ou de votre organisation toute entière.

J’ai constaté que de me rappeler à moi-même la portée et l’impact d’un défi (au-delà de ma personne) pouvait servir à me motiver à demander/trouver de l’aide. Montrez plus de vulnérabilité.

Leçon : Regardez au-delà de vous-même quel sera l’impact (si cet obstacle est incorrectement traité) sur votre univers au sens le plus large. De cette perspective, demandez-vous ensuite si vous avez besoin d’aide …

#4 – Plus haut vous êtes, plus dur il y parait …

J’ai aussi remarqué que plus votre position dans l’organisation est élevée (promotion, niveau, titres etc.), plus il semble difficile de devoir demander l’aide.

Et pas seulement de consultants/coachs externes, mais pour que quelqu’un à l’intérieur de l’organisation puisse aussi vous aider.

Leçon : Peu importe notre titre, nous avons tous besoin de l’aide, alors demande-la. C’est en réalité un signe de force, pas de faiblesse et cela fait grandir votre organisation …

#5 – Le budget semble toujours être un challenge …

Nous ne pouvons pas nous le permettre. Je n’ai pas le budget pour cela. Si je leur demande de l’aide, ils me la feront payer. Beaucoup de leaders manquent du courage de défier le statu quo quand on en vient aux contraintes. Je soutiendrais qu’il y a d’habitude davantage de capacité et de flexibilité dans les organisations pour dépenser de l’argent pour des initiatives critiques ou résoudre des problèmes critiques. Cela demande seulement à certains de lever la main et de demander, de demander de l’aide.

Leçon : Vous ne pouvez pas vous permettre de ne pas payer pour l’aide dont vous avez besoin. Demandez-vous quel sera le coût de l’échec ? De ce point de vue, il est souvent meilleur marché de demander l’aide…

En conclusion

Dans le doute… demandez de l’aide!

Je veux demander à chaque lectrice et lecteur de ce billet de l’aide.

S’il vous plaît, réfléchissez à cet article et comment il résonne avec votre voyage personnel et professionnel. Puis, partagez s’il vous plaît des commentaires pour complémenter ce billet.

J’aimerais entendre vos histoires, vos perspectives et vos diverses réactions.

Restez agile mes amis,

Bob.

Post-scriptum

Il y a un point de vue intéressant dans cette vidéo de Richard Sheridan où il explore le fait de dire la vérité dans ses projets. Je pense qu’il est parfaitement en ligne avec le thème de ce billet…

Amplifiez les succès et les réussites de vos projets Agiles

Le 15 février 20226 février 2022 par mopertodans agileLaisser un commentaire

Les sociétés n’augmentent pas le succès d’Agile ou de Scrum, elles en amplifient le succès.

Scaling Success

https://agile-scrum.com/2021/02/05/scaling-success/ par Zuzi Sochova

Dans notre voyage vers Agile, nous nous demandons souvent par où commencer, quels pratiques, outils et processus devrions-nous nous utiliser ?

Ce que j’ai appris pendant mon propre voyage est que nous n’avons pas besoin d’une « autre » méthode. Aucune de celles-ci n’est une solution miraculeuse de toute façon. Elles sont toutes formidables pour entamer comment changer la façon dont vous travaillez et les mentalités.

Mais la partie la plus importante de votre voyage est le succès.

Pouvez-vous partager une histoire de réussite ?
Pouvez-vous utiliser vos propres mots pour décrire comment votre propre environnement a changé et montrer l’impact de ces nouvelles manières différentes de travailler ?

Si oui, les gens vont s’y mettre et essayer d’atteindre un impact similaire.

Les transformations agiles les plus réussies que j’ai vues ont commencé exactement comme cela. Avec une petite équipe expérimentant de nouvelles pratiques et partageant l’impact observé avec d’autres. Selon le point de départ, ces équipes partagent des histoires de réussite différentes et diverses, comme. 5 fois moins de bogues reportés par des clients, 3 fois plus de valeur livrée sur une période donnée (ce n’est pas la même chose que plus de fonctionnalité, mais souvent le contraire), un délai de mise sur le marché significativement plus rapide, une motivation plus élevée et un meilleur niveau d’engagement, plus d’innovations qui aboutissent à une satisfaction client meilleure… l’impact varie en fonction de l’environnement.

Pour nous, il y a quelques années c’était plus de flexibilité, apprendre plus rapidement et une meilleure satisfaction client.

Partager sur les succès n’a rien de nouveau dans le management du changement. C’est l’une 8 étapes dans Conduire le changement: Feuille de route en 8 étapes de John Kotter que pour quelque raison on ne connait toujours pas assez largement dans la communauté agile, donc j’ai pensé à vous les rappeler ici .

#1 – Créez le sens de l’urgence

À moins que vous ne sachiez pourquoi vous changez la façon dont vous travaillez (pour être plus agiles, Scrum ou Kanban), ne le faites pas. Ni Agile, ni Scrum, ni Kanban ne sont votre but. Ce sont juste des ‘béquilles’ vous aidant dans votre voyage vers la réussite. Vous devez avoir un objectif plus élevé défini qui sera plus fort que les objectifs individuels et unifiera donc les personnes.

#2 – Construisez une coalition de direction

Vous ne pouvez jamais changer l’organisation si vous êtes seul. Vous devez trouver des partisans (des enthousiastes agiles dans votre cas) qui créeront une équipe qui vous aidera à changer le système. Ainsi, au minimum deux personnes complémentaires qui sont de vrais aficionados agiles, car trois personnes constituent l’équipe la plus petite. Les autres vous rejoindrons en observant des résultats.

#3 – Formez une vision et des initiatives stratégiques

Parfois avoir d’un but n’est pas suffisant car les gens ne voient pas de manière d’y arriver et le changement dans sa globalité est trop abstrait. C’est un espace où les structures, les méthodes et les pratiques sont utiles.

#4 – Enrôlez une armée de volontaires

Finalement, c’est le moment de le rendre plus grand. Faites-en un mouvement, pas juste un autre projet. Faites-y adhérer un plus grand groupe. Faites-les s’impliquer. De nouveau, si vous sautez certaines des étapes précédentes, cela ne pourra pas grandir.

#5 – Permettez l’action en faisant tomber les barrières

Maintenant, une fois que vous avez l’énergie de votre côté, vous devez l’aider et éliminer les barrières (hiérarchie, silos, positions détaillées, KPIs individuel, …), sinon, tout l’enthousiasme initial va s’évaporer avant que vous ne le compreniez.

#6 – Générez des victoires dans le court terme

Générez du succès rapidement et souvent et rendez-le visible à toutes et tous. Partagez des histoires d’améliorations, célébrez même de petits pas de progrès. Le succès est un moteur puissant pour le changement. Accélérez, multipliez les succès. Sans cela, tout changement mourra.

#7 – Soutenez l’accélération

pousser les gens dans la bonne direction — Continuez tout le temps de pousser.

Vous pouvez la célébrer, mais vous ne pouvez pas arrêter de pousser après la première victoire, ne soyez pas trop satisfait. Il y a toujours une meilleure manière. Trouvez un autre défi, découvrez une meilleure façon de travailler jusqu’à ce que la vision de la nouvelle façon de travailler définie par le but original devienne vraie.

#8 – Institutionnalisez le changement

Finalement en créant des liens entre la nouvelle façon de travailler et le succès vous tenez le levier du changement.

Ces liens sont la glu qui empêche l’environnement de retomber en arrière dans l’ancienne façon de travailler.

Agile est un changement majeur et sans le conduire comme un changement vous aurez beaucoup de mal à réussir.

N’oubliez donc pas de définir à quoi ressemble le succès, célébrez-le et rendez-le meilleur au fil du temps.

Les exigences SMART sont Agiles

Le 7 février 202219 janvier 2022 par mopertodans agile, outils et méthodesLaisser un commentaire

Des approches SMART sont utilisées pour évaluer les exigences dans les projets en cascade, prédictifs. Elles s’appliquent aussi aux projets agiles.

SMART Requirements are Agile

http://www.bonniebiafore.com/smart-requirements-are-agile/ par Bonnie Biafore

Spécifique

Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance. Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.

Mesurable.

La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.

Atteignable

Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.

Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.

Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.

Réaliste

Une approche pratique de comment planifier et implémenter le changement

En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.

Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.

La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.

Temporel – contraint par le Temps

L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.

Un projet pilote n’est pas toujours la meilleure façon de commencer votre voyage Agile

Le 28 janvier 20228 janvier 2022 par mopertodans agile, best practicesLaisser un commentaire

Commencer petit pour mettre en œuvre un grand changement est presque toujours une bonne idée… et le mot « presque » y tient une grande importance.

A pilot project is not always the best way to start your agile journey

https://kbondale.wordpress.com/2021/01/24/a-pilot-project-is-not-always-the-best-way-to-start-your-agile-journey/ par Kiron Bondale

Beaucoup d’entre nous s’accorderaient sur le fait que si vous essayez de mettre en œuvre un grand changement, commencez petit. De même qu’il est plus facile d’avaler une petite pilule qu’une énorme, la capacité d’adopter et de supporter le changement est souvent plus simple quand le changement implique des pas de fourmi.

Cette approche des petits pas/changements progressifs s’applique aussi à Agile.

premiers pas — l’approche dite « à pas de bébé » ou *baby steps*

Par exemple, les expériences d’amélioration qu’une équipe identifie pendant une rétrospective de sprint devraient être petites pour fournir des retours rapides sur si vraiment cela vaut la peine d’aller plus loin.

Mais quand j’ai lu un récent article HBR de Ron Ashkenas et Nadim Matta sur les challenges à reproduire en plus grand un projet pilote réussi, cela m’a rappelé que ce principe de commencer petit pourrait ne pas fonctionner avec des transformations Agiles.

Dans l’article, les auteurs listent quelques défis à appliquer avec succès les leçons d’un projet pilote sur un plus grand contexte

La résistance de la masse des parties prenantes auxquelles on demande de travailler de façon différente alors que la cible des personnes impactées pour le pilote est probablement plus réceptive aux changements proposés. C’est le problème de “franchissement de l’abîme”.
Éviter des éléments bloqueurs dans l’organisation ou des obstacles est relativement simple dans le contexte d’un projet unique, mais cela devient exponentiellement plus difficile quand le périmètre des changements augmente.
La difficulté à essayer de faire appliquer et évoluer des pratiques et des apprentissages du projet pilote aux contextes variés de multiples projets différents.

À cette liste, j’ajouterais encore un défi.

Avoir les meilleurs sur le projet reste bien sûr souhaitable

La première source d’incertitude de livraison dans la plupart des projets basés sur la connaissance est la prévisibilité de disponibilité des bonnes personnes avec les bonnes compétences et au bon moment. Dans un pilote, il est possible d’améliorer la dotation en personnel en notre faveur en allant extraire des gens compétents de leurs rôles normaux pour travailler sur le projet.

Si nous ne remplaçons pas ce personnel avec des ressources temporaires, cela a des impacts sur la capacité de chacune des équipes dont ils faisaient partie et ça n’améliorent probablement pas nos relations avec les leaders de ces équipes.

Mais tous les utilisateurs seront-ils aussi des « cadors » ?

Mais encore pire, quand le projet pilote est fini et que nous commençons à nous congratuler des résultats, la raison principale n’est pas parce que nous étions Agiles, mais parce que nous avons permis à des gens compétents de se concentrer sur un travail précis du projet plutôt que les garder dans leur niveau habituel de multitâches

Quand nous essayons ensuite d’étendre notre approche sur de multiples projets, les résultats sont moins prometteurs parce que nous n’avons pas adressé combien ce travail habituel simultané sur de multiples tâches consomme de temps et de ressources.

Cela ne devrait pas vous décourager de lancer une approche projet pilote dans votre transformation Agile

Cependant, avant de faire la promotion des leçons de ce projet pilote, abordez d’abord les questions fondamentales de la gestion du travail si vous voulez réaliser des bénéfices durables.

Un référentiel sur l’hybridation des modes projet est en marche au PMI France

Le 14 janvier 202228 décembre 2021 par mopertodans agile, formations et certificationsLaisser un commentaire

Des nouvelles du Lab Hybrid, projet mené par Stéphane Derouin et supporté par le PMI France et en particulier son Président Ricardo Naciff .

Tout d’abord, un énorme bravo aux 29 bénévoles qui travaillent à la réalisation du guide des bonnes pratiques hybrides.

La phase idéation des trois thèmes : Gouvernance, cadre méthodologique, dimension humaine, et leurs sous thèmes est terminée.

La phase construction et rédaction du guide des bonnes pratiques démarre en janvier 2022 pour se terminer en juin 2022.

Stéphane Derouin constitue dès maintenant deux équipes pour la rédaction de ce guide pratique et opérationnel en charge de :

La rédaction du document et de sa structure de narration.
La collecte :

- de retours d’expériences,
- de bibliographie,
- de témoignages,
- de documents,
- ou de contenus théoriques en rapport avec l’hybridation.

N’hésitez-pas à contacter Stéphane si vous souhaitez vous aussi contribuer à ce travail. Merci encore à toutes et à tous !

PMI Disciplined Agile de Poche par les volontaires du PMI France !

Le 6 janvier 202215 décembre 2021 par mopertodans agile, outils et méthodesLaisser un commentaire

La team PMI Disciplined Agile de Poche, composée des bénévoles Claudine Blanquier, Laurent Thomas, Frédéric Martin et Selim Khaldi, facilite la découverte de Disciplined Agile avec des mémentos de poche résumant les fondamentaux de Disciplined Agile, EN FRANCAIS !

Le PMI, à travers la septième édition du PMBoK, a su prendre en compte l‘évolution de l’environnement de la conduite de projet : les approches adaptatives, dont font partie les démarches Agiles, sont identifiées et décrites dans le cadre général porté par des principes de conduite de projet.

De manière pratique, l’acquisition par le PMI en 2019 de la boîte à outils Disciplined Agile (DA), traduit tout l’intérêt qui est porté à ces approches.

À partir de ce constat, une équipe pluridisciplinaire de bénévoles du « Disciplined Agile Special Interest Group » du Chapitre PMI-France a décidé de faciliter la découverte de Disciplined Agile en produisant des mémentos de poche résumant les fondamentaux de Disciplined Agile, en français !

Un superbe travail de synthèse de l’essence de cette approche et une traduction compréhensible par tous les francophones.

3 mémentos de synthèse: https://www.pmi.org/disciplined-agile/posters

PMI DA poche – boîte à outils, panorama de ce que DA peut vous apporter
PMI DA poche – Choose your WoW, comment choisir votre manière de travailler en équipe ou avec plusieurs équipes.
PMI DA poche – cycle de vie, les différentes modélisations des cycles de vie projet ou produit en fonction de votre contexte d’activités.

Ce travail est mis gracieusement à votre disposition sur le site PMI France

Et pour aller plus loin dans la découverte de Disciplined Agile et le partage d’expérience adhérez à la communauté LinkedIn francophone “Disciplined Agile, échangeons et partageons ”.

« La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile » par Fidaa Berrjeb.

Le 4 janvier 20228 janvier 2022 par mopertodans agile, outils et méthodes1 commentaire

Dans ce billet, Fidaa explique les 4 valeurs du manifeste agile ainsi que chaque valeur du manifeste de test.

Le manifeste agile

1. Les personnes et les interactions plus que les processus et les outils

La méthode agile privilégie l’individu et lui donne le plus d’importance. Il est facile de comprendre les personnes plutôt que les processus ou les outils, car ce sont les personnes qui répondent aux besoins de l’entreprise et pilotent le processus de développement.

« Quand les entreprises prennent de l’ampleur, elles cherchent à reproduire leur succès initial. Elles confondent bien vite le processus et le contenu ». Steve jobs dans une interview en 1995.

2. Des logiciels opérationnels plus qu’une documentation exhaustive

L’approche Agile se concentre sur la production de valeur. La documentation reste nécessaire à la continuité et à la maintenabilité du projet, mais n’apparaît pas comme une priorité. Auparavant, l’équipe passait des heures sur la rédaction de documents et cela empêchait l’avancement des livrables.

3. La collaboration avec les clients plus que la négociation contractuelle

Le message ici n’est pas que les contrats doivent être jetés par la fenêtre mais que vous devriez collaborer plus souvent avec vos clients. L’approche Agile demande la collaboration continue avec le client et son implication dans toutes les phases du projet pour collecter ses retours et donc construire des produits de valeur.

4. L’adaptation au changement plus que le suivi d’un plan

Les méthodes traditionnelles considéraient le changement comme une dépense, il fallait donc l’éviter. L’intention était de développer des plans détaillés et élaborés. L’agilité nous invite à mettre en place un fonctionnement flexible capable d’absorber les changements et de redéfinir les objectifs et les priorités. Avec ce mode de fonctionnement, tout changement apporte une valeur ajoutée au lieu d’un obstacle à éviter.

Le manifeste du test

1. Tester au fil d’eau plus que tester à la fin

Traditionnellement, les gens considèrent les tests comme une phase qui se produit à la fin du développement. En revanche, en Agile, les tests sont une activité qui doit se produire parallèlement au développement .

2. Éviter les bugs plus que trouver les bugs

Il serait beaucoup plus productif de clarifier les spécifications avant de commencer à écrire une seule ligne de code, et de s’assurer que tout le monde, du client au développeur et au testeur, a exactement la même compréhension de la façon dont quelque chose doit fonctionner.

3. Tester la bonne compréhension plus que vérifier la fonctionnalité

En Agile, les testeurs doivent devenir des ambassadeurs du client; Ils doivent comprendre en profondeur qui sont leurs utilisateurs et ce qu’ils essaient de réaliser avec le produit. Les testeurs doivent être les représentants de ce client dans chaque décision de conception, en veillant à ce que la fonctionnalité réponde aux besoins réels des clients, pas seulement aux spécifications.

4. Construire le système plus que casser le système

Bien qu’il existe une croyance commune que les testeurs sont exclusivement engagés dans la destruction, ce n’est qu’à moitié vrai. Il ne faut pas oublier l’objectif principal de créer un produit de valeur et qui fonctionne bien. C’est pourquoi la reproduction des actions réelles d’un utilisateur est de la plus haute priorité.

5. La responsabilité de l’équipe sur la qualité plus que la responsabilité du testeur

Les testeurs ne peuvent pas améliorer la qualité, leur rôle est de déterminer le niveau de qualité et d’en informer les parties prenantes. Vous ne pouvez améliorer la qualité que par les efforts conjoints de toute l’équipe.

Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

Après ce premier billet qui, nous l’espérons, vous aura intéressés, Fidaa va essayer de s’orienter sur l’aspect Quality Assurance (QA) dans ses prochains billets car les sujets sont nombreux qui couvrent Agilité et QA.

Toutes ces choses

Le 30 décembre 202121 décembre 2021 par mopertodans agileLaisser un commentaire

All the stuff

https://seths.blog/2021/12/all-the-stuff/ by Seth Godin

Les marchés vous persuadent souvent que vous n’en avez pas assez.

Vos communautés vous rappellent que si.

Il en est très souvent de même pour les fonctionnalités demandées par les parties prenantes dans vos projets !

A force d’empiler les fonctionnalités, on risque fort l’indigestion !

Jamais assez, ne rien perdre par rapport au produit précédent, bénéficier de toutes les fonctionnalités de tous les concurrents…

N’est-ce pas la beauté, la force de l’approche Agile que de se recentrer sur la valeur business de chaque fonctionnalité demandée pour les prioriser ?

Puis n’en réaliser qu’un relativement faible nombre des plus bénéfiques avec une équipe et un temps limité. Observer et apprendre du résultat. Puis, répéter l’exercice de priorisation jusqu’à ce que la valeur de la prochaine itération soit plus faible que celle que l’on pourrait tirer d’une initiative et/ou projet concurrents.

En bref, stop au gâchis !

Dans les transformations agiles, pensez de haut en bas et de bas en haut à la fois.

Le 15 décembre 202115 décembre 2021 par mopertodans agileLaisser un commentaire

Quel est le meilleur endroit pour commencer une transformation agile dans une société ?

Think top-down and bottom-up for agile transformations

https://kbondale.wordpress.com/2020/10/18/think-top-down-and-bottom-up-for-agile-transformations/ par Kiron Bondale

Une question que l’on me pose régulièrement pendant mes formations est : « Quel est le meilleur endroit pour commencer une transformation agile dans une société ? ».

Si j’avais le choix, je préférerais utiliser la réponse échappatoire (mais correcte) “ça dépend”, mais sinon je réponds d’habitude que vous voudriez mener les deux approches simultanément, de haut en bas et de bas en haut.

Une approche pour des changements organisationnels majeurs est fréquemment de commencer par le haut avec la direction exécutive, créant une coalition d’engagement et de support vers une vision partagée de l’avenir.

Ceci est critique dans les transformations agiles pour certaines raisons

Les équipes de développement ne travaillent pas de manière isolée et gagner l’adhésion pour changer comment les choses sont faites sera nécessaire de la part de tous les secteurs de support dont les ressources humaines, les finances et les achats.
Il y aura le besoin de financer des investissements comme la formation, le coaching, l’outillage et potentiellement même la dotation en personnel sur de nouvelles positions.
Sans changement dans les pratiques de management de portefeuilles de projets existantes et les métriques d’exécution (par exemple passer d’un focus sur maximiser l’utilisation à maximiser la valeur), il sera difficile d’obtenir les pleins bénéfices de la transformation.
Pour changer des comportements établis de cadres intermédiaires vers une mentalité agile, l’équipe de direction a besoin de modéliser d’abord les comportements cibles désirables. Les managers vont devoir être formés pour y parvenir et ils doivent aussi consentir à se tenir mutuellement responsables de cette nouvelle façon de travailler.
Il doit y avoir une vision fédératrice pour la transformation ainsi qu’un plan sur la façon d’y arriver. L’équipe de direction doit être entièrement engagée dans la création de ces livrables clefs.

Mais il y aura aussi besoin d’avoir l’engagement au niveau de l’équipe de développement. Si les membres individuels de l’équipe sont à l’aise avec comment les choses fonctionnent mais n’ont aucun sens d’urgence sur le besoin du changement, leur appui sera superficiel.

Leur pleine adhésion est nécessaire

Développez les détails des nouvelles façons de travailler et revoyez et adaptez celles-ci au fil du temps.
Soyez confortable sur imaginer et conduire des expériences avec les échecs occasionnels de celles-ci.
N’hésitez pas à prendre de nouveaux rôles et responsabilités.
Soyez ouvert et fournissez aux parties prenantes le plus fort niveau de transparence sur leur travail et le workflow qu’elles ont utilisé jusque-là.
Collaborez avec les parties prenantes d’autres domaines fonctionnels avec lesquelles vous pourriez précédemment avoir seulement coopéré.

CSP est partenaire de DantotsuPM, Découvrez tous leurs ateliers

Ces résultats sont nécessaires et un avantage clef de prendre les 2 approches en même temps, de haut en bas et de bas en haut, consiste en ce que cela crée un “effet sandwich” coinçant ceux du middle management qui ne voudraient pas changer comment ils travaillent.

Sans cela, il est peu probable qu’une transformation agile réussira.

Voici comment le principe d’exploration de PRINCE2 Agile peut vous faire économiser de l’argent !

Le 2 décembre 202113 novembre 2021 par mopertodans agile, outils et méthodesLaisser un commentaire

En tant que chef de projet, recevoir un nouveau mandat de projet me rappelle les premières coordonnées dans une course d’orientation.

https://www.axelos.com/news/blogs/august-2020/how-prince2-agile-exploration-can-save-you-money de Maximiliano Clavijo Punschke – Chef de projet, Neem Consulting Ltd

La course d’orientation est un sport d’aventure en plein air dans lequel vous recevez une carte et des coordonnées. L’objectif est de naviguer d’endroit en endroit en passant par un ensemble de points de contrôle et de décider du meilleur itinéraire pour terminer le parcours dans les plus brefs délais. La seule différence est que la course est dans le projet une entreprise multinationale avec une structure organisationnelle complexe. Avant de vous précipiter aux prochains points de passage (ou aux phases de votre projet), il sera important de rencontrer votre équipe pour discuter de ce qu’est la cible finale (le livrable du projet) et si le projet est utile et viable.

Mais comment faire cela dans un environnement Agile PRINCE2^® ?

D’après mon expérience, j’ai trouvé un excellent soutien de la part d’une valeur clé de PRINCE2 Agile : l’exploration. Cela m’a aidé à définir ce qui constitue le produit minimum viable (MVP) de mon projet et à définir les exigences obligatoires dans la description du produit de mon projet. Habituellement, les techniques d’exploration telles que « l’expérience » ou « spike/spiking » sont utilisées soit lorsqu’il existe des incertitudes autour des théories, lorsque l’impact est lié à l’utilisation de nouvelles technologies ou lorsqu’il existe des préoccupations fonctionnelles du point de vue du consommateur. Lorsque vous utilisez des techniques d’exploration au début du processus de projet PRINCE2 Agile (en avant-projet), cela peut être source de grande valeur.

Maintenant, imaginez qu’en plus du mandat du projet, vous receviez également la documentation technique de bout en bout pour intégrer une plate-forme de commerce électronique d’avant-garde pour votre organisation. Faire un Sprint d’une journée (un spike) et créer un livrable temporaire un tel prototype peut offrir les avantages suivants:

Vous réduisez les incertitudes d’un point de vue technique et client.
Vous aidez à identifier tous les domaines qui doivent être examinés pour remplir la description du livrable du projet et son analyse de rentabilité.
Vous identifiez et impliquez les bonnes parties prenantes, qui peuvent ensuite faire partie de l’équipe de projet.
Vous créez des boucles de retours rapides pour accélérer le processus de collecte des exigences.
Vous créez une opportunité de générer des apprentissages qui peuvent soutenir l’analyse de rentabilité.
Vous aidez à résoudre les « inconnus connus » et à révéler des informations sur des « inconnus inconnus ».

Pour rappel : Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.

Dans PRINCE2 Agile, le travail à partir d’un spike peut être managé et contrôlé avec une approche de timeboxing telle que Scrum ou en utilisant un système basé sur les flux (par exemple Kanban). J’ai constaté qu’en raison du spike, j’étais mieux placé pour travailler avec l’équipe de développement sur les estimations du projet. Il est important d’être cohérent avec l’approche de management agile afin de s’assurer que les techniques d’estimation sont bien alignées.

Faire un ou des spikes au cours de la phase d’avant-projet a également fourni des informations sur les risques majeurs (dans mon cas, principalement les menaces) qui auraient un impact sur le projet s’ils se matérialisaient.

Toutes les données recueillies à partir de ce prototype ont contribué à éclairer l’élaboration de l’analyse de rentabilité. L’un des principes les plus pertinents de PRINCE2 Agile est de maintenir une justification business continue.

Le spike au cours de la phase d’avant-projet peut fournir suffisamment de données pour répondre à la question suivante : Le projet en vaut-il la peine et est-il viable ?

Si la réponse est « non », vous saurez alors que le spike vient de vous éviter un mauvais investissement. Si le projet fait partie d’un programme, il est fondamental de remonter ceci dès que possible; cela pourrait déclencher un examen de l’analyse de rentabilité du programme tout entier avec des conséquences majeures sur ses bénéfices et la réussite de la future organisation.

Si la réponse est « oui », utilisez les flux d’informations disponibles pour mettre en évidence les risques majeurs, l’impact associé et la probabilité lorsque vous demandez l’approbation de lancement du projet par la direction du programme.

Le Manager dans les Daily Scrum : Quelles sont les choses à ne pas faire en dehors d’éviter totalement sa présence.

Le 26 novembre 202121 novembre 2021 par mopertodans agile, best practicesLaisser un commentaire

**Un des anti-modèles les plus courants aux Réunions Daily Scrum est la participation active des managers.**

Back To Basics: Managers and Daily Scrum Meetings

https://tcagley.wordpress.com/2020/09/24/back-to-basics-managers-and-daily-scrum-meetings/ par Tom Cagley

Si vous n’allez pas plus loin dans la lecture de ce billet, je recommande aux managers de rester éloignés du Daily Scrum. Même s’il n’est pas interdit aux managers de venir au Daily Scrum ni que ce soit intrinsèquement mauvais en soi il y a toutes sortes de fréquents résultats négatifs.

Voici 4 des pires attitudes

1 – Mettre l’équipe sur le grill

Transformer le Daily Scrum en une réunion de statut où la déviation par rapport plan du leader est mise en évidence et même punie.

Ce comportement rend pour le moins difficile de produire une mentalité agile.

2 – Distribuer du Travail

Les leaders qui utilisent le Daily Scrum pour assigner du travail empêchent les équipes d’apprendre à s’auto-organiser et élimine l’objectif de planning d’équipe de la réunion. J’ai demandé à un manager pourquoi il distribuait le travail dans le Daily Scrum, sa réponse fut « je suis responsable de m’assurer que chacun est occupé ».

Distribuer du travail pendant cette rencontre signifie que le manager doit avoir une compréhension détaillée de toutes les histoires et tâches nécessaires pour faire quelque chose, les entraînant vers un micromanagement du travail. Le Daily Scrum est un événement dans l’équipe projet Agile dont l’objectif va à l’encontre de cette approche.

3 – Le « paraître »

La perception qu’a de vous votre manager (ou la personne renouvelant votre contrat) est importante pour votre carrière. C’est une tendance humaine de base que de vous assurer que vous paraissez bons aux yeux du patron, même parfois aux dépends de vos pairs. Ce comportement n’amène pas à partager les problèmes, demander de l’aide, ni à re-planifier.

4 – Désintérêt

J’ai récemment observé un manager qui venait chaque jour au Daily Scrum et passait tout son temps à faire des choses sur son téléphone. Quand s’adressait à lui, il semblait choqué que quelqu’un lui parle. Après le quatrième jour, j’ai pu coincer la personne pour une discussion. Sa formation Agile indiquait qu’il devait aller au Daily Scrum, mais il ne souhaitait pas être là. Il était passif-agressif. Il n’est plus revenu après cette rencontre et chacun s’est senti plus à l’aise. En tant que manager, si vous allez aller au Daily Scrum (ne le faites pas s’il vous plaît) écoutez et prêtez l’attention.

En règle générale, les managers devraient trouver une raison d’être n’importe où plutôt qu’au Daily Scrum. Comme avec toutes les règles, il y a des exceptions. Par exemple, le scénario de manager-joueur, où un membre de l’équipe est aussi le manager. J’ai entendu des scénarios où la présence d’un manager était utile, mais j’ai entendu ces histoires de managers pas de leurs équipes.

Et si vous rejoigniez le Lab Hybrid du PMI France ?

Le 9 novembre 20212 novembre 2021 par mopertodans agile, formations et certifications, outils et méthodesLaisser un commentaire

Une nouvelle initiative s’est mise en place au sein de la communauté des membres du PMI Chapitre France, le Lab Hybrid.

Allez découvrir les sommets du monde hybride avec Stéphane Derouin

Réunissant environ 25 membres, Stéphane Derouin a lancé cette nouvelle initiative à mi-parcours entre la gestion de projet dite traditionnelle et les concepts Agiles.

L’objectif de ce groupe de travail est de co-écrire un guide des bonnes pratiques hybrides, pragmatique et utilisable par le plus grand nombre .

Vous y retrouverez des aspects liés :

A la gouvernance
Au cadre méthodologique
A la dimension humaine.

Bien évidemment le projet lui-même sera géré en mode hybride avec une livraison du guide prévue pour le 31 mai 2022.

Le Business Owner est Ricardo Naciff, président du PMI France et Stéphane Derouin est le responsable du projet. Chaque sujet au sein des trois thématiques sera porté par une petite équipe qui fonctionnera en mode Agile / Scrum avec un Product Owner (Responsable du Product Backlog) et un Scrum Master.

Nous ne manquerons pas de partager avec vous l’avancement de ce projet au cours de l’année 2021/2022.

En savoir plus

La facilitation dans les projets Agile, comment ça fonctionne ?

Le 26 octobre 20218 octobre 2021 par mopertodans agile, outils et méthodesLaisser un commentaire

Le manuel AgilePM® cite la facilitation comme une technique clé, mais comment devriez-vous utiliser la facilitation dans les projets agiles ?

Facilitation in Agile Projects

https://apmg-international.com/article/facilitation-agile-projects de Tomasz Nedzi

Trois versions de suite du AgilePM® Handbook citent la facilitation comme une technique qui aide à construire l’équipe, à prendre des décisions et à identifier les risques. Cependant, la facilitation est à peine décrite dans le manuel et cet article en présente un résumé et explique comment elle peut être utilisée avec succès dans des projets.

Selon l’une des définitions : « la facilitation est toute action qui rend une tâche facile pour les autres ou une tâche qui est supportée par d’autres ». Le but de la facilitation est de veiller à ce que les réunions et les ateliers soient conçus et menés de manière efficace. Elle permet à l’équipe de prendre des décisions indépendantes, grâce à une personne indépendante, comme un facilitateur. Ce professionnel peut manager correctement les réunions, afin que les participants ne se « nuisent » pas entre eux, mais apprécient les différences d’opinion et en comprennent les avantages.

Qui est le facilitateur ou la facilitatrice ?

C’est une personne qualifiée pour sélectionner le « processus » approprié (formats, modèles, techniques et outils) à la « tâche » (objectif de la réunion).

Certains des modèles/techniques/outils sont :

Paraphraser avec un modèle de feedback,
Les quatre boîtes,
Résumer, Proposer, Produire – Summarise, Propose, Output (SPO)
Modèle Process Iceberg®,
Symptôme, Cause, Action (SCA),
Allégories,
Storytelling.

Ces dénominations semblent plutôt mystérieuses et compliquées et suggèrent que le rôle de facilitateur est difficile. C’est d’autant plus difficile que le facilitateur est censé manifester son impartialité même s’il est impliqué dans le travail ou s’il est émotionnellement dépendant des résultats.

De quoi le facilitateur ou la facilitatrice est-il responsable?

La facilitation met fortement l’accent sur la distinction entre la responsabilité du processus utilisé et la responsabilité de la tâche à réaliser. Comme dans le management de projet, un processus signifie effectuer certaines activités qui mènent à un résultat spécifique. Les normes de management de projet telles que PMBOK® Guide, Praxis Framework, AgilePM® définissent les processus nécessaires pour produire le livrable du projet, mais le livrable ou produit peut être différent pour chacun des projets.

Le manuel de facilitation (« Facilitation. Develop your expertise » par Tony Mann) ne définit pas le contenu de l’atelier (la « Tâche »), qui peut être différente à chaque réunion, mais il aide à identifier (le « Processus ») qui délivrera le résultat requis. Le résultat requis du management de projet est de livrer le produit dans les contraintes du triangle du projet. Le résultat requis de l’atelier facilité devrait être, par exemple, les risques identifiés, les exigences hiérarchisées en un certain laps de temps. Comme dans le cas du management de projet, la facilitation devrait également inclure les parties prenantes, d’autant plus que l’atelier peut être mis en œuvre en utilisant différents formats.

Nous appelons un « Format » la façon dont les ressources sont utilisées pendant la réunion :

Groupe – signifie que les parties prenantes impliquées travailleront ensemble en groupes,
Tous – signifie que tout le monde travaillera seul,
Tout à un – cela amènera toutes les personnes à travailler ensemble avec un seul support, par exemple un tableau à feuilles mobiles,
Un pour tous – une personne communique avec les autres, par exemple quand ils ont l’expérience, les connaissances à partager.
un pour tous, tous pour un

Deux parties prenantes clés sont mentionnées dans le manuel de facilitation

Leader de tâche – personne responsable de la définition de l’objectif de la réunion, par exemple Manager de projet, Leader d’équipe,
Facilitateur – responsable du processus de l’atelier.

Par conséquent, nous nous attendons à ce que le leader de tâche ait des connaissances spécialisées sur la tâche, et le facilitateur n’a donc pas besoin d’être expert en la matière. Une connaissance spécifique de la tâche pourrait même être un obstacle si le facilitateur voulait s’engager dans la création de la solution, perdant ainsi son impartialité.

Il est peu probable que nous nous attendions à ce que le manager de projet soit le facilitateur, mais nous pouvons nous attendre à ce qu’il assume le rôle de leader de tâche. AgilePM® Handbook suggère clairement que le facilitateur devrait être un rôle distinct et indépendant du manager de projet.

Un facilitateur efficace devrait…

Être orienté sur le changement,
être audacieux, courageux, prendre des risques,
avoir un focus général et être focalisé sur les idées,
être flexible,
être prompt à répondre et à agir,
être orienté processus,
être un catalyseur discret,
être extraverti,
être capable de rester calme sous le stress,
avoir un faible niveau de tension,
avoir une large connaissance des affaires.

Estimation du temps et du coût de la facilitation

Le manager de projet doit trouver une personne adéquate pour remplir le rôle de facilitateur, mais il doit également être en mesure d’estimer le temps nécessaire pour mener les ateliers.

Cependant, il y a ici plusieurs risques car les tâches peuvent avoir différents niveaux d’incertitude.

Avec la certitude que la question à laquelle il faut répondre est claire et que la réponse sera facile à obtenir des participants à l’atelier, il est plus facile d’estimer le temps nécessaire. Cette durée estimée sera alors généralement suffisante pour atteindre les objectifs de la réunion.
Lorsqu’il s’agit de complexité, c’est-à-dire que la question est claire, mais que la réponse n’est pas encore connue, le temps estimé à l’origine peut être plus que doublé pendant l’atelier.
Et enfin, lorsque nous avons affaire à l’incertitude (la question/problème est inconnu et doit d’abord être compris pour trouver une réponse ou une solution), le temps réel de l’atelier lui-même peut être jusqu’à 4,5 fois plus long.

De plus, le rôle de facilitateur est de bien manager le « triangle d’or de la facilitation ». Comme dans le cas du « triangle de projet », où les « portée-délais-coûts » restent en équation les uns par rapport aux autres, dans le cas de la facilitation, nous avons un triangle interdépendant « tâche-temps-maturité du groupe ».

Cela signifie que le temps des ateliers dépend de la tâche (que nous connaissons dans le management de projet comme la portée) et de la maturité du groupe/processus, c’est-à-dire de la difficulté de mettre en œuvre une tâche donnée. Cependant, le niveau de difficulté ne peut être estimé que par un facilitateur expérimenté. Cela signifie que le manager de projet (comme dans le cas de l’estimation d’autres tâches du projet) doit utiliser l’aide d’un facilitateur expérimenté pour planifier des ateliers. Cela signifie aussi que la logistique des ateliers (emplacement, équipement) affectera le budget du projet.

En résumé

Un facilitateur expérimenté (comme un manager de projet expérimenté) utilise un processus afin que d’autres personnes puissent atteindre les objectifs. Ce sont les compétences et l’expérience du facilitateur (comme dans le cas du manager de projet) qui déterminent l’efficacité avec laquelle il ou elle gère la sélection des outils appropriés et l’ajustement du processus aux exigences de la tâche. La facilitation (un peu comme le management de projet) est une activité professionnelle différente. La responsabilité du manager de projet est d’aller chercher et de motiver un professionnel suffisamment expérimenté pour obtenir des résultats d’atelier satisfaisants.

Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning ?

Le 14 septembre 202118 août 2021 par mopertodans agile, outils et méthodesLaisser un commentaire

Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.

Unravelling PI Planning

https://www.digite.com/blog/unravelling-pi-planning/ par Anshuman Singh

Il y a une citation présentant le contenu du PI Planning sur Scaled Agile Framework : “Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning”.

Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.

La plupart des organisations qui mettent en œuvre SAFE® ne le mettent pas entièrement en œuvre. Mais s’il y a un dénominateur commun entre toutes ces mises en œuvre de SAFE®, c’est le PI Planning. Ainsi qu’est-ce que le PI Planning ? Et que signifie ‘PI’ dans PI Planning ?

Eh bien, PI signifie Programme Increment, un Incrément de Programme. Un Incrément de Programme entre dans une fenêtre de temps (timebox) de 8 à 12 semaines (le défaut étant 10 semaines comme recommandé par Scaled Agile Inc.). Cette timebox de 10 semaines encapsule 5 Sprints Agiles ou Itérations de 2 semaines. La 10^ème semaine du PI se termine avec la Démonstration de PI où le travail construit pendant le PI est présenté aux parties prenantes. (Il est utile de noter ici, qu’un PI est un incrément d’un Programme entier. Un Programme est là où les équipes et autres ressources sont investies d’une mission de développement importante. Un Programme consiste donc en de multiples Incréments de Programme.

Comme le PI a 5 itérations avec des équipes multiples travaillant en cadence pour réaliser une vision commune, il est important pour ces équipes de se rassembler et planifier le cours des actions pour la durée entière du PI. La réunion aide aussi les équipes à comprendre quelles sont les dépendances entre elles et les risques à adresser. Cette réunion est appelée PI Planning. C’est une réunion complexe et détaillée d’une durée de 2 jours pendant la semaine 10 du PI.

Alors, qu’est-ce qui entre dans un PI Planning ?

La Vision du Programme et le Programme Backlog sont deux entrées principales et essentielles pour conduire une réunion de PI Planning. La Vision fournit le contexte à l’équipe entière sur pourquoi et comment le travail fait dans le PI aidera dans la construction de la Solution complète. Le Programme Backlog comprend des 10 premières fonctionnalités classées par priorité et accompagnées de descriptions courtes des bénéfices business que la fonctionnalité génèrerait.

Le Programme Backlog appartient au Product Manager qui est aussi responsable de s’assurer qu’on l’ordonne selon la priorité business en fonction de la réalité du marché et d’autres facteurs exogène. Les 10 premières fonctionnalités sont aussi accompagnées de Starter Stories (beaucoup d’histoires peuvent manquer, beaucoup ont besoin d’être décomposées ou sont des duplications dans les backlogs d’autres équipes). Ces Starter Stories permettent aux équipes de démarrer rapidement leur planification pour le PI.

PI Planning

La réunion de PI Planning s’applique à l’équipe entière allouée au Agile Release Train et on s’attend à ce que chacun y participe. Si certains des membres d’équipe sont à d’autres emplacements géographiques, ils doivent participer à distance. La réunion de PI Planning est divisée en différentes sessions sur un créneau de 2 jours.

La réunion de PI Planning est organisé par le Release Train Engineer (RTE, aussi appelé le Scrum Master du Agile Release Train). Le RTE présente la Vision et les 10 premières fonctionnalités à la session inaugurale du PI Planning. Après cela, toutes les équipes entrent dans leurs sessions respectives où elles évaluent leur propre vélocité pour au moins les 2 premières itérations sur les 5. Les équipes mûrissent les fonctionnalités et les Starter Stories et évaluent leur taille. À la fin du premier jour, les équipes se réunissent avec les Business Owners, des architectes système et d’autres parties prenantes pour obtenir des clarifications et mettre en avant leur compréhension.

Le deuxième jour, les équipes entrent de nouveau dans des sessions spécifiques et détaillent encore davantage leurs backlogs respectifs. Chaque équipe formule une liste d’objectifs appelés des Objectifs d’Équipe et les Business Owners donnent chacun des objectifs un score de Valeur Business. Le score de Valeur Business est un chiffre entre 1 à 10 (10 pour la Valeur la plus élevée côté business, 1 pour la plus basse). Plusieurs objectifs peuvent avoir le même score de Valeur Business.

Après cela, chaque équipe présente son plan au groupe assemblé en entier. Le plan met en évidence les risques identifiés, les dépendances prévues et les objectifs agréés avec leur Valeur Business. Une fois que chacune des équipes a achevé sa présentation, une liste agrégée d’objectifs d’équipe est présentée et une liste agrégée de risques de Programme est aussi compilée.

L’équipe discute chacun des risques et les adresse avec l’approche ROAM (Resolved, Owned, Accepted, Mitigated). Finalement, il y a un vote de confiance où chaque équipe donne son score (entre 1 et 5) de confiance d’atteindre les divers objectifs. Si une équipe donne un score de moins de 3, ses membres doivent exprimer leurs réserves qui sont discutées avec le groupe entier. Le problème pourrait ajouter à la liste de risques ou exiger un peu de re-planification ou être simplement informatif. Si nécessaire les équipes retravaillent leurs plans jusqu’à ce qu’un fort niveau de confiance puisse être atteint.

La magie de SAFe tient en grande partie à ce qui va sortir du PI Planning.

Productions du PI Planning

Les productions de la réunion PI Planning sont les suivantes

Une liste d’Objectifs d’Équipe avec la Valeur Business, où les objectifs sont les résumés business de ce que chaque équipe a l’intention de livrer dans le prochain PI.
Il y a aussi des Objectifs additionnels que chaque équipe peut avoir choisi au cas où elle serait capable d’achever son travail et qu’une certaine bande passante resterait.

Les objectifs d’équipe sont agrégés et raffinés pour former les Objectifs complet du PI avec sa Valeur Business. C’est réalisé par le RTE après que la réunion de PI Planning soit finie et pas pendant la réunion.

Nous gagnons une compréhension de la vitesse de chaque équipe au minimum pour l’Itération 1 et 2, avec des histoires d’utilisateur de taille identifiée pour ces itérations sur lesquelles les équipes travailleront.
Une production importante du PI Planning est le tableau de Dépendance de Programme qui dépeint les Fonctionnalités / Histoires, les Dépendances et les jalons marquants. Les architectes et des membres d’équipe UX jouent un rôle clef pour aider à identifier ces dépendances.
Le PI Planning donne aussi une liste de Risques identifiés et comment ils ont été adressés à travers le mécanisme ROAM.

Rôles Principaux dans le PI Planning

Les rôles clefs et leur fonction pendant le PI Planning sont mis en évidence ci-dessous.

Business Owner – fournit la Valeur Business et l’approbation des Objectifs de l’Équipe PI
Product Manager – fournit les 10 premières fonctionnalités priorisées du backlog
RTE – présente le processus de planification et les résultats attendus
Product Manager et ScrumMasters – supportent les sessions d’Équipe et la décomposition des histoires
Équipes Agiles – mûrissent les fonctionnalités des Histoires d’Utilisateur pendant les sessions d’Équipe, identifient les risques et donnent le crucial vote de confiance
Architecte Système / – aide à établir des dépendances inter-équipe et les risques

Épilogue

Le PI Planning sert la fonction importante de rassembler l’équipe entière et d’aider ses membres à gagner une perspective unifiée sur le travail qu’ils vont accomplir.

Les équipes entendent directement des Business Owners, les leaders organisationnels, comment le PI en cours de planification aidera l’organisation à s’approcher des ses objectifs finaux et quel est l’avenir attendu de la solution en construction.

Sur une note plus banale, les équipes sont capables de mettre en évidence les interdépendances et comment elles prévoient de les adresser avec succès. Ayant formulé les objectifs du PI, les équipes développent un sentiment d’appropriation pour les livrer.

La réunion de PI Planning est organisée dans la 5ème itération du PI qui est l’Itération de l’Innovation et de la Planification et n’a ainsi pas à être planifiée sur un créneau de temps complémentaire. Elle répond au besoin de perspective que les équipes désirent souvent mais obtiennent rarement. Elle distribue la planification et le contrôle du travail aux équipes qui sont en fin de compte responsables de sa livraison.

Et c’est une bonne chose!

Anshuman Singh, Product Manager, SwiftEASe

Regardez comment SwiftEASe aide dans les réunions de PI Plannning et suit les objectifs, risques et le statut d’achèvement de fonctionnalités du PI.

SAFe® et Scaled Agile Framework sont des marques déposées de Scaled Agile, Inc.

Choses à faire avant la réunion de planification du sprint

Le 13 septembre 20215 août 2021 par mopertodans agile, experience sharingLaisser un commentaire

Découvrez ce que vous devriez faire avant même le début de votre réunion de planification de sprint afin de faire du prochain sprint un succès.

https://blog.gurock.com/sprint-planning/ par Nishi Grover Garg

Les équipes Scrum se réunissent pour décider des éléments de travail de leur prochain sprint lors de la réunion de planification du sprint. Mais est-ce le début de la conversation pour le sprint à venir, ou y a-t-il des choses à faire avant ?

Priorisez le Product Backlog, l’arriéré de produit

La première et la plus importante considération est d’avoir un product backlog vivant qui est à jour et hiérarchisé pour suivre l’évolution des besoins de l’entreprise. Le propriétaire de produit doit avoir un œil constant sur l’ajout, la suppression, la modification et la mise à jour d’éléments dans le product backlog. Lorsque le temps vient de planifier le sprint suivant, le chef de produit doit apporter à la table une liste des éléments de valeurs les plus élevées que l’équipe puisse choisir.

Détaillez les fonctionnalités

Étant donné que la plupart des exigences agiles sont courtes, soit sous la forme d’histoires utilisateur (User Stories) ou simplement de phrases listant les fonctionnalités nécessaires, elles nécessitent d’être détaillées pour pouvoir être implémentées. Le propriétaire de produit doit passer du temps à rechercher chacune des fonctionnalités et à essayer de présenter en termes simples le besoin réel que chacune exprime. Utilisez des listes à puces ou des phrases simples, pour expliquer la fonctionnalité en détail. Nous voyons cela se produire principalement pendant ou après la réunion de planification du sprint, mais si des exigences sont connues avant la réunion, le propriétaire de produit peut avoir une longueur d’avance.

Décidez d’une définition de done

Au cours d’une réunion de planification de sprint, l’équipe choisit généralement ce qu’elle fera et livrera à la fin de cette itération de sprint. Il est impératif que les membres de l’équipe connaissent et conviennent d’une définition de done pour chaque histoire utilisateur ainsi que chaque tâche de chacune. Qu’il s’agisse d’une tâche de développement, d’une tâche de conception ou d’exécution de test ou d’une tâche de revue de livrable, tout le monde doit s’accorder sur une compréhension commune de ce que signifie « done » afin d’assurer une livraison fluide et aucun conflit à la fin du sprint.

Soignez les user stories

Chaque histoire utilisateur qui est mise en avant pour la planification du sprint doit être soignée, développée et détaillée avec les connaissances et les commentaires de l’équipe entière.

Lorsque les testeurs, les développeurs et le propriétaire de produit s’assoient ensemble et discutent d’une nouvelle fonctionnalité, de nombreuses nouvelles questions peuvent survenir de la part de l’équipe. Les questions portent souvent sur l’intégration avec les fonctionnalités existantes, le comportement de la fonctionnalité dans des cas spécifiques ou la manière dont le comportement doit être adapté pour différents types d’utilisateurs. Les cas spéciaux font également partie des critères d’acceptation définis dans l’histoire utilisateur pour la rendre complète.

Quelles que soient les questions, il est préférable de les poser au plus tôt et d’y répondre avant de choisir l’histoire utilisateur. Fondamentalement, cela signifie qu’une conversation doit avoir lieu pour chaque user story, afin que l’équipe puisse se comprendre et décider des critères d’acceptations définis et agréés par tous.

Ces sessions de « toilettage d’histoires » doivent avoir lieu avant la réunion de planification du sprint afin que pendant la planification, l’équipe sache exactement ce qui est requis de cette fonctionnalité et puisse donner de meilleures estimations et story points en fonction de sa complexité.

Commencez par le design

De nombreuses histoires utilisateur ont besoin de storyboards visuels ou de maquettes de l’interface utilisateur, et dans ces situations, les concepteurs d’expérience utilisateur ou UX designers peuvent avoir besoin d’être impliqués. Ces histoires doivent être sélectionnées un sprint à l’avance et allouées d’abord aux UX designers, afin qu’ils puissent construire les maquettes ou les images d’écran prêtes avant que la fonctionnalité ne soit sélectionnée pour le développement dans le sprint suivant. Cette approche facilite la communication et évite les retards pendant le développement.

De même, certaines histoires utilisateur peuvent nécessiter une recherche sur une nouvelle approche, une nouvelle technologie ou un nouvel outil avant de commencer, ou il peut être nécessaire de créer un design d’architecture complet pour une certaine partie avant de se lancer dans sa mise en œuvre. Dans de tels cas, la tâche de conception ou de R&D doit être créée et démarrée dans un sprint précédent, puis allouée au développeur ou à l’architecte principal au sein de l’équipe pour préparer les designs et résultats de recherche pertinents. Ils peuvent ensuite partager ces informations avec l’équipe afin que tout le monde soit prêt à commencer à travailler sur la mise en œuvre dans le sprint suivant.

Un propriétaire de produit doit être constamment à l’affût des histoires utilisateur qui peuvent nécessiter un travail de conception ou de recherche avant de les commencer, et avoir ces user stories distribuées aux personnes concernées avant le sprint pour s’assurer que la mise en œuvre sera fluide et que la livraison pourra avoir lieu à temps.

Nishi est une formatrice en entreprise, une passionnée agile et une testeuse dans l’âme ! Avec plus de 11 ans d’expérience dans l’industrie, elle travaille actuellement chez Sahi Pro en tant qu’évangéliste et responsable des formations. Elle est passionnée par la formation, l’organisation d’événements et de rencontres pour une communauté de test, et a été conférencière lors de nombreux événements et conférences de test.

Consultez son blog où elle écrit sur les derniers sujets dans les domaines Agile et Testing.

Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire.

The Agile Manifesto: Why Agile Makes Sense

Pourquoi l’agilité a du sens

Comment les auteurs du manifeste agile m’ont inspiré

James Grenning

James Grenning sur InfoQ

Jim Highsmith

Gestion de projet agile par Jim Highsmith

Andrew Hunt

L’essence de l’agilité, comme indiqué dans « le programmeur pragmatique »

Ron Jeffreys

Ron Jeffries dans Story Points Revisited

Ron Jeffries sur The Nature of Software Development

Jon Kern

Jon Kern dans Agile dans Agile in the Context of a Holistic Approach

Brian Marick

Brian Marick dans l’interview de Leanpub Frontmatter

Agile a du sens

partagez ce billet avec vos amis, collègues et relations professionnelles

Voici une série de vidéos courtes qui peuvent vous être utiles pour répondre aux questions de certaines de vos parties prenantes sur Scrum et Agile.

partagez ce billet avec vos amis, collègues et relations professionnelles

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé.

In Scrum, when is a sprint over?

https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/ par Leon Tranter

Qu’est-ce qu’un sprint ?

Pourquoi est-il timeboxé ?

Quand un sprint est-il terminé ?

De quelles autres façons un sprint peut-il se terminer ?

partagez ce billet avec vos amis, collègues et relations professionnelles

Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.

Seven Sins of Reviews

https://kbondale.wordpress.com/2021/04/18/seven-sins-of-reviews/ par Kiron Bondale

Bien qu’il y ait probablement plus que ces façons de gâcher les revues, en voici sept dont j’ai été témoin.

#1 – Le seul participant est un Product Owner (ou un rôle similaire représentant la voix du client).

#2 – Trop en mettre dans une seule revue et ne pas laisser suffisamment de temps aux parties prenantes pour digérer ce qu’elles ont vu.

#3 – Organiser une démonstration plutôt qu’un échange bidirectionnel.

#4 – Avoir les mauvaises personnes dans la revue.

#5 – Prendre des engagements pendant la revue.

#6 – Critique ouverte du travail de l’équipe.

#7 – Ne pas prendre suffisamment de temps pour analyser ce qui a été appris lors d’une revue.

Des critiques bien managées sont un ingrédient clé de la construction du bon livrable pour nos clients, donc éviter ces sept péchés contribuera grandement à tirer une valeur réelle de ces rencontres critiques.

partagez ce billet avec vos amis, collègues et relations professionnelles

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :

En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.

Ayez une attitude constructive et une approche communicative

Coachez les autres membres de l’équipe sur les aspects pertinents du test .

Collaborez avec les développeurs, le Product Owner et les stakeholders pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.

Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .

Reportez les défauts et travaillez avec l’équipe pour les résoudre.

partagez ce billet avec vos amis, collègues et relations professionnelles

Les gens attendent bien trop longtemps avant de demander de l’aide !

Lost Art of Asking for Help

https://rgalen.com/agile-training-news/2021/2/16/lost-art-of-asking-for-help par Robert Galen

Les gens attendent trop longtemps pour demander de l’aide !

Le Statut Pastèque

Les Raisons Possibles

#1 – Typiquement, le temps n’améliore pas les choses …

#2 – Comment vous commencez est critique

#3 – Trop d’espoir et d’orgueil …

#4 – Plus haut vous êtes, plus dur il y parait …

#5 – Le budget semble toujours être un challenge …

J’aimerais entendre vos histoires, vos perspectives et vos diverses réactions.

Post-scriptum

partagez ce billet avec vos amis, collègues et relations professionnelles

Scaling Success

https://agile-scrum.com/2021/02/05/scaling-success/ par Zuzi Sochova

#1 – Créez le sens de l’urgence

#2 – Construisez une coalition de direction

#3 – Formez une vision et des initiatives stratégiques

#4 – Enrôlez une armée de volontaires

#5 – Permettez l’action en faisant tomber les barrières

#6 – Générez des victoires dans le court terme

#7 – Soutenez l’accélération

#8 – Institutionnalisez le changement

Agile est un changement majeur et sans le conduire comme un changement vous aurez beaucoup de mal à réussir.

partagez ce billet avec vos amis, collègues et relations professionnelles

Des approches SMART sont utilisées pour évaluer les exigences dans les projets en cascade, prédictifs. Elles s’appliquent aussi aux projets agiles.

Spécifique

Mesurable.

**Pourquoi est-il timeboxé ?**

Mais comment faire cela dans un environnement Agile PRINCE2^® ?

**Un des anti-modèles les plus courants aux Réunions Daily Scrum est la participation active des managers.**