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

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.

L’anti-modèle Agile dit du « Planning Tetris » se manifeste souvent avec l’approche SAFe

La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. 

The « Planning Tetris » Antipattern

https://failfastmoveon.blogspot.com/2021/11/the-planning-tetris-antipattern.html par Michael Küsters

 Nous devons utiliser tous nos Story Points

Ceci est un dysfonctionnement courant dans de nombreuses équipes Scrum, et en particulier dans les Agile Release Trains de SAFe où les équipes opèrent sur un horizon de planification de 3 à 5 sprints. Il en résulte un antipattern souvent appelé « Planification Tetris. » C’est extrêmement nocif, et voici pourquoi.

Bien que le plan de fonctionnalités ci-dessus semble être parfaitement optimisé, la réalité semble souvent différente : tous les articles génèrent de la valeur plus tard qu’ils le  pourraient potentiellement; à un coût plus élevé, en demandant plus de temps et avec une efficacité moindre !

Accumulation des travaux en cours

La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. C’est efficace sur le plan des ressources (c-à-d. maximiser l’utilisation du temps disponible), mais pas du débit (c-à-d. maximiser le rythme auquel la valeur est générée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Cela mène à une augmentation du travail en cours, ce qui est un problème pour de multiples raisons

Déni de valeur

Tout comme dans l’exemple de diagramme ci-dessus, « Fonctionnalité 1 » et « Fonctionnalité 2 » pourraient chacun être finis en un seul Sprint. Et encore, Fonctionnalité 1 ne fournit aucune valeur dans Sprint 1, et Fonctionnalité 2 n’a aucune valeur dans Sprint 2. Donc, nous perdons 1 Sprint de mise sur le marché sur Fonctionnalité 1 (notre plus haute priorité) – et sur Fonctionnalité 2 aussi :

Un exemple parfait de la façon dont l’utilisation optimale de l’équipe fait arriver la valeur plus tard !

Perte d’argent

Imaginez maintenant que chaque fonctionnalité coûte moins cher qu’elle ne le vaut (ce qu’elle devrait, sinon elle ne vaudrait pas la peine d’être développée) et vous voyez que l’efficacité « économisée » d’avoir travaillé sur les caractéristiques 3 et 4 avant de terminer la caractéristique 1 coûte à l’entreprise plus d’argent que les bénéfices cumulés.

Perte d’efficacité

Vous pouvez argumenter que « différentes personnes travaillent sur les fonctionnalités, donc il n’y a pas de multitâche. »

Oui, et Non. Que se passe-t-il vraiment ?

Le Sprint Planning du Sprint 1 doit discuter de 3 caractéristiques : 1, 3 et 4. Cela signifie que toute l’équipe discute de trois sujets différents (dont aucun ne sera livré dans ce Sprint). La même chose se produit dans les réunions journalières et les revues. Et peut-être aussi au niveau du code source. Les interférences des fonctionnalités peuvent également alourdir la complexité de la configuration technique, des processus de déploiement et autres.

L’équipe devient plus lente, donc moins efficace.

Ajout de risques inutiles

Livre sur Amazon

Dans les statistiques, il y a un phénomène appelé « la probabilité élevée d’événements à faible probabilité ». Permettez-moi d’expliquer brièvement : Il y a une quantité infinie d’événements presque totalement improbables, mais malheureusement, l’infini élevé divisé par l’infini faible est encore un nombre proche de : Quelque chose va arriver. Vous ne savez tout simplement pas quoi, ni quand, alors vous ne pouvez pas vous préparer ni en atténuer les effets. Comme vous ne savez pas quel aspect de votre plan sera touché lorsqu’un risque frappe, vous serez toujours pris par surprise.

En quoi est-ce un plus gros problème dans la planification de Tetris que dans la livraison séquentielle ?

Effet massif de répercussions en chaine

Certains effets « dominos » sont quasiment impossibles à arrêter.

Lorsque vous travaillez sur un sujet et qu’un événement touche toute votre équipe, vous avez à communiquer sur un problème. Lorsque la même chose se produit alors que vous travaillez sur de multiples sujets, tous sont touchés, et vous générez un effet de répercussion en chaine beaucoup plus fort.

Mesures d’atténuation complexes

Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !

Conséquences chaotiques

L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.

Préparez vous à l’échec

Relisez ce billet sur la Loi de Parkinson

Il y a la Loi de Parkinson – « Le travail s’étend toujours pour remplir la quantité de temps disponible« . C’est souvent utilisé comme argument pour commencer un autre sujet, parce qu’il arrête le sur-investissement et garde les gens concentrés.

Mais il y a aussi la Loi des moyennes : « Les plans basés sur les moyennes échouent la moitié du temps. »

Cette dernière fait de la planification Tetris une approche suicidaire d’un point de vue business : Elle enclenche un cercle vicieux.

Échec prévisible

Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…

Des estimations prudentes

Les équipes doivent insérer des zones tampons dans leurs estimations de fonctionnalités afin de réduire la probabilité de défaillance. Lorsqu’un plan Tetris s’étend sur plusieurs sprints, il se peut que certaines fonctionnalités ne soient pas « prêtes » à être implémentées pendant le sprint lorsque la marge de manœuvre serait disponible – donc nous nous retrouvons avec la Loi de Parkinson, les estimations gonflées ne réduisent pas les probabilités d’échec.

Un débit en baisse

À ce stade, La loi de Parkinson se combine avec le défaut des moyennes pour mettre l’équipe KO. Indépendamment de la manière conservatrice dont les estimations ont été construites, l’équipe finira toujours par échouer la moitié du temps. La conséquence est que le débit business continue de diminuer (Jusqu’à un fond intéressant : quand un Sprint ne contient qu’une seule caractéristique !)

Étranglement de l’équipe

Examinons maintenant l’impact psychologique de la Planification Tetris.

Pas d’espace pour la créativité

Je n’ai jamais vu une organisation où le marketing produits était heureux que les développeurs ajoutent des « espaces créatifs » dans un plan Tetris. Il s’agit de lancer fonctionnalité, après fonctionnalité, après fonctionnalité, sans pause, sans pause. Lorsqu’une fonctionnalité est terminée, une autre est déjà en cours. Il n’y a pas de place pour la créativité.

Pas d’espace pour la croissance des personnes

Le seul résultat opérationnel pertinent dans les plans Tetris est généralement la valeur opérationnelle fournie.

Il ne tient pas compte du fait que les développeurs sont le capital humain de l’organisation, et leur croissance accroît la capacité de l’organisation à offrir de la valeur.

Surtout dans notre industrie technologique en rapide évolution, ne pas croître équivaut à reculer jusqu’à ce que finalement, l’équipe ne soit plus compétitive.

Pas de place pour l’amélioration

Je conseille souvent que les développeurs devraient prendre un certain temps pour regarder le travail « fait » pour réfléchir à comment il aurait pu être mieux fait, et de transformer cette meilleure façon en action. Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours  une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !

Maintenant… et alors ?

Le fait que la planification Tetris soit une mauvaise idée devrait être évident.

Mais alors, quelle est la meilleure façon ? pouvez-vous vous demander.

Cela semble incroyablement simpliste, parce que c’est aussi simple que cela.

  1. Livre sur Amazon

    Réduisez la quantité de fonctionnalités sur lesquelles l’équipe travaille en parallèle au minimum absolu. Cela minimise le rayon de l’explosion.

  2.  Au lieu d’avoir des gens en parallèle de multiples sujets, laissez les gens « inefficaces », « peu qualifiés » prendre des parties plus faciles du travail pour améliorer leur capacité. Cela réduit l’impact des événements à faible probabilité et donne à chacun de l’air pour respirer.
  3.  Donnez du mou dans les sprints. La résilience acquise peut absorber l’impact. Elle réduit également le besoin d’estimations gonflées, contre la loi de Parkinson et le défaut des moyennes. Elle donne également aux gens de l’air pour respirer.
  4. Tirez : Soyez d’accord sur l’approche Pull-Forward. Lorsque l’équipe se sent sous chargée, elle peut toujours ramener les sujets futurs dans ces temps d’inactivité. Personne ne se plaint quand un sujet est fini à l’avance, tout le monde se plaint quand quelque chose arrive en retard. Le Pull-Forward n’a pas d’effets de répercussions en chaine ou de conséquences chaotiques.

Ok, trop de mots, alors pour faire court

  1. Séquencez.
  2. Donnez du mou.
  3. Tirez.
Tous les problèmes mentionnés dans cet article sont alors résolus.
Visitez le site de notre partenaire Virage Group

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

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

Unravelling PI Planning

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

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

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

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

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

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

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

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

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

Visitez le site SAFe

PI Planning

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

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

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

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

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

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

Productions du PI Planning

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

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

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

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

Rôles Principaux dans le PI Planning

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

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

Épilogue

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

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

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

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

Et c’est une bonne chose!

Anshuman Singh, Product Manager, SwiftEASe

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

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

2021 Gartner Market Guide for Enterprise Agile Frameworks

Obtenez votre exemplaire gratuit dès aujourd’hui !

Le Project Management Institute a été reconnu comme fournisseur représentatif dans le Gartner Market Guide de 2021.

Obtenez votre exemplaire du rapport Gartner Market Guide for Enterprise Agile Frameworks 2021 pour en savoir plus sur le marché agile.

© 2021 Gartner, Inc. and/or its affiliates.

Vous pouvez utiliser ce Guide pour mieux comprendre quel est le statut des approches Agiles et identifier qui peut le mieux vous aider à vous former.

Lesquelles de ces approches Agiles s’harmoniseront le mieux avec vos plans futurs et votre situation actuelle ?
CertYou est partenaire de DantotsuPM

Que lisiez-vous en Juin 2021 sur le blog du management de projet DantotsuPM.com ?

Ces 3 billets qui retinrent l’attention de nombreuses et nombreux PMs et Agilistes.

7 choses qu’un leader ne devrait jamais faire dans ses courriers électroniques

Avant que vous ne répondiez à cette saga surchauffée de courriels, voici comment éviter certaines bévues dans l’étiquette entourant l’usage de la messagerie électronique qui seraient potentiellement embarrassantes ou dommageables.

QRP est partenaire de DantotsuPM

38 Biais Cognitifs et leurs impacts sur les managers de projets et leurs équipes

Avec les 27 déjà décrits en 2019-2020, vous voici équipés de davantage de connaissances sur 65 biais cognitifs.

FDF est partenaire de DantotsuPM

Un tour de SAFe en 5 minutes !

Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.

CertYou est partenaire de DantotsuPM

Trop de règles rendent l’agilité impossible

Combien de règles devez-vous suivre ?

Too many rules makes agility impossible

https://hennyportman.wordpress.com/2020/04/01/too-many-rules-makes-agility-impossible/ par Henny Portman

Un des principes du Manifeste Agile est la Simplicité — l’art de maximiser le travail non fait — est essentielle. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.

Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?

Avez-vous jamais joué au jeu de Go ?

Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.

CSP est partenaire de DantotsuPM
J’ai lu une histoire à propos des garderies d’enfants en Israël.

Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.

Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».

Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trains grâce aux règles SAFe ou malgré elles ?

Structure agile ou façon de travailler Règles
Manifeste agile 4 valeurs, 12 principes
Scrum 3 rôles, 5 cérémonies, 3 artefacts, 5 valeurs
Nexus 6 rôles, 5 cérémonies (équipe), 6 événements (Nexus), 7 artefacts, 5 valeurs
LeSS 5 rôles, 5 cérémonies (équipe), 3 événements (équipe d’équipes), 4 artefacts, 28 règles (LeSS), 12 règles (LeSS énorme)
AgilePM 13 rôles, 6 processus, 15 produits, 8 principes
PRINCE2 Agile 9 rôles, 7 processus, 7 thèmes, 7 principes, 5 comportements, 26 produits
Disciplined Agile Delivery 11 rôles, 3 phases, 6 cycles de livraison, 7 principes
SAFe 12 rôles, 6 cérémonies (équipe), 7 événements (programme), 2 cérémonies (grandes solutions), 7 artefacts, 4 valeurs, 10 principes
CertYou est partenaire de DantotsuPM

Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !

Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : “L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”

Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.

Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.

 

Un tour de SAFe en 5 minutes !

Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.

Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.

Pour en savoir plus sur SAFe, consultez le site scaledagileframework.com et la formation SAFe sur scaledagile.com.

CertYou est partenaire de DantotsuPM

Quoi de neuf dans SAFe 5 ? SAFe pour le développement de matériel !

Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée.

What’s new in SAFe 5? SAFe for Hardware Development!

https://www.scaledagileframework.com/blog/whats-new-in-safe-5-safe-for-hardware-development/ par Harry Koehnemann

Beaucoup d’entre nous travaillent dans les organisations qui essayent d’améliorer la livraison de produit dans  des solutions qui comprennent du matériel. Pendant que SAFe offre aux développeurs de logiciels une myriade de bonnes pratiques pour accélérer l’exécution, nous n’avons eu que peu à dire aux développeurs de matériels. Jusqu’à présent.

Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée. La communauté du logiciel a inventé de nouvelles pratiques comme les méthodes Agiles et l’intégration continue, qui a mené à des innovations technologiques comme des micro-services, les plateformes et l’infrastructure « as-a-service » et le management d’interfaces pour les soutenir.

Aujourd’hui, le business exige la livraison toujours plus rapide de matériel de haute qualité et de systèmes et sous-systèmes mécaniques. La pression est maintenant sur le développement de matériel pour découvrir que de nouvelles pratiques LEAN et Agile favorisent une livraison plus rapide de solutions.

Nous voyons maintenant que des pratiques Agiles commencent à émerger dans l’industrie du matériel. Les organisations utilisent avec succès des jumeaux numériques, l’impression 3D, le Circuit Imprimé (PCB) en un jour, les Développements Pilotés par les Tests dans la conception CAO, l’intégration continue et d’autres pratiques et technologies qui accélèrent la livraison de produit et en améliorent la qualité.

La dernière mise à jour de SAFe 5 inclut de nouveaux conseils pour ceux qui font face à ces défis particuliers.

L’article Applying SAFe to Hardware Development décrit 6 principes critiques pour aider les ingénieurs de matériels à mieux comprendre comment le développement LEAN-Agile s’applique à leur contexte.

Ces principes seront immédiatement reconnaissables pour ceux qui sont familiers de SAFe

  1. Organisez autour de la valeur pour le développement de matériel
  2. Embrassez la variabilité et préservez des options
  3. Construisez de manière incrémentale, intégrez fréquemment
  4. Concevez pour le changement
  5. Exécutez le travail par petits lots
  6. Intégrez la qualité dans la construction de matériel

Il est grand temps que LEAN et Agile traverse le fossé pour aider le matériel et les constructeurs de systèmes cyber-physiques à répondre aux demandes de l’ère digitale. Vous pouvez lire l’article complet en anglais ici.

© Scaled Agile, Inc.

CertYou est partenaire de DantotsuPM

Agile SAFe peut-il s’interfacer avec « Waterfall » ?

Le manque de transparence cause des malentendus et des conflits. Générer de la transparence demandes des efforts spécifiques.

Can Agile (SAFe) Be Interfaced With Waterfall? – Transparency

https://tcagley.wordpress.com/2019/01/24/interfacing-agile-safe-be-interfaced-with-waterfall-transparency/ par Thomas Cagley

Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).

Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets

Le manque de transparence cause des malentendus et des conflits.

Cependant, générer de la transparence a un coût.

Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.

Plusieurs des techniques les plus communes pour générer de la transparence

#1 – Le Contrat

Spécifiez ce qui peut et doit être partagé dans le contrat.  Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre.  Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu).  Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.

#2 – Un Plan construit conjointement

Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres.  La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur  des risques et communiquer les dépendances en temps réel.

Matchware est partenaire de DantotsuPM

#3 – Des Cérémonies communes

Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies).  Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives.  Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.

#4 – Des Ateliers de mûrissement des exigences et de design

travail d'équipeCollecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.

#5 – Des Modèles de design

L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.

Facile ET difficile à la fois

une plus grande transparence comme base de relations et de travail

Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.

Montez ou restez dans le train SAFe© avec la 5.0 !

Téléchargez la présentation “What’s New in SAFe® 5.0 ?”

SAFe permet de monter à l’échelle dans l’implémentation de méthodes Agile et de mettre en place gouvernance projet et programme robuste.

Hexagon est partenaire de DantotsuPM

Ce jeu de transparents présente une vue assez détaillée de tous les changements introduits dans le SAFe Framework©.

Téléchargez le document: https://v5preview.scaledagileframework.com/?ddownload=41425
© Scaled Agile, Inc.

CertYou est partenaire de DantotsuPM