Catégorie : agile

Méthodes, retours d’expérience, bonnes pratiques

La controverse sur les Story Points : Quelle est leur réelle valeur ?

Le par mopertodans agileLaisser un commentaire

Voici un billet que j’ai trouvé très intéressant sur la réelle valeur des story points et les raisons pour lesquelles ils créent des conflits dans vos projets Agiles.

The Story Point Controversy par Natalie Barnes

https://resources.scrumalliance.org/Article/story-point-controversy

L’estimation du travail agile fait l’objet de débats dans les organisations depuis des années. Il existe plusieurs techniques d’estimation, mais les story points, en particulier, peuvent être un mystère pour beaucoup. Bien qu’il s’agisse d’une méthode couramment utilisée, certains peuvent questionner son efficacité. Cet article décrit le but des story points et pourquoi ils peuvent être sujets à controverse.

Qu’est-ce qu’un Story Point ?

Un story point est une unité de mesure d’une user story basée sur des facteurs tels que la complexité, l’effort, l’incertitude et le risque. Les story points peuvent être utilisés dans des approches agiles comme Scrum lors de la planification du sprint en attribuant une valeur en points à une user story.

Le story-pointing est un moyen rapide d’estimer le travail à l’aide d’outils tels que Planning Poker ou le modèle de Fibonacci. Par exemple, l’équipe peut attribuer un 1 ou un 2 à une histoire qu’elle considère comme nécessitant peu d’effort. L’objectif est d’aider les équipes Scrum à avoir un dialogue ouvert pour acquérir une compréhension commune du travail relatif à toutes les histoires utilisateurs dans l’arriéré de produit, le product backlog.

Relisez ce billet sur « pourquoi Fibonacci ? »

Toute l’équipe (ceux qui font le travail) discute des éléments et des composants impliqués dans le développement de l’histoire utilisateur et parvient à un consensus sur l’estimation en story points. Certaines équipes établissent une base de référence convenue pour l’histoire d’effort le plus faible avec le nombre de story points le plus bas. Si une user story a un nombre très élevé de points, l’équipe décompose l’histoire en histoires plus petites puis les estime.

Comment les story points sont-ils utilisés dans les sprints ?

Une fois que la planification du sprint est terminée et que l’équipe a décidé de ce à quoi elle peut s’engager dans le sprint, elle a alors son nombre total de points d’histoire, de story points, engagés. À la fin du sprint, l’équipe aura consommé tous les story points qui répondent à leur définition de terminé, done. Toutes les histoires qui ne sont pas complètes sont alors soit déplacées dans le backlog, peut-être affinées et ré-estimées, soit reportées au sprint suivant : c’est une décision d’équipe.

L’équipe répète ce processus pour chaque sprint. Au fil du temps, les membres développent leur vélocité, qui est une moyenne du nombre total de story points complétés à la fin de chaque sprint. Les story points terminés peuvent varier à chaque sprint en fonction de la capacité de l’équipe (temps disponible pour chaque sprint). Les facteurs qui pourraient avoir une incidence sur la capacité comprennent le nombre de membres de l’équipe travaillant dans le sprint en raison d’un congé personnel ou d’une maladie, d’une formation ou de conférences, d’événements imprévus, de distractions externes ou peut-être d’un sprint lourd en réunions (pensez aux réunions de département ou d’organisation).

Pourquoi les story points peuvent-ils être sujets à controverse ?

Étant donné que les story points sont une valeur nébuleuse et arbitraire, certaines organisations peuvent ne pas comprendre l’unité réelle de cette mesure des histoires utilisateur. Elles peuvent mal interpréter leur objectif, et il est difficile d’associer systématiquement les points d’histoire au délai de livraison. Prenons la vélocité, par exemple. Elle est considérée comme une mesure clé dans Agile, mais elle peut être utilisée à mauvais escient lors de la mesure de la productivité d’une équipe. Les dirigeants peuvent poser des questions sur la vélocité de l’équipe et vouloir savoir combien de points d’histoire ils achèvent à chaque sprint. Cet état d’esprit de la vélocité en tant que mesure de productivité utilisant des story points ne donne pas une bonne idée de la productivité ni du temps qu’il faudra à l’équipe pour livrer une fonctionnalité.

Disons que l’équipe prend en charge et complète 20 story points dans le sprint 1. Dans le sprint 2, ils prévoient 40 story points mais ne complètent que 30 story points. Dans le sprint 3, ils embarquent et complètent 30 points d’histoire. Cela ne signifie pas que l’équipe est plus ou moins productive de sprint en sprint. Cela fait partie du processus de planification de l’équipe pour déterminer ce qu’elle peut engager dans chaque sprint compte tenu de son expérience du dernier sprint. Étant donné que les user stories présentent différents degrés de complexité et d’incertitude, l’équipe a peut-être appris que ses estimations lors de la planification du sprint étaient trop élevées ou trop basses et s’ajuste en conséquence à chaque sprint.

La capacité de l’équipe est une autre raison pour laquelle les story points peuvent fluctuer. Peut-être qu’ils n’ont pas pu en terminer autant qu’ils l’avaient prévu en raison d’une personne malade dans l’équipe ou d’un autre événement inattendu.

Les story points sont également utilisés à mauvais escient comme métrique pour comparer une équipe à une autre. L’équipe A peut avoir une moyenne de 40 story points tandis que l’équipe B peut avoir une moyenne de 80 story points. Le management peut mal interpréter cela comme signifiant que l’équipe A est deux fois plus productive que l’équipe B. Il n’y a pas deux équipes égales. Leurs membres peuvent avoir des compétences différentes, la taille des équipes peut être différente et les définitions d’un story point peuvent varier. La comparaison des équipes nuit à leur processus d’estimation, crée des estimations gonflées et démoralise l’équipe.

Trouvez un équilibre

Il est compréhensible que les organisations aient besoin de savoir à quel point les équipes sont productives et elles ont besoin de quelque chose de tangible pour mesurer leur performance. Cependant, il est erroné de supposer que les story points et la vélocité sont des mesures d’évaluation de la productivité. Les story points sont utilisés par l’équipe Scrum à des fins de planification et ne doivent pas être considérés comme une unité de productivité par la direction. La vélocité en tant que métrique doit être utilisée par l’équipe Scrum comme point de référence pour les aider dans leur prise de décision pour les engagements de sprint.

Les apprentissages continus et l’expérience de l’équipe donnent la possibilité à l’équipe Agile d’améliorer ses estimations au fil du temps.

Grâce à l’inspection et à l’adaptation, les membres de l’équipe deviennent plus prédictifs et capables de prévoir les délais pour les fonctionnalités. Ce qui compte dans l’agilité, c’est un dialogue ouvert et productif sur le travail, la progression vers l’objectif du produit et la création fréquente de valeur pour les clients.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’est-ce qui challenge le plus vos équipes avec Scrum ?

Le par mopertodans agile, experience sharingLaisser un commentaire

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

What challenges teams most with Scrum? de Kiron Bondale

https://kbondale.wordpress.com/2022/03/20/what-challenges-teams-most-with-scrum/

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

Guide téléchargeable gratuitement

La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).

La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.

Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.

Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.

Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :

  1. Les événements/cérémonies : 31 %
  2. Les rôles : 31 %
  3. Les livrables/artefacts : 17 %
  4. Le timeboxing de 1 à 4 semaines : 20%

Cela concorde avec ce que j’ai observé.

Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.

Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.

Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.

La propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.

Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.

Et c’est pourquoi « Scrumbut » (Scrum mais…) est la valeur par défaut, pas l’exception.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

+++++++++++++++++++++++++++

Qu’est-ce que le « Scrumbut » ?

https://www.scrum.org/resources/what-scrumbut

Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.

Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.

Scrumbut – L’équipe contourne le problème plutôt que le résoudre.

ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.

Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.

Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)

Exemples de ScrumBut

  • « (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
  • « (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
  • « (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
  • « (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »

Un produit minimum viable n’est pas toujours la chose la plus précieuse pour une startup

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Certaines startup décident de ne pas construire de MVP et d’attendre que le produit soit complet et mature avant de demander à des clients potentiels de l’essayer et fournir des retours. Vous voudrez peut-être aussi envisager cette approche…

A minimum viable product is not always a startup’s most valuable player de Srikrishnan Ganesan

https://www.mindtheproduct.com/a-minimum-viable-product-is-not-always-a-startups-most-valuable-player/

Une pratique courante de lancement de startup consiste à créer d’abord un produit minimum viable (MVP). Largement considéré comme la meilleure première étape pour prouver un produit, un MVP permet à une startup de commercialiser rapidement une version initiale du produit et de solliciter au plus tôt les commentaires des clients pour l’améliorer avant de lancer le produit. Avec un MVP, une startup peut se concentrer sur la unique selling proposition du produit, la proposition de valeur qui rend le produit unique, et construire autour de celle-ci.

Rocketlane a pris un chemin différent. Nous n’avons pas construit de MVP, mais nous avons attendu que le produit soit complet et mature avant de nous engager avec des clients potentiels et de leur demander de l’essayer et de fournir des retours. Vous voudrez peut-être aussi envisager cette approche lorsque vous évaluerez diverses façons de mettre votre produit sur le marché. Dans cet article, nous allons vous expliquer pourquoi.

Pourquoi casser les codes ?

Brisez les codes !

Un MVP fonctionne bien lors de la création d’un produit entièrement nouveau pour un nouvel espace et pour des solutions ponctuelles simples pour les petits clients. Cependant, si un produit doit remplacer des produits horizontaux matures par des solutions spécialement conçues, le produit ne réussira pas en commençant en tant que MVP, d’autant plus si le produit cherche à unifier, en remplaçant un ensemble d’outils horizontaux cloisonnés.

La signification du MVP – Corriger les idées fausses les plus courantes

Les principaux piliers de notre histoire de produit sont ses capacités de « tout-en-un » et « d’unification », rassemblant les tâches, les rapports de projet, les notes de réunion, la collaboration de documents en direct et les flux de travail dans une expérience étroitement couplée.

Nous devions intégrer tous ces composants dans notre toute première version de produit et livrer un produit avec une gamme significative de fonctionnalités dès le premier jour. Pour gagner l’adhésion, un produit qui promet une expérience tout-en-un doit faire au moins 80% de ce que fait chacune des solutions horizontales. Le produit doit d’abord avoir toutes ses fonctionnalités de base en place, puis ajouter une couche d’innovation au-dessus.

Distractions et détours

Si vous créez un produit tout-en-un remplaçant plusieurs outils établis et cloisonnés, ce n’est pas non plus une bonne idée de développer et de lancer chaque module séquentiellement en tant que MVP. Si vous donnez un module ou une partie de votre solution à vos clients potentiels pour qu’ils la testent, ils vous fourniront des retours pour améliorer cette partie, ce qui pourrait vous faire perdre de vue votre solution complète.

Supposons que vous alliez plus loin et que vous lanciez une partie de votre produit en tant que MVP, alors l’ensemble du marché pourrait fournir des commentaires similaires et vous faire perdre encore plus de concentration sur votre vision plus aboutie. Vous lanceriez également un MVP qui n’est probablement pas encore au niveau en le comparant fonctionnalité par fonctionnalité avec l’une des solutions établies et cloisonnées que vous souhaitez remplacer, ce qui pourrait entraîner des critiques plus mitigées que vous ne le recevriez autrement si vous aviez attendu pour livrer votre vision complète.

Ne laissez pas un client vous entraîner dans la spirale d’une vision qui lui est propre.

Un autre risque à lancer ou engager des clients potentiels avec un module MVP de votre produit est de suivre LEUR vision de ce module.

Il pourrait finir par ressembler à d’autres produits déjà sur le marché, car ils vont comparer chaque module MVP à d’autres solutions cloisonnées qu’ils utilisent ou connaissent déjà.

Il est préférable d’allouer du temps et des ressources à l’analyse des retours des clients sur des modules et des fonctionnalités spécifiques après avoir livré la vision complète et votre différenciation.

Construire dans les délais lors de la création d’un produit

Une autre raison d’impliquer les clients potentiels tard dans la phase de développement est que les clients jugent en fonction de l’agilité et de la vitesse de production. Lors de la construction des fondations d’un produit, les clients ne percevraient peut-être pas de progrès mensuels significatifs. Plutôt que d’impliquer les clients potentiels dans les premières étapes et risquer la désillusion, il est préférable d’attendre les derniers mois avant le lancement.

Une fois que vous avez un bon produit qui est à 80% de ses fonctionnalités, il ne devrait pas être difficile d’engager des clients potentiels à l’essayer pour quelques équipes et cas d’usage, puis à itérer rapidement avec eux pour atteindre l’adéquation produit / marché cible.

La présentation d’un nouveau produit presque fini aux clients potentiels garantit également qu’ils n’ont pas besoin d’imaginer ce qu’il sera à l’avenir. Ils le voient déjà fonctionner avec succès en fonction de votre vision et peuvent mieux comprendre cette valeur.

Idéalement, les clients potentiels verraient également qu’il n’y a pas d’autre produit équivalent sur le marché ni ailleurs. Lorsqu’ils utilisent le produit en fonction de votre vision complète, ils doivent également imaginer comment cela pourrait les aider.

Gestion des risques

reconstructionImpliquer des clients potentiels tard dans la phase de développement inclut le risque de construire trop sans le valider. Le risque augmente avec l’ampleur et la complexité du produit. Même si vous avez de l’expérience dans la création de produits et que vous connaissez la direction, les demandes des clients et ce dont ils peuvent et ne peuvent pas se passer, il est préférable d’engager un panel d’examinateurs, pas nécessairement des clients potentiels, qui sont intéressés par votre vision. Dès la phase de conception, vous pouvez leur montrer des maquettes de ce que sera votre produit complet. De cette façon, vous aurez un flux de retours sur les démonstrations de maquettes même pendant la construction du produit, ce qui vous aidera à réduire les risques.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Vendre la vision

Vous devrez peut-être éduquer les investisseurs et les employés sur votre approche de produit mature. Les deux groupes peuvent être plus familiers de l’approche MVP et peuvent se demander pourquoi attendre la fin de la phase de développement pour engager des clients potentiels. Vous pouvez manager cela avec des réunions régulières où vous présentez les progrès et répondez aux questions. Vous pouvez également distribuer une note de service écrite aux investisseurs et employés, ce qui serait un bon exercice pour cristalliser votre pensée et pour les deux groupes d’avoir un document de référence.

Un produit mature est le produit le plus viable

Il y a plus d’une façon de construire un produit, en particulier pour les catégories horizontales et compétitives. Au lieu de créer un MVP, vous voudrez peut-être créer un produit avec plus de maturité et d’étendue avec quelques expériences innovantes clés qui servent de promesse différenciante (unique selling proposition) et illustrent pourquoi votre produit est le meilleur pour des cas d’utilisation spécifiques.

Si vous engagez les clients potentiels lorsque le produit semble mature, ils comprendront pourquoi ils devraient s’aligner sur votre vision et vous ne sacrifierez pas la différenciation que vous apportez sur le marché.

 

La signification de MVP – Corrigez les idées fausses les plus courantes !

Le par mopertodans agile, best practicesLaisser un commentaire

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

The Meaning of MVP – Correcting Common Misconceptions de Phil Tarnowski

https://www.mindtheproduct.com/the-meaning-of-mvp-correcting-common-misconceptions/

Chacun a sa propre interprétation de ce que signifie un produit minimum viable (MVP) pour son organisation et, bien que les spécificités d’une définition de MVP puissent varier, ce billet explore ce qu’est un MVP et ce qu’il n’est certainement pas.

Un MVP réussi est essentiel à la création d’un produit numérique réussi : C’est l’ensemble de fonctionnalités ciblées qui lance votre produit sur le marché, donne le ton pour l’avenir de votre produit et vous aide à vous guider vers des améliorations prioritaires sur la feuille de route du produit. C’est la version initiale qui met votre produit sur le marché et vous permet d’itérer, d’obtenir des retours et de vous concentrer sur l’adéquation produit / marché. Votre MVP n’est pas le strict minimum, ni le nombre maximum de fonctionnalités : Il se situe quelque part entre les deux.

Voici quelques choses qu’un MVP n’est certainement pas.

Squelette

Il y a 20 ans, votre nouveau produit numérique était souvent le premier à être commercialisé. Il y avait moins de solutions numériques qu’aujourd’hui et les attentes en matière d’expérience utilisateur étaient plus faibles. Aujourd’hui, les goûts et les attentes des consommateurs ont changé. Tout comme le marché (nous avons écrit un guide en anglais sur la façon de définir la première version de votre produit numérique).

Lorsqu’il existe des dizaines d’autres concurrents avec des offres de produits similaires, vous devez rendre votre MVP plus beau et plus intuitif que la concurrence. Il ne devrait pas seulement fonctionner. Il devrait résoudre de vrais problèmes et être élégant en le faisant.

Aujourd’hui, si les gens ne savent pas facilement comment utiliser un produit, ils passeront à autre chose. S’ils ne voient pas la valeur rapidement, ils passeront à autre chose. Pour cette raison, vous devez créer un MVP qui fait le travail rapidement et facilement.

Un seul et c’est fini (one and done)

Les produits numériques ne sont pas une construction où une seule version suffit. Peu importe l’expérience que vous avez des produits numériques, il y aura des fonctionnalités que vous manquerez ou sur lesquelles vous vous tromperez dans votre première version.

Vous obtiendrez des retours sur votre MVP, ce qui signifie que vous devrez revenir sur la conception pour améliorer le produit. Si vous pensez que votre premier jet sera parfait et n’aura pas besoin de changements, vous serez déçu. Tout comme une maison, les produits numériques nécessitent des améliorations et un entretien continus. Et, si votre MVP est apprécié par vos utilisateurs, vous devrez éventuellement « maintenir l’existant » et « ajouter une chambre d’amis » pour continuer à répondre à leurs attentes et vous assurer qu’ils reviennent.

Le produit parfait

Bien que votre MVP ne devrait pas être le simple squelette de toutes vos idées, il ne devrait pas non plus être toutes vos idées. Si vous passez trois ans à développer entièrement toutes les caractéristiques du produit de vos rêves, puis mettez ce produit sur le marché, vous serez probablement surpris du résultat. Vous constaterez peut-être que certaines fonctionnalités que vous pensiez être des aspects essentiels de votre produit sont déroutantes et inutiles pour vos utilisateurs.

Cela signifie que vous avez passé trois ans à construire quelque chose que vos utilisateurs ne veulent même pas. C’est une grosse perte de temps et d’argent.

Créez un MVP qui adresse les problèmes clés que vos utilisateurs doivent résoudre, mettez-le sur le marché et obtenez des retours. Répétez cette stratégie et itérez au fil du temps. La rétroaction et l’itération atténueront les risques. Cela vous aidera à créer un produit axé sur l’utilisateur. En abordant les problèmes par de petites améliorations incrémentales, vous vous assurerez de créer un produit précieux pour les personnes qui utilisent réellement le produit.

Bien que votre définition personnelle du MVP de votre produit puisse varier, assurez-vous que vous ne vous basez pas sur l’une de ces fausses idées.

  • Définissez votre MVP en commençant par les objectifs business à long terme et travailler à rebours.
  • Priorisez impitoyablement et évitez le piège d’avoir un MVP qui est un squelette ou exagérément musclé.
  • Et n’oubliez pas de recueillir de manière obsessionnelle des retours afin de pouvoir continuer à maintenir et à améliorer votre produit au fil du temps.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Faire – ou acheter ?

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Si déterminer quels systèmes, composants ou modules vous devriez « fabriquer » et lesquels vous devriez « acheter » reste un sujet difficile dans votre organisation informatique, quels sont les facteurs clés à considérer ?

Make – or Buy? par Michael Küsters

https://failfastmoveon.blogspot.com/2022/08/make-or-buy.html

« Agile » n’est pas une solution miracle. Le domaine est large, large et extrêmement sensible au contexte. Souvent, ce sont des nuances complexes qui font ou défont une approche. Dans ce billet, je veux partager mes expériences pour que d’autres puissent aussi apprendre.

Déterminer quels systèmes, composants ou modules nous devrions « fabriquer » et lesquels nous devrions « acheter » (par extension : utilisation à partir de l’Open Source) est un sujet difficile pour toute organisation informatique. Même lorsqu’il y a une position claire de la part de la direction du développement en faveur d’une option, ce vote est souvent formé avec une perspective myope : Les managers préfèrent « acheter » tout ce qu’ils peuvent, tandis que les développeurs hardcore préfèrent tout « faire ». Ni l’un ni l’autre n’est avisé. Mais comment décider ?

Il y a quelques facteurs clés en jeu

Facteurs Détails
Disponibilité Lorsqu’il existe une solution abordable et prête à l’emploi, « Achetez » pour éviter de réinventer la roue. Assurez-vous que prêt signifie prêt et « abordable » n’a aucune condition.
Unicité Vous devez « faire » tout ce qui est unique à votre modèle business.
Adaptabilité Lorsqu’il n’y a qu’un petit besoin de changement et de personnalisation, « Acheter » est préférable. Ne sous-estimez jamais « un petit changement ».
Durabilité « Acheter » uniquement lorsque le coût initial et le coût du cycle de vie sont inférieurs. Inclure les coûts de migration et de décommissionnement.
Compétence Si vous avez besoin de spécialistes que vous n’avez pas et que vous n’aurez pas, « Achetez » de quelqu’un qui les possède.
Dépendance Si votre entreprise doit fermer ses portes quand la solution devient indisponible, « Acheter » vous met en dépendance de votre fournisseur.
Perte sèche Vous pouvez « Acheter » pour gagner en vitesse même lorsque tous les indicateurs favorisent « Faire », si – et seulement si – vous êtes prêt à passer en perte sèche tout ce qui est investi dans la solution « Acheter ».
Choisissez judicieusement : Les réponses ne sont souvent pas si évidentes qu’elles en ont l’air.

Et vous, comment vous y prenez-vous pour répondre à la question : Faire ou acheter ?

Agile Kata : C’est quoi ? Ressources gratuites et opportunités d’aller plus loin.

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Qu’est-ce que tout ce buzz autour d’Agile Kata ?  Voici de nombreuses ressources gratuites et des opportunités d’en apprendre davantage.

What is the buzz around the Agile Kata?   Free Resources and Learning Opportunities par Joe Krebs

https://www.agilealliance.org/practicing-business-agility-with-the-agile-kata/

Agile Kata est-il nouveau ?

Livres sur Amazon

Les deux communautés, Agile et Kata, ne sont pas nouvelles. Ils ont des décennies d’expérience et de preuves de succès. Il y a des années, lorsque j’ai commencé à chercher de meilleures façons de diriger les transformations agiles, je suis tombé sur le Toyota Kata et j’ai construit un pont entre ces approches. Vous pourriez dire que le Agile Kata en lui-même est nouveau, mais les utilisateurs exploitent la richesse des expériences et des succès de deux communautés. L’intersection où Agile et Kata se rencontrent est nouvelle. Je l’ai nommé « Agile Kata » pour la rendre plus facile à référencer et à identifier.

À quoi sert l’Agile Kata ? 

Agile Kata est un modèle pour aider les organisations à créer et à accroître l’agilité de l’entreprise. Comparativement, Agile Kata est appliqué au niveau organisationnel comme Scrum et Kanban le sont au niveau de l’équipe. Vous pouvez utiliser Agile Kata pour piloter une transformation agile, créer une culture agile ou conduire un changement organisationnel.

Si vous cherchez de meilleurs moyens d’augmenter l’agilité de votre entreprise avec Agile Kata

Burnout des développeurs : 3 façons de l’éviter au sein de votre équipe informatique

Le par mopertodans agile, best practicesLaisser un commentaire

L’épuisement professionnel guette les équipes de développement, en particulier avec les approches Agile. Voici trois stratégies pour le prévenir !

Developer burnout: 3 ways to avoid it on your IT team par  Christine Spang

https://enterprisersproject.com/article/2022/8/avoid-developer-burnout

Le développement de logiciels est en constante évolution. En conséquence, les développeurs modernes peuvent se sentir « toujours en service », avec peu de temps d’arrêt pour se recharger. Une étude de Haystack a révélé que 83% des développeurs de logiciels souffrent d’épuisement professionnel.

Ce n’est un secret pour personne que la pandémie a augmenté les sentiments d’épuisement professionnel, mais d’autres variables exacerbent également ces ressentis. Les principales raisons citées par les développeurs dans l’étude pour l’épuisement professionnel comprenaient une charge de travail élevée (47%), des processus inefficaces (31%) et des objectifs ou des cibles peu clairs (29%).

L’expérience du développeur (DevEx) fait référence aux interactions et aux sentiments globaux qu’un développeur éprouve lorsqu’il travaille à la réalisation d’un objectif. Ceci peut jouer un rôle essentiel dans l’identification et la conservation d’expériences positives pour les développeurs et les utilisateurs finaux. Une expérience de développement sans friction qui simplifie les processus et aide à prévenir l’épuisement des développeurs est vitale.

[ Lisez aussi Burnout: 3 steps to prevent it on your team. ]

La façon dont le travail est structuré dans un environnement distant est un facteur important dans le développement d’une culture de travail positive qui permet aux entreprises de retenir et d’attirer des employés de grande valeur. L’autonomie et un certain degré d’autorité dans le temps et l’emplacement peuvent aider à restaurer un sentiment de contrôle.

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

3 conseils pour prévenir l’épuisement professionnel des développeurs

Voici trois solutions pour vous aider à prévenir l’épuisement professionnel au sein de votre équipe de développeurs :

#1 – Automatisez les processus simples

De nos jours, l’automatisation est un élément clé dans toute industrie, de l’IA avancée et de l’apprentissage automatique à la simple utilisation de logiciels pour effectuer des tâches plus efficacement.

Les développeurs sont devenus partie intégrante de tous les types de travail dans les organisations. Lorsque vous managez une équipe de développeurs, aidez à prévenir l’épuisement professionnel en leur suggérant les moyens les plus efficaces et les plus motivants de gérer leurs listes de tâches.

Les développeurs doivent disposer de processus rapides et structurés pour effectuer les tâches. Par exemple, l’utilisation d’outils et de technologies pour simplifier le travail complexe est une bonne pratique pour supprimer le travail répétitif et rendre la livraison du code plus rapide et plus facile. Des processus longs et laborieux embourbent les développeurs et peuvent retarder ou empêcher la satisfaction de livrer quelque chose.

Prenez le pouls de vos développeurs grâce à des enquêtes et à des réunions 1-1, et recherchez activement d’autres moyens de recueillir des informations sur ce que l’équipe pense de sa charge de travail et des processus qu’elle souhaite automatiser.

L’automatisation offre également aux développeurs plus de bande passante. En automatisant des tâches administratives simples et l’accès à de riches données de communication, et en corrigeant les processus stagnants, vous pouvez donner à vos développeurs plus de temps pour innover plutôt que de se laisser prendre par des tâches de base qui consomment beaucoup de temps.

#2 – Bâtissez une culture axée sur les résultats

Pour créer une culture axée sur les résultats, commencez par fixer des objectifs clairs. Une fois ces objectifs en place, donnez à vos développeurs un accès complet à tous les outils disponibles et l’autonomie nécessaire pour manager leurs processus afin de les atteindre.

Un horaire de travail flexible peut permettre une culture axée sur les résultats qui limite le stress du monde moderne et augmente la productivité. La plupart des emplois de développeur n’exigent pas que les travailleurs soient dans un bureau tout le temps, alors pourquoi ne pas donner de la flexibilité à votre équipe ?

Les développeurs n’en font pas nécessairement plus en restant assis sur une chaise plus longtemps.

Les employés apprécient de pouvoir définir leurs horaires. Avoir le contrôle de leur temps et de leur lieu de travail permet des sentiments d’autonomie. Gardez à l’esprit que le travail basé sur la connaissance et la réflexion ne s’alignent pas nécessairement avec huit heures de production : Les développeurs n’en font pas nécessairement plus en restant assis sur une chaise plus longtemps.

#3 – Prévenez le stress à long terme qui mène à l’épuisement professionnel

Bien que le surmenage ne soit pas toujours le problème, il contribue à l’épuisement professionnel. En tant que leader, il est essentiel de donner l’exemple et de montrer qu’il est normal de prendre du temps pour se ressourcer.

En savoir plus sur le leadership

Conformément à l’état d’esprit axé sur les résultats mentionné ci-dessus, l’industrie s’éloigne d’horaires stricts de 9h à 17h. Selon le rapport Gartner 2021 Digital Worker Experience Survey, 43 % des répondants ont déclaré que les horaires de travail flexibles les aidaient à être plus productifs.

Les développeurs devraient être en mesure de mettre en cohérence leurs besoins personnels avec ceux de leur travail. Démontrer cela en tant que leader crée un précédent qui aide votre équipe à trouver un équilibre dans sa propre vie.

La prévention de l’épuisement professionnel maintient votre équipe en bonne santé physique et mentale et, en fin de compte, améliore la productivité. Cette productivité conduit à une plus grande innovation et aide l’entreprise à se développer à mesure que votre équipe se concentre sur la création d’expériences positives pour les utilisateurs finaux.

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

Le par mopertodans agile, experience sharingLaisser un commentaire

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

Le par mopertodans agileLaisser un commentaire

#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

Le par mopertodans agile, best practicesLaisser un commentaire

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

Le par mopertodans agile, leadership, pmo et portofolio, pointeurs utilesLaisser un commentaire

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

Le par mopertodans agile, pointeurs utilesLaisser un commentaire

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 par mopertodans agile, pointeurs utilesLaisser un commentaire

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 »

Le par mopertodans agileLaisser un commentaire

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 ?

Le par mopertodans agile1 commentaire

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

Le par mopertodans agileLaisser un commentaire
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 ?

Le par mopertodans agile, experience sharingLaisser un commentaire

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

Téléchargez votre copie du guide PM² – Agile de la Commission européenne

Le par mopertodans agile, pointeurs utiles1 commentaire

Ce guide présente PM²-Agile, l’extension agile de la méthodologie PM².

Les personnes qui mettent en œuvre les approches Agile font face à de nombreux défis :

  • Téléchargez ce guide

    Être agile tout en respectant les processus, structures et règles de l’entreprise, y compris les règles de gouvernance informatique et budgétaires, les structures des programmes, l’architecture et les besoins en interopérabilité ;

  • Appliquer de manière cohérente des approches agiles dans l’ensemble de l’organisation.
  • Être Agile dans un environnement hybride où des approches prédictives sont également utilisées.

Le guide fournit :

  • Un vocabulaire commun pour faciliter la communication entre les équipes de projet et au sein des équipes de projet.
  • Le modèle PM²-Agile.
  • Les valeurs et principes agiles.
  • Les bases des pratiques agiles.
  • Des informations sommaires sur certains outils et techniques agiles.
    • La description d’un ensemble d’artefacts recommandés pour la documentation et les rapports d’avancement concernant les activités gérées avec des principes agiles.
    • Des références et suggestions de lectures complémentaires sur des sujets liés à la méthode Agile.

Le guide PM²-Agile répond principalement aux besoins des projets de développement de logiciels mais les approches agiles sont aussi fréquemment appliquées avec succès en dehors de cet environnement.

PM²-Agile ne remplace aucune partie de PM². Il élargit PM² en proposant des méthodes, des outils et des techniques spécifiques qui aident les équipes à adopter et à utiliser les principes Agile et Lean dans le cadre de leurs projets PM².

European Commission, Directorate-General for Informatics, The PM²-Agile guide 3.0.1, Publications Office, 2021, https://data.europa.eu/doi/10.2799/162784

Titre : Guide PM²-Agile 3.0.1

Édition : Guide PM²-Agile v.3.0.1, juillet 2021 © Union européenne, 2022

Produit par : Commission européenne, DIGIT.B4.001 Élaboration et sourçage de projet

Publié par : Commission européenne, DIGIT, Centre d’Excellence PM² (CoEPM²)

© Union européenne, 2022

« 12 mythes sur l’Agilité » par Jean-Yves Klein

Le par mopertodans agile1 commentaire

L’Agilité est souvent fantasmée, parfois usurpée et trop fréquemment mal comprise.

Voici 12 mythes à garder à l’esprit pour éviter de se tromper quand on envisage d’adopter une approche Agile.

1.   L’agilité est une mode

Faux car Scrum a été conçu en 1995, le manifeste agile a été écrit en 2001… Donc on ne peut pas dire que « c’est une mode ».

L’agilité est ancrée, durablement. Le 15ème état de l’Art sur l’agilité rappelle que 94% des entreprises ayant une composante de développement logiciel pratiquent l’agilité, et 65% de ces entreprises ont plus de 3 ans de pratique (source 15th State of Agile Report, Digital.ai)

2.   L’Agilité, ce n’est que pour l’IT.

Faux : Même si les outils et méthodes utilisent souvent le vocabulaire de l’IT, j’ai personnellement eu l’occasion de voir que c’était aussi parfaitement adapté à d’autres projets de l’entreprise (Marketing, R&D, Juridique, Sécurité, Mécanique, Électronique…).

3.   L’Agilité, c’est la meilleure façon de faire pour tout le monde, tout le temps.

Faux : L’agilité n’est pas la réponse à tout. Si vous êtes certain de votre périmètre, de votre techno, que les attentes des parties prenantes ne changeront jamais… alors ne le faites pas en agile.

Par contre, si l’un de ces domaines pourrait être amené à évoluer (combien de fois vos parties prenantes ont-elles changé d’avis sur les 2 dernières années ?), alors faites-le en Agile.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

4.   L’Agilité, c’est moins cher.

Faux : L’agilité, entrainant un certain nombre de réunions supplémentaires, décomptées du temps de réalisation, va coûter plus cher que le même projet en cycle en V.

Rapport téléchargeable gratuitement en ligne

Cependant, un projet en cycle en V a beaucoup plus de chance de se « planter ». 29% des projets utilisant le cycle en V se sont plantés, contre 9% des projets agiles. (Source le Chaos report de 2015).

Si on prend en compte les rallonges, avenants… qui sont traditionnellement le lot des projets en cycle en V, il devient évident qu’un portefeuille de projets, menés en Agile coûtera moins cher que ce même portefeuille de projet menés en cycle en V.

Pour creuser le sujet, regardez les Options Réelles de Claus Hirzmann.

C’est comme les trous dans le fromage : Plus il y a de trous, moins il y a de fromage et plus il y a de fromage, plus il y a de trous…

5.   L’agilité peut être appliquée de la même façon dans toute l’entreprise

« One size fits all » est un gros mensonge. Portons-nous tous la même paire de chaussures ?

Les pratiques agiles doivent s’adapter aux équipes, aux métiers, aux projets…

Si vous changez l’un de ces composants, il vous faudra revoir le dispositif.

Une partie de Disciplined Agile a été construit dans ce but : Vous fournir le meilleur outil en fonction de votre problématique, de la complexité de votre domaine, de la complexité de votre solution, de la taille de vos équipes, de leur maturité… (cf. Disciplined Agile Browser).

6.   L’Agilité, c’est facile

L’Agilité, c’est simple à comprendre… ça ressemble tellement à du « bon sens ».

Mais il faut comprendre ce qui est écrit en creux
  • Si on demande aux équipes d’être autonomes, auto organisées, cela implique que l’on supprime les « petits chefs » qui regardent leur montre quand quelqu’un part avant 18h…
  • Si on demande aux équipes de construire de la valeur, cela implique qu’elles aient accès aux utilisateurs (et non plus l’homme qui a vu l’homme qui a vu l’homme… qui a vu l’ours), qu’elles puissent re-prioriser le Backlog sans redemander la validation d’un comité de pilotage « Copil N+x »…
  • Si on demande aux équipes d’être efficaces, cela implique que ce qui a été produit va être mis dans les mains des utilisateurs pour recueillir leur feedback, à chaque itération (et non pas tous les 3 mois…)
  • Si on se permet des changements dans la méthodologie (« On fait du Scrum, mais… » ), on se retrouve trop souvent à avoir supprimé tout ce qui était compliqué, mais essentiel.

Cette liste n’est pas exhaustive. J’ai repris le schéma du ministère de la défense américain à propos de « Agile bullshit« .

L’Agilité demande de vrais changements « autour » de l’équipe. S’ils n’ont pas été entrepris, les équipes vont se décourager. Je suis convaincu que l’Agilité doit être conduite de façon sérieuse, voire disciplinée (cf. Disciplined Agile).

7.   L’agilité, c’est mettre Scrum partout

Scrum est l’un des Framework les plus utilisés (66% des cas d’après 15th State of Agile Report).

Mais Scrum n’est pas la seule réponse, beaucoup d’autres outils et méthodes sont aussi là pour répondre et aider l’organisation (cf. Disciplined Agile Browser, et The Agile Landscape, Christophe Webb).

8.   Passer à l’échelle, c’est rajouter des équipes agiles partout

téléchargez gratuitement le guide complet de 19 pages

Passer à l’échelle requiert une analyse de l’organisation actuelle et de comprendre ses faiblesses.

L’organisation à l’échelle devra avoir mis en place des solutions pour éviter de reproduire les problèmes de l’ancienne organisation.

Il est important de garder le lien avec les parties prenantes, ainsi qu’avec la vision du produit (et pour qui on travaille).

9.   Passer à l’échelle, c’est mettre en place SAFe.

Seulement 37% des entreprises ayant mis en place une organisation agile à l’échelle utilisent SAFe (cf. 15th State of Agile Report).

Visitez le site SAFe

10.  L’Agilité, c’est le Chaos. On a sacrifié la prédictibilité pour la réactivité.

Trop souvent, en acceptant un changement demandé par le client, on oublie de lui rappeler les conséquences. On lui fait plaisir sur le moment, mais quand il faudra faire le bilan de 15 changements d’avis sur les 3 derniers mois, celui qui va payer la note ne sera pas content…

L’Agilité requiert une plus grande rigueur et discipline que sur un cycle en V car les conséquences sont visibles immédiatement (cf. PM2 de la commission européenne) d’où le nom de « Disciplined Agile ».

11. L’Agilité, c’est faire 2 fois plus vite pour 2 fois moins de temps

Jeff Sutherland, Creator of SCRUM

Même si Jeff Sutherland le promet dans son livre (“Scrum, The art of doing twice the work in half the time”), il est important de se rappeler que le père Noël ne vient qu’une fois par an…(et vous pouvez lui demander ce livre).

« 95% des performances d’un système viennent de la conception du système, et non des capacités des personnes qui travaillent dans le système » W.E. Deming.

J’ai un petit Serious Game pour le mettre en pratique, créé par Henrik Kniberg et mis à jour par Alfred Almendra.

Donc oui, on peut toujours améliorer les choses, tout en étant réaliste.

12. On peut faire une transformation Agile en 6 mois

Non. Celles auxquelles j’ai participé ont toutes demandé bien plus de 6 mois. Tout le monde ne travaille pas dans la Silicon Valley… Même Mc Kinsey le dit et parle de 1 à 3 ans.

Jean-Yves KLEIN, Certifié PMP, DASSM, PMS1, SAFe

Jean-Yves Klein

Ancien développeur, passé directeur de projet puis responsable d’agence, Jean Yves a basculé en 2008 sur la mise en place d’équipes agiles.
Coach Agile, il a accompagné plusieurs entreprises dans la mise en place d’organisations guidées par l’efficacité.
Il est intervenu en électronique, mécanique, marketing, et bien sûr en IT.
Il est membre du PMI Rhône Alpes, et formateur Disciplined Agile.
Il est aussi président d’OpenSeriousGame car c’est l’une des meilleures méthodes pour faire passer un message, que de le faire vivre. Il a créé Lego4DevOps, Lego4SAFe, DevSecOps.

Qu’est-ce qui s’est bien passé ?

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Vous vous demandez quand et où le projet aurait pu mieux faire et oubliez trop souvent de voir tout ce qui a bien marché. Essayez de faire l’inverse, commencez par ce qui a fonctionné.

What Went Right?

https://samsilverstein.com/what-went-right/ par Sam Silverstein

Vous arrive-t-il de vous poser constamment cette question ?

Ou, comme c’est si souvent le cas, vous demandez-vous ce qui a mal tourné ?

Vivez-vous dans les mentalités responsables de l’abondance, de la gratitude et du respect ou vous retrouvez-vous à glisser dans les mentalités négatives de pénurie, des droits qui vous sont dus et du mépris ?

La responsabilisation n’est pas une façon de faire. La responsabilisation est une façon de penser. Et l’état d’esprit que vous choisissez motive ces pensées. Ces pensées, à leur tour, guident vos actions. Vos actions, comme vous pouvez le voir, sont le résultat direct des mentalités que vous choisissez en premier lieu. Dans la vie et dans les affaires, vous pouvez choisir vos pensées et diriger vos résultats.

Maintenant, je ne veux pas une seconde que vous pensiez que je ne glisse jamais vers un état d’esprit de pénurie. Cela m’arrive. Mais nous devons être en mesure de reconnaître cela lorsque cela se produit et de revenir rapidement à l’état d’esprit responsable.

Faites attention aux résultats que vous obtenez et aux interactions que vous avez avec les gens. Si vos résultats ne correspondent pas à ce que vous voulez, évaluez votre état d’esprit, vos croyances, ajustez-vous, puis regardez ce qu’il advient de vos résultats.

Ce n’est pas pour rien que les rétrospectives chères aux Agilistes (tout autant que les leçons apprises aux managers de projets) nous incitent à regarder ce qui a bien marché, quels ont été les points négatifs et d’en tirer des enseignements pour une amélioration continue lors de prochains Sprint ou version de nos livrables.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile