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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un risque asymétrique est un risque où la récompense potentielle l’emporte largement sur la perte potentielle. Identifiez et prenez davantage de ces risques.
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. 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.
En tant que manager de projet et leader d’équipe, la sécurité psychologique est un élément essentiel de la création et du support d’équipes très performantes.
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
partagez ce billet avec vos amis, collègues et relations professionnelles
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
Fauxcar 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.
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).
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 changementdemandé 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard.
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.
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.
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.
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.
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
Séquencez.
Donnez du mou.
Tirez.
Tous les problèmes mentionnés dans cet article sont alors résolus.
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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 trainsgrâce aux règles SAFe ou malgré elles ?
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Beaucoup de critiques concernant SAFe sont dirigées vers la prescription détaillée qu’il donne du « comment faire ».
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.
#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.
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.
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 !
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à.
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…
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 !
DantotsuPM.com 