L’importance d’avoir une philosophie qualité dans l’environnement Agile

Cet article passe en revue les principales différences entre la qualité interne et externe et insiste sur l’importance d’avoir une philosophie de qualité dans l’environnement Agile.

The importance of having a quality philosophy in the agile encironment

https://www.agilequalitymadeeasy.com/post/the-importance-of-having-a-quality-philosophy-in-the-agile-environment-david-tzemach par David Tzemach

Les différences entre qualité interne et externe

Pour comprendre le vrai sens de la qualité, vous devez faire la distinction entre qualité interne et externe :

  • La qualité externe fait référence à ce que le client voit lorsqu’il interagit avec le logiciel. Un exemple de mauvaise qualité externe est une interface utilisateur non intuitive qui nécessite une navigation complexe pour utiliser une fonction simple.
  • La qualité interne fait référence à tous les problèmes non visibles pour le client qui ont un impact sur la maintenabilité et la stabilité du système, tels que la conception du code et la couverture des tests.

Quel type de qualité est le plus important ?

Les deux sont importants, en supposant que l’équipe a le temps, les ressources et les connaissances nécessaires pour s’occuper des deux.

Mais que se passe-t-il lorsque vous devez livrer rapidement et que vous devez en choisir un ?

Il n’y a pas de réponse définitive, car chaque type présente des avantages et des inconvénients. D’expérience, un système de forte qualité interne peut être livré même avec une faible qualité externe (nous voyons cela tout le temps dans l’industrie du logiciel). Cependant, un système de faible qualité interne rendra presque impossible la construction d’une qualité externe élevée. Comment pouvez-vous construire un système qui repose sur des fondations défaillantes ?

Qu’est-ce qu’une philosophie de qualité et pourquoi en avez-vous besoin ?

Dans le cadre de tout projet de développement (Agile ou autre), l’organisation doit déterminer le niveau de qualité qu’elle s’attend à délivrer au marché et à ses clients. Le niveau de qualité doit être dérivé de la philosophie de qualité.

La philosophie de qualité est le niveau acceptable de tolérance du projet pour les écarts de qualité (par exemple, la dette technique, la faible couverture de code, etc.) et les problèmes rencontrés après la livraison des produits.

À chaque extrémité du spectre de la philosophie de la qualité, nous avons une tolérance élevée pour la mauvaise qualité et une faible tolérance pour la mauvaise qualité.

Tolérance élevée pour la mauvaise qualité

L’équipe est censée livrer les produits le plus tôt possible, quelle que soit la qualité des livrables.

Relisez ce billet

Cela inclut la fourniture d’éléments présentant des problèmes de qualité importants (par exemple, les tests ne passent pas, plusieurs bogues sont connus, etc.) et même sans tests terminés. C’est parce que la philosophie de qualité de l’organisation est de battre sur les délais la concurrence à tout prix et de combler les lacunes manquantes par la suite.

Faible tolérance pour la mauvaise qualité

Le livre de Phil B. Crosby

L’équipe est censée livrer des produits sans compromettre leur qualité, qui est censée être au plus haut niveau possible. Pour ce faire, les équipes de développement réduisent le nombre d’histoires utilisateur qu’elles peuvent fournir par version pour créer des infrastructures automatisées, en exécutant plus de tests et en passant une grande partie de leur temps à s’assurer que chaque fonctionnalité est produite avec la meilleure qualité possible.

Flux et vitesse

Comme vous pouvez le constater, la philosophie de qualité organisationnelle affecte considérablement le flux de travail et la vitesse de livraison. Par conséquent, elle doit être communiquée aux équipes d’ingénierie, car elle a un impact substantiel sur leur travail quotidien.

Notez que même si votre entreprise a une tolérance élevée pour la mauvaise qualité, cela ne signifie toujours pas que vous pouvez livrer des produits de mauvaise qualité à vos clients.

Cependant, cela permet à l’équipe de réduire la couverture des tests (d’un montant acceptable), de prendre plus de risques et d’investir moins dans la qualité « externe » car la qualité interne reste non négociable.

#SAFe ressemble beaucoup à un livre de cuisine

#SAFe en tant que livre de recettes est bon pour les gens qui ne savent pas par où commencer et qui préfèrent ne pas partir de rien.

Mais il faut bien sûr aller plus loin pour devenir un véritable cuisinier Agile.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

SAFe s a lot like a cookbook

https://www.linkedin.com/posts/michaelkuesters_safe-safe-learning-activity-6925771413186359296-b6WB/ de Michael Küsters

Beaucoup de critiques concernant SAFe sont dirigées vers la prescription détaillée qu’il donne du « comment faire ».

Comment exécuter les rencontres, comment chaque rôle doit fonctionner, comment faire ceci ou comment faire cela.

SAFe peut être perçu comme un livre de cuisine détaillé qui répond à toutes les questions, et superficiellement, c’est vrai.

Oui, la documentation fournie par Scaled Agile, Inc est le livre de recettes officiel de SAFe.

Et oui, elle compose ce que nous connaissons officiellement sous le nom de SAFe.

Suivez cette recette, disent-ils, et vous cuisinerez SAFe correctement.

Mais.

Tout comme vous pouvez cuisiner un plat exactement comme le dit la recette, il n’y a aucune garantie que vous en aimerez le résultat. Et en ne suivant que des recettes, vous ne deviendrez jamais un bon cuisinier.

Si vous ne pouvez rien faire sans vous baser sur des recettes écrites par d’autres, vous pouvez avoir l’illusion que vous pouvez cuisiner, mais en réalité, vous ne le pouvez pas. Si vous le pouviez, vous n’auriez pas besoin de quelqu’un pour réfléchir à votre place.

  • Est-ce mal d’avoir des recettes ? Non.
  • Est-ce mal d’utiliser des recettes ? Non.
  • Est-il possible d’obtenir un bon résultat en suivant des recettes ? Oui.
  • Pouvez-vous construire votre avenir sur des recettes créées par d’autres ? Non.

#SAFe est excellent pour les personnes qui ne savent pas par où commencer et qui préfèrent ne pas partir de rien. Il vous donne de nombreuses instructions sur la façon de commencer.

À partir de là, vous devez (pour ainsi dire) apprendre à cuisiner par vous-même, sinon tout ne sera que gaspillage.

Surtout, si la seule chose que vos consultants SAFe peuvent faire pour vous est de vous relire ce que dit la recette, ils ne vous aident pas.

Si vous savez lire, vous pouvez lire la recette par vous-même. Ils ou elles doivent vous apprendre à créer vos propres recettes.

La mort de la dérive de contenu (le « scope creep ») et le management de projet Agile

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible.

The Death of Scope Creep  – Agile Project Management

https://www.projectsmart.co.uk/scope-management/the-death-of-scope-creep-agile-project-management.php  par Duncan Haughey

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible. Les organisations qui adoptent l’agilité, qui s’équipent pour s’adapter, sont mieux préparées à s’adapter rapidement aux évolutions fréquentes du marché et aux besoins des clients.

Cependant, d’après mon expérience, la flexibilité de l’agilité peut être une arme à double tranchant. Lorsque vous avez beaucoup trop de latitude sans définitions explicites, la dérive de contenu se produit. Et si vous ne contrôlez pas ce glissement du périmètre, vous vous retrouverez avec des membres de l’équipe fatigués, des clients mécontents et une initiative qui a déraillé !

Qu’est-ce qui motive la dérive de contenu dans les projets agiles ?

Et plus important encore, comment pouvez-vous l’empêcher de mettre en danger vos projets ?

Continuez à lire ce billet pour le savoir.

À quoi ressemble le Scope Creep et comment pouvez-vous le repérer ?

La dérive de contenu se produit lorsque les besoins, les objectifs ou les buts d’un projet changent bien au-delà de ce qui a été promis à l’origine. Chaque fois que ce changement se produit, le projet n’est plus strictement décrit. Et pire encore, les limites des attendus et finalement de la fin du projet deviennent floues.

Savoir à quoi ressemble le scope creep n’aide que si vous savez comment le repérer, et il existe plusieurs façons de le faire. Peut-être introduisez-vous progressivement des choses mineures. Peut-être que les délais sont ignorés. Les délais manqués peuvent amener les membres de l’équipe à mal comprendre leurs devoirs et obligations. Peut-être que votre analyste d’affaires est moins directement engagé.

Si vous apercevez de tels signes, la dérive de contenu met probablement en danger votre projet.

Qu’est-ce que la dérive de contenu et le management de projet agile ?

Dans le management de projet agile, la dérive de contenu fait généralement référence à des changements réguliers, mais non approuvés et non planifiés, qui ont un impact négatif sur les limites du projet. Généralement, en pratique, de tels scénarios signifient que vous mettez constamment en œuvre des changements sans tenir compte de la façon dont le projet en est impacté.

Comment reconnaître cette dynamique ?

Eh bien, ce glissement se manifeste le plus souvent avec l’ajout de nouvelles fonctionnalités et services aux produits. Et cela se produit surtout lorsque de tels ajouts sont effectués sans tenir compte de l’effet sur d’autres limites du projet (par exemple : les délais, le budget, le personnel, la qualité, la sécurité, etc.).

Donc, beaucoup d’entre nous, y compris moi-même, sont conscients du concept de triple contrainte dans le management de projet : Si le contenu d’un projet change, cela peut en affecter la durée et / ou les coûts. Si les effets sur les délais et le budget ne sont pas pris en compte, la qualité va en souffrir. Et c’est ainsi que vous obtenez une dérive de contenu dans le management de projet agile.

Comment éviter que la flexibilité agile ne provoque de dérive de contenu

Pour éviter le glissement de portée associé à la flexibilité requise avec l’agilité, créez votre processus de contrôle des modifications à l’aide d’un tableau Kanban. Une flexibilité incontrôlée peut éventuellement entraîner une dérive de contenu et détourner le projet de son plan initial. Même si votre portée est flexible, restez constamment aligné avec votre plan.

Comment ? Utilisez le nettoyage du backlog (backlog grooming), également connu sous le nom de SCRUM refinement. Cette activité importante est trop souvent négligée.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Le nettoyage du backlog doit être effectué une fois par sprint et implique les éléments suivants
  • Ajout de critères, de contexte, d’urgence, d’estimations ou d’éléments narratifs aux éléments du backlog avant de les pousser vers la production dans un cycle.
  • Suppression des éléments inutiles qui n’offrent plus de sens pour le projet.
  • Harmoniser les objectifs avec la vision pour maintenir un bon périmètre.

Il est essentiel de prendre ces mesures pour minimiser ou prévenir la dérive de contenu. En fin de compte, le nettoyage du backlog permet aux équipes d’accélérer la planification des sprints et d’améliorer l’allocation et la décomposition du travail. Le processus permet essentiellement à un système efficace de management du changement de prendre effet tout en maintenant la flexibilité souhaitée.

Impliquez tous les membres de l’équipe de projet et atténuez les causes du scope creep

Pour éviter la dérive de contenu, impliquez tous les membres de l’équipe. Cela signifie que, même lorsque vos parties prenantes sont satisfaites, n’oubliez pas de vérifier que vos développeurs sont également satisfaits. Informez-les du processus de management des changements et de la façon dont cela les affectera. Ils doivent être des gardiens, des garants de la portée du projet, plutôt que des acteurs du changement.

Gardez également à l’esprit que les membres de l’équipe projet, du moins d’après mon expérience, aiment aider et peuvent accepter d’apporter de gros changements sans passer par la procédure de management des changements.

Pour éviter cela, précisez que tout le monde ne devrait pas accepter d’apporter des modifications à moins d’y être autorisé pour éviter de perturber le calendrier du projet et potentiellement créer une dérive de contenu. Tout membre de l’équipe qui souhaite aider les intervenants doit décrire la procédure de contrôle des changements et se porter volontaire pour aider à enregistrer la demande de changement.

Pourquoi est-il si important d’être si vigilant ?

C’est une question à laquelle il est facile de répondre : la dérive de contenu est un sérieux problème dans les projets agiles, en particulier lorsque le manager de projet, les équipes et les partenaires n’apprécient pas l’effet que les changements peuvent avoir sur l’équipe, le budget et les délais. Heureusement, si vous êtes explicite sur la portée initiale du projet et que vous gérez correctement les modifications apportées à votre plan de projet tout au long de la durée de vie du projet, il est peu probable que la dérive de contenu soit un problème majeur.

Mais pour en être certain, vous aurez toujours besoin d’un système de management de projet efficace qui soit à la hauteur du défi, alors utilisez des outils de management des changements qui vous permettent de documenter de nouvelles modifications et d’évaluer instantanément l’impact de ces modifications.

En tant que manager de projet, vous pouvez hiérarchiser ces modifications et allouer les tâches aux membres de l’équipe à l’aide de solutions telles que ProjectManager. Ensuite, une fois qu’un changement est autorisé, quelqu’un peut s’y atteler immédiatement.

Mettez en œuvre des procédures de management des changements

Que se passe-t-il lorsque quelqu’un essaie d’apporter des changements ? Selon mon expérience, il est naïf de croire que rien ne changera. Mais tous les changements ne sont pas mauvais. Un changement structuré, bien géré et approuvé dans vos projets est tout ce dont vous avez besoin pour éviter la dérive de contenu.

Pour cultiver de tels changements, vous voudrez utiliser une stratégie de management des changements pour décrire les processus de contrôle du changement qui doivent être mis en œuvre et quand le plan de projet doit être mis à jour.

Il est également essentiel de mettre en place une procédure de management des risques qui spécifie la fréquence à laquelle le statut global de votre projet sera évalué. Cette étape vous permet de tenir à jour le registre des risques dont la dérive de contenu.

Et le processus n’a pas besoin d’être intimidant : une procédure de gestion des changements est simple. Fondamentalement, quelqu’un propose un changement via une demande qui est ensuite examinée, acceptée ou refusée. Si elle est acceptée, le changement est inclus dans le plan du projet. L’utilisation des fonctionnalités de management des changements fournies par votre outil de gestion de projet facilitera ce processus.

En fait, l’établissement des mesures correctives implique de déterminer qui évaluera et approuvera les changements car, sans méthode, le changement se produit sans prévenir.

Évitez les changements de DERNIÈRE MINUTE

Enfin, pour éviter toute dérive de contenu, évitez tout changement de dernière minute. Commencez par déterminer la portée de votre projet en fonction des besoins de vos parties prenantes. Ensuite, à l’aide d’une structure de répartition du travail (WBS), générez un plan de travail complet. Le plan de travail est la conséquence de savoir ce que votre projet apportera. Dans le plan, incluez tous les besoins et la façon dont vous y répondrez sous forme d’activités, d’événements et d’objectifs.

Pour vous assurer que vous n’avez rien négligé, faites le lien entre l’échéancier de votre projet et votre processus de management des besoins.

Conclusion & à retenir

Quel que soit le projet, l’évolution des besoins est considérée comme un échec de planification dans le management de projet conventionnel. Aussi, votre étape de planification initiale doit-elle être solide comme le roc, surtout si vous voulez éviter la dérive de contenu.

Si vous ignorez la dérive et n’essayez pas de l’empêcher de se produire en premier lieu, vous risquez de mener votre projet à l’échec et personne ne souhaite cela !

Comment contrôlez-vous la portée de vos projets ?

Comportements de leadership pour une culture de changement agile

L’agilité est un comportement et des attitudes, pas une méthodologie ni un ensemble de processus ou de techniques

Leadership behaviours for an Agile Change culture

https://agilechangemanagement.co.uk/leadership-behaviours-for-an-agile-change-culture deMelanie Franklin

Téléchargez le livre blanc en anglais

Nous savons que l’agilité n’est pas une méthodologie ni un ensemble de processus ou de techniques. L’agilité est le comportement et les attitudes qui permettent aux individus et aux organisations de se déplacer rapidement et facilement.

Au niveau individuel, cette capacité conduit à l’innovation, à la créativité, à l’adoption rapide de nouvelles méthodes de travail.

Au niveau organisationnel, ce comportement est démontré par des améliorations continues, la recherche de nouveaux apprentissages, la volonté d’adopter de nouvelles approches et, en fin de compte, une mise sur le marché de nouveaux produits et services aux clients plus rapide et plus créative.

Les comportements agiles sont soutenus par de nouvelles façons de planifier et de hiérarchiser le travail, mais ils ont besoin d’un environnement qui encourage et récompense leur utilisation.

Les leaders sont les principaux acteurs dans la création de cet environnement.

Les leaders ne sont pas limités à ceux qui ont un pouvoir hiérarchique au sein de leurs organisations.

Un leader est quelqu’un que les autres suivent volontiers.

Je travaille avec de nombreuses organisations à différentes étapes dans l’agilité, et j’ai observé un groupe central de comportements travaillant ensemble, qui permettent aux processus et techniques agiles de s’épanouir :

  1. Imaginez l’état futur
  2. Faites évoluer votre vision
  3. Identifiez les petites étapes
  4. Vivez dans l’incertitude
  5.  Prenez des décisions
  6. Sollicitez l’avis des autres
  7. Abandonnez le contrôle

Si vous occupez un poste de leadership, j’ai écrit un document qui vous donnera l’occasion de comparer votre propre comportement à l’excellence agile et d’identifier les domaines à améliorer.

Si vous êtes manager de projet/programme, PMO ou Product Owner, cela vous donnera beaucoup d’idées sur ce dont il faut discuter avec votre sponsor.

https://agilechangemanagement.co.uk/wp-content/uploads/2022/04/Leadership-behaviours-for-an-Agile-Change-culture.pdf

Téléchargez ce guide sur le site de notre partenaire Virage Group

Guide Scrum pour les leaders

Si vous dirigez des équipes Scrum ou si vous êtes un leader dans une organisation qui tire parti de Scrum, le Guide « Scrum Companion for Leaders » est fait pour vous.

Il examine les différents éléments de Scrum et réfléchit à un moyen efficace pour les dirigeants de s’engager dans l’agilité.

Le guide a été écrit pour la version Scrum Guide 2020.

Il existe de nombreuses définitions du leadership qui s’appliquent à l’utilisation de Scrum. Les leaders sont à la fois à l’intérieur et à l’extérieur de l’équipe Scrum. Tout le monde fonctionne avec un certain niveau de leadership. Cependant, ce guide est axé sur les personnes qui sont en dehors de l’équipe Scrum. Par exemple, les managers des ressources humaines, les managers de projets et de programmes et les responsables de département. Si vous êtes un exécutif, nous vous suggérons de lire la première section car elle vous fournira un contexte sur le fonctionnement de Scrum dans votre organisation.

Télécharger la version française

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Disponible dès maintenant, le rapport 2022 sur l’état du coaching agile : « 2022 State of Agile Coaching Report »

Le Business Agility Institute, Scrum Alliance et ICAgile ont collaboré pour affiner davantage la mesure de l’impact du coaching agile.

Avec les données de plus de 2 000 coachs agiles professionnels qui ont partagé leurs expériences sur l’impact du coaching agile, le deuxième rapport annuel sur l’état du coaching agile est publié et disponible dès maintenant. Le rapport couvre un éventail de sujets liés au coaching agile dans le monde réel, y compris le retour sur investissement, la valeur et les métriques permettant de définir le succès.

 

Téléchargez le document

Ce rapport montre que le coaching agile reste un domaine en pleine croissance, que la demande de coachs qualifiés continue d’augmenter et que les coachs apportent des améliorations mesurables au sein des organisations.

Les coachs pensent que le plus grand impact qu’ils et elles ont est de faire évoluer une organisation vers un état d’esprit et une culture agiles.

Fait intéressant, ils et elles trouvent également que c’est le changement le plus difficile à faire, et l’un des plus grands obstacles à l’agilité s’il n’est pas atteint.

L’agilité dans le business est un ensemble de capacités organisationnelles, de comportements et de méthodes de travail qui offre à votre entreprise (ou organisation) la liberté, la flexibilité et la résilience nécessaires pour atteindre son objectif. Peu importe ce que l’avenir nous réserve. Business Agility Institute

Téléchargez gratuitement le rapport bien documenté et illustré en anglais.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Répondez à l’enquête annuelle sur l’état de l’agilité « State of Agile »

La 16ème enquête annuelle sur l’état de l’agilité est axée sur l’identification des tendances en matière d’adoption de l’Agile dans le monde entier.

Prenez quelques minutes pour répondre au court sondage « Faites entendre votre voix Agile ». La date limite pour les soumissions de sondages est le vendredi 26 août 2022. Scaled Agile rendra le rapport State of Agile disponible lorsqu’il sera publié à l’automne, et les rapports des 15 années précédentes sont disponibles en ligne.

Cliquez ici pour répondre au sondage de 33 brèves questions

 

Qu’est-ce qu’un incrément de produit ?

Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.

https://resources.scrumalliance.org/Article/product-increment par Fadi Stephan

Dans Scrum, les équipes interfonctionnelles construisent des produits et des services en cycles courts en décomposant les gros produits et services en petits morceaux appelés incréments de produits qui peuvent être réalisés par une équipe interfonctionnelle dans un court laps de temps. Le livrable de chaque sprint est un incrément de produit fonctionnel.

Guide téléchargeable gratuitement

Le Guide Scrum 2020 définit un incrément comme « une étape concrète vers l’objectif du produit. Chaque incrément s’ajoute à tous les incréments précédents et il est soigneusement vérifié, garantissant que tous les incréments fonctionnent ensemble. Pour fournir de la valeur, l’incrément doit être utilisable… Toute l’équipe Scrum est responsable de la création d’un incrément précieux et utile à chaque sprint ».

De nombreuses équipes ne comprennent pas ce concept et abordent toujours le développement de produits de la manière traditionnelle avec construire, construire, construire, puis intégrer, tester et déployer. Les équipes développent les sprints 1, 2 et 3, et ainsi de suite et dans un sprint « spécial » ultérieur, elles intègrent le tout, testent, emballent et livrent.

Dans cette approche traditionnelle, les équipes peuvent découper leur travail en fonction des fonctionnalités, des composants, des services ou des blocs de construction d’architecture tels que la construction du back-end d’abord, puis de la logique métier de niveau intermédiaire, puis de l’interface utilisateur (le front-end). Dans chaque scénario, ils atteignent la fin du sprint avec un incrément incomplet qui n’est pas utilisable. Ce n’est qu’après le sprint « spécial » beaucoup plus tardif que l’équipe fournit un incrément intégré et fonctionnel.

Dans Scrum, un incrément de produit est ce que vous avez précédemment construit, plus tout ce que vous venez de terminer dans le dernier sprint, le tout intégré, testé et prêt à être livré ou déployé.

Sans incrément de produit utilisable, les équipes de développement retardent la livraison de la valeur et manquent des opportunités d’obtenir de réels retours des utilisateurs et d’adapter le produit pour garantir la satisfaction du client. D’autre part, les versions incrémentales permettent un retour immédiat, une innovation plus rapide, une amélioration continue, une adaptation au changement et des clients plus satisfaits.

Ainsi, dans Scrum, vous générez et testez un élément dans le sprint 1, puis dans le sprint suivant, vous continuez à ajouter de nouvelles fonctionnalités intégrées et entièrement testées à cet élément. Ce que l’équipe publie après chaque sprint est souvent appelé itération. Lorsque vous construisez des choses de cette manière, de manière itérative et incrémentale, vous avez toujours une version utilisable de votre produit prête. Avec le développement itératif, vous pouvez toujours apprendre de ce que vous avez déjà, l’améliorer et y ajouter.

Vous pouvez commencer avec un squelette très mince de fonctionnalités intégrées de base de bout en bout, puis avec le temps, le rendre plus riche en fonctionnalités en fonction de l’apprentissage et des commentaires que vous obtenez de chaque sprint.

Rappelez-vous, si vous faites quelque chose qu’une seule fois, vous n’itérez pas. Si vous n’ajoutez pas à ce que vous avez déjà, vous n’incrémentez pas.

Lorsque vous commencez avec Scrum, cette approche itérative consistant à fournir un incrément de produit fonctionnel, testé, de haute qualité et potentiellement utilisable à chaque sprint semble impossible. Le simple fait d’essayer de terminer le code dans le sprint est déjà assez difficile. Comment êtes-vous censé gérer également l’exécution de tests unitaires, d’intégration et de régression au sein du même sprint ?

Y arriver prend du temps, vous devrez diviser le travail en petites tranches verticales et établir une forte culture d’ingénierie agile qui se concentre sur l’amélioration de la qualité dans chaque incrément au lieu de vérifier la qualité plus tard.

Article connexe:  How to Integrate Bug Fixes into your Product Backlog

Pour en savoir plus à ce sujet, consultez ces 8 steps to guide your team to technical excellence. Vous pouvez également renforcer votre définition de Done en utilisant cette définition de Done Canvas de Rickard Jones et John Barratt ou utiliser celle-ci dans vos rétrospectives. La clé est d’améliorer continuellement la qualité de votre incrément de produit afin que vos équipes puissent fournir un incrément de produit potentiellement utilisable à la fin de chaque sprint.

Recevez des articles et des vidéos de scrum et de pros agiles dans votre boîte de réception, y compris l’e-mail mensuel Practical Agility, abonnez-vous.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

« Scaling Scrum ain’t easy » avec Chad Beier

Voici à peu près ce que donne cette chanson en français.

Scrum Scale Away

Nous évoluons aujourd’hui

  • Nous avons organisé nos équipes dans une chaîne de valeur parce que nous devons être LEAN
  • Nous allons utiliser Scrum avec plus d’équipes pour l’agilité
  • Mais nous pouvons rencontrer des malheurs du Scrum scaling
  • Le gaspillage dans notre processus peut être exposé
  • Mais nous allons Sprinter, oh oui, nous allons Sprinter
  • Et y arriver

Nous voulons de l’agilité

  • Plusieurs équipes, une livraison fréquente
  • Une définition de l’incrément intégré fait en moins d’un mois
  • Principes fondamentaux de la mise à l’échelle, nous ne pouvons pas oublier les revues et les rétrospectives combinées de l’équipe
  • Et nous planifierons, ensemble, nous planifierons et nous nous amuserons

La mise à l’échelle de Scrum n’est pas facile

Ne vous laissez pas induire en erreur, la mise à l’échelle de Scrum n’est pas facile ! Alors, j’espère que cette petite chanson pourra vous faire sourire et restera dans votre tête 🙂

Maintenant, écoutez et appréciez 🙂 l’humour en chanson !

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Trahison ou nouvelle décision basée sur de nouvelles informations ?

Comme toute personne, vous n’aimez pas reconnaître que vous aviez tort ou que vous avez pris une mauvaise décision. Et pourtant, le plus souvent,  une mauvaise décision qui peut être corrigée vaut beaucoup mieux que l’indécision !

A new decision based on new information

https://seths.blog/2021/06/a-new-decision-based-on-new-information  par Seth Godin

Les gens ne disent pas oui ni ne changent pas d’avis parce que vous insistez.

La raison est que nous n’aimons pas admettre que nous avions tort.

Si nous décidons d’aller de l’avant, c’est parce que quelque chose a changé. Il se peut que notre situation soit différente, que l’histoire que nous nous racontons soit différente, que les temps aient changé ou que votre offre ait changé. Il se peut que nous vous fassions davantage confiance.

Qu’y-a-t-il de nouveau ?


Ceci me rappelle une discussion avec Emmanuel Le Roy qui connait très bien la Chine et la culture des affaires dans ce pays.

Il me disait qu’un contrat signé en Chine à l’instant T avec des conditions X, peut ne plus être considéré comme valide par votre client chinois si les conditions, l’environnement ou le contexte ont changé de manière significative.

Et de tels gros changements ne manquent pas en cette période agitée avec la pandémie, les problèmes d’approvisionnement en matières premières, les évolutions démographiques et révolutions sociologiques, les perturbations et catastrophes météorologiques, les guerres et conflits…

Bien sûr, dans vos projets, vous avez du mal à gérer de tels retournements de situation.

Pourtant, ils sont fréquents et pourraient parfois être tout à fait légitimes voire logiques en y réfléchissant bien.

Prenez l’exemple simple d’une fonctionnalité désirée par le client et qu’il s’est engagé auprès de vous à utiliser dès que disponible.

Cette fonctionnalité pourrait ne plus être adaptée si les circonstances ont significativement changé. Par exemple :

  • Y-a-t-il une raison logique qui puisse expliquer le changement de décision ?

    Le niveau d’expertise des utilisateurs s’est fortement réduit (départs en retraite) ou accru (formations, recrutement d’experts) pendant la période de développement de vos livrables.

  • Des collaborateurs clés ont quitté l’organisation.
  • Une nouvelle stratégie ou des priorités opérationnelles occupent à 200% les utilisateurs qui devaient tester la fonctionnalité.
  • Une nouvelle technologie rend vos livrables obsolètes avant même leur déploiement.
  • Des compétiteurs ont déjà sorti un produit ou service bien plus évolué que ce que vous développez.
  • Une réorganisation est en cours.
  • Les budgets pour accompagner le changement ont été totalement coupés fautes de revenus (perte de gros contrats, attentisme des clients en période de crise…).

Donc, les raisons justifiées peuvent être très nombreuses.

Que pouvez-vous faire?

Travaillez en cycles courts de quelques jours à quelques semaines, pas plus. Adoptez une approche adaptative et agile. Celle-ci vous permet de livrer au plus tôt des réponses aux besoins les plus critiques de vos clients. Et ceux-ci ont bien moins de chance de changer dans le très court-terme.

Récoltez les bénéfices de ces premiers livrables et itérez en reconsidérant à chaque fois l’ensemble de la situation pour en examiner les changements significatifs.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile