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é.
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.
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
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.
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é.
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.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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 !
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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².
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
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é.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
Ne forcez pas l’agilité sur chaque projet que vous exécutez simplement parce que les méthodologies agiles et itératives sont « à la mode ». Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.
Voici les questions à vous poser avant de sélectionner une approche agile pour un projet.
Le projet est-il suffisamment important pour que les bonnes personnes s’y consacrent ?
Agile produit des résultats rapidement, ce qui nécessite un gros investissement de temps pour les membres de votre équipe. Les équipes agiles sont composées de gens du business et de personnes techniques qui sont essentiels à vos opérations commerciales. Assurez-vous qu’ils ont suffisamment de temps pour contribuer à votre projet. Cela nécessite souvent des compromis difficiles entre le travail de projet et les opérations.
Les membres de votre équipe ont-ils suffisamment de profondeur et d’étendue de connaissances ?
Ce qui rend les méthodologies agiles agiles, c’est la réactivité à l’évolution des besoins. Les experts du métier travaillent en étroite collaboration avec les experts de l’équipe technique pour fournir ce qui est nécessaire -> rapidement. Pour cela, votre équipe a besoin d’une connaissance approfondie des domaines métiers et techniques touchés par le projet. L’équipe réévalue constamment les besoins business du projet aux niveaux du produit, les fonctionnalités macros et micros et la priorité du besoin.
Votre sponsor a-t-il un état d’esprit agile ?
La réactivité agile à l’évolution des conditions business et son approche apprentissage sont très différents des méthodes de projet traditionnelles.
Votre sponsor doit être à l’aise avec l’évolution des besoins et des priorités de l’entreprise, prêt à participer à des revues fréquentes du produit en pleine évolution et prêt à intervenir pour obtenir les ressources agiles dont le projet a besoin.
Votre équipe peut-elle être co-localisée ou virtuellement co-localisée ?
Agile implique un dialogue profond, interactif et souvent dérangeant, qui nécessite l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la co-localisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir.
Y a-t-il une synergie entre les membres business/métiers et technique de votre équipe ?
L’agilité nécessite le dévouement d’experts business et techniques qui soient ouverts aux nouvelles idées et se soutiennent mutuellement. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations. Pour réussir, une équipe agile doit bien s’entendre.
Le produit peut-il être construit de manière itérative ?
Les meilleures qualités d’Agile proviennent de la fourniture de parties utilisables de la solution tout en apprenant de chaque itération. Bien que ce soit plus courant avec les produits logiciels, d’autres produits peuvent également être fabriqués de cette façon. Avec un peu de créativité, les déménagements, les déploiements de processus et même certains projets de construction peuvent être produits par étapes itératives.
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
Peut-être envisagez-vous de poursuivre une carrière en tant que Scrum Master. Ou peut-être ce rôle vous a-t-il récemment été assigné et vous vous demandez si être un Scrum Master est bon pour vous.
7 Questions to Determine if Being a Scrum Master Is Right for You
Il y a beaucoup de bonnes raisons de devenir un Scrum Master ; l’emploi est très demandé et bien rémunéré. Mais la raison la plus importante, peut-être la seule, de devenir Scrum Master est que c’est le bon job pour vos compétences, votre personnalité et vos centres d’intérêt.
Après tout, je voudrais peut-être devenir un chanteur de K-pop parce que cela paie bien et qu’on en demande, mais il y aurait plein de choses qui me retiendraient de faire une carrière en tête des charts de pop musique.
Voici sept questions que vous pouvez vous poser pour voir si vous êtes plus adapté à une carrière de Scrum Master que je ne le suis à une carrière d’idole des adolescents.
1. Aimez-vous aider les autres ?
Les Scrum Masters doivent aimer aider les autres. Cela ne peut pas être quelque chose qu’un Scrum Master fait à contrecœur. Je pense qu’aider peut être particulièrement difficile si le Scrum Master est dans un double rôle et qu’on s’attend à ce qu’il contribue également en tant que programmeur, testeur, concepteur ou similaire. Quelqu’un dans ce rôle commence à travailler chaque matin en pensant : « Humm, devrais-je faire tout ce que je suis entré dans cette industrie pour réaliser ? Ou devrais-je résoudre les problèmes des autres ? ».
Même avec de bonnes intentions, il est difficile pour beaucoup d’entre nous de vouloir éliminer les obstacles et résoudre les problèmes de quelqu’un d’autre plutôt que de progresser dans nos tâches. Pourtant, c’est exactement ce que fera un excellent Scrum Master.
2. Avez-vous besoin d’être sous les projecteurs ?
Je compare parfois un Scrum Master à un caddy de golf. Un bon caddy peut être essentiel au succès d’un golfeur. Mais les caddies ne sont pas là pour leur propre gloire. Les grands caddies font tout ce qu’ils peuvent pour aider leurs golfeurs à donner une bonne image plutôt que de chercher à faire eux-mêmes bonne figure.
Les Scrum Masters agissent à peu près de la même manière. Par exemple, lors d’une revue dont l’équipe a de quoi être fière, un grand Scrum Master se met en arrière-plan pendant que l’équipe reçoit les éloges.
3. Savez-vous bien écouter ?
Nous savons tous qu’un Scrum Master aide à éliminer les obstacles à la progression et à la productivité d’une équipe. Cela signifie souvent écouter, poser des questions de clarification, puis résoudre le problème. Mais d’autres fois, cela signifie simplement écouter : laisser un membre de l’équipe se plaindre de quelque chose.
Les bons Scrum Masters savent quand passer à l’action et quand écouter avec sympathie.
J’ai déjà coaché une très grande organisation dans sa transition vers l’agilité. Une partie de ce travail impliquait l’embauche et l’établissement de contrats avec des Scrum Masters expérimentés pour aider ceux qui, au sein de l’entreprise, occupaient ce poste.
Pat était l’un des Scrum Masters expérimentés que nous avions embauchés. Quelques mois après l’avoir embauché, le vice-président en charge de la transition m’a demandé si Pat était bon. J’ai répondu avec confiance que Pat faisait un excellent travail.
J’ai demandé au vice-président pourquoi il était curieux à propos de Pat. Il a dit que c’était parce que Pat ne parlait pas beaucoup dans les réunions. J’ai dû souligner que nous ne payions pas Pat au mot prononcé et que lorsqu’il disait quelque chose, c’était souvent brillant.
4. Pouvez-vous influencer sans autorité (hiérarchique) ?
Influencer sans autorité hiérarchique est l’une des leçons les plus difficiles à maîtriser pour de nombreux Scrum Masters. Je trouve cela particulièrement vrai pour ceux qui deviennent Scrum Master après des rôles porteurs d’autorité, tels que chef de projet et leader technique.
Bien que ce soit difficile à apprendre, influencer sans autorité est une compétence importante pour tous les bons Scrum Masters. Si vous aimez mener de cette façon, comptez cela comme un point en faveur d’une carrière en tant que Scrum Master.
D’un autre côté, si vous préférez dire : « Faites-le simplement parce que je vous le dit », n’excluez pas de devenir un Scrum Master. Dans mes premiers rôles de leadership, c’était mon style infortuné et mal choisi. Vous pouvez le surmonter.
5. Êtes-vous à l’aise avec l’incertitude ?
Relisez ce billet sur VUCA
Les équipes Scrum existent vivent dans l’incertitude. Le product backlog est incomplet. L’architecture émerge avec le temps. Les équipes apprennent à accepter l’incertitude.
Pour les dirigeants, cependant, c’est souvent inconfortable. Cela nécessite de faire confiance à l’équipe et souvent d’accorder plus confiance aux membres de l’équipe que dans le passé pré-agile.
Un bon Scrum Master n’a pas à être enthousiasmé par l’incertitude, mais doit y être suffisamment à l’aise pour y vivre. Si vous êtes du genre à vouloir secrètement éliminer toute incertitude, vous serez frustré en tant que Scrum Master ou vous rendrez votre équipe folle à poursuivre un objectif impossible.
6. Pouvez-vous bien manager les conflits ?
Les équipes agiles sont utilisées pour relever les défis les plus difficiles d’une organisation, c’est-à-dire les projets qui ne réussiront pas autrement. Ajoutez à cela les fortes personnalités que l’on retrouve dans de nombreuses équipes de développement et il y aura des conflits.
Au minimum, les membres de l’équipe différeront sur la façon de résoudre les problèmes. Plus fondamentalement, vous devrez peut-être faire face à des conflits de personnalité entre les membres de l’équipe ou à des demandes irréalistes de la part des parties prenantes.
Vous n’avez pas besoin d’aimer les conflits, la plupart des gens ne les aiment pas. Mais pour servir votre équipe, vous devrez vous en occuper.
7. Êtes-vous assez technique ?
Pour être un excellent Scrum Master, vous devez savoir quelque chose sur le travail effectué par l’équipe. Vous n’avez pas nécessairement besoin d’être capable de faire l’un de leurs jobs ni de l’avoir fait dans le passé.
Vous devez en savoir assez pour parler couramment leur langue et faire preuve d’empathie pour les défis que présente leur travail.
Si vous n’avez pas une compréhension approfondie du travail pour avoir fait le job d’un membre de l’équipe auparavant, poser de bonnes questions est un excellent substitut.
Découvrez les types de questions qui aident votre équipe à résoudre les problèmes. Si le fait de négliger un certain type de travail leur a brûlé les doigts dans le passé, posez-leur des questions à ce sujet lorsqu’ils semblent l’avoir oublié. Vous pourriez demander, par exemple, « Y a-t-il des implications pour la base de données ? » si des modifications apportées à la base de données avaient été auparavant négligées.
Vous n’avez pas besoin d’être technique, peu importe ce que cela peut signifier pour vos livrables. Mais vous devez être capable de discuter intelligemment du progrès et des problèmes avec l’équipe.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Qu’en pensez-vous ?
Que pensez-vous de ces sept questions ?
Y aurait-il une autre question que vous poseriez avant de décider qu’une carrière en tant que Scrum Master est un bon choix pour une personne ?
S’il vous plaît partagez vos idées dans les commentaires.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire.
Lorsque le manifeste agile a été publié en 2001, il était à la fois attendu depuis longtemps et bien en avance sur son temps.
Ben Linders
Les méthodes de développement de logiciels axées sur des plans prédictifs ont échoué pendant de nombreuses années au cours du siècle dernier. Elles échouent toujours. Les rapports CHAOS du Standish Group montrent année après année que la plupart des projets informatiques échouent ou connaissent de grosses difficultés. Pour ceux qui réussissent, l’agilité y joue souvent un rôle. Au moment de la publication du manifeste, il était attendu depuis longtemps : nous savions depuis de nombreuses années que faire plus de plans et de meilleurs plans et gérer les projets dans les détails n’était pas la voie à suivre. Nous avions besoin d’une nouvelle approche, d’un nouvel état d’esprit.
Ensuite, des idées telles que travailler en équipe, collaborer étroitement avec les clients, livrer en cycles courts, faire des rétrospectives et adapter notre façon de travailler, challengeaient les personnes et les organisations en 2001. Le monde n’était pas prêt pour cela à ce moment-là. Je me demande en fait s’il est prêt pour cela maintenant, vingt ans plus tard ?
Quand le manifeste a été publié, ce n’était pas quelque chose de « nouveau » pour moi. Mais cela avait beaucoup de sens. J’ai commencé avec l’agilité avant l’invention d’Agile, dans les années 80s. J’ai adopté l’approche pour offrir de la valeur à mon client par incréments parce que cela avait du sens pour moi et mon équipe. Nous avons collaboré, fait des démonstrations de produits, réfléchi à notre façon de travailler et avons adaptée cette approche. Elle nous a aidé à livrer un meilleur produit plus rapidement. En 2001, elle a reçu un nom : Agile.
Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire. La publication du manifeste a supporté une vague de nouvelles réflexions sur la façon dont les humains collaborent et communiquent. Pourtant, de nombreuses personnes ont du mal à appliquer l’agilité dans leur contexte spécifique.
Pour aider à donner du sens au Manifeste Agile et l’appliquer pour réfléchir et apprendre, j’ai créé les Cartes de Questions Rétrospectives du Manifeste Agile. Elles peuvent être téléchargées dans ma boutique en ligne pour une somme modique.
Ces cartes contiennent des questions puissantes pour inspirer vos rétrospectives agiles et les garder précieuses et efficaces. Il y a 15 questions pour chacune des quatre valeurs du manifeste, à la fois pour les côtés gauche et droit de la valeur (c’est « ensemble » donc les deux côtés sont précieux). Et 12 questions bonus que vous pouvez utiliser pour aider les équipes à réfléchir à leur parcours agile, et des cartes vides que vous pouvez utiliser pour ajouter vos propres questions. Au total, il y a 78 cartes avec des questions puissantes.
Poser des questions peut aider à approfondir la compréhension et à mieux comprendre ce qui se passe. Le manifeste agile n’apporte pas de réponses ni de solutions. Il guide vers les choses qui ont du sens, qui comptent. Avec ces conseils, nous pouvons trouver des réponses et trouver des solutions qui fonctionnent pour nous.
En résumé, Agile avec le manifeste Agile me semble être du bon sens pour développer des produits. Malheureusement, le bon sens n’est pas si commun.
Comment les auteurs du manifeste agile m’ont inspiré
Au fil des ans, j’ai rencontré et parlé avec la plupart des auteurs du manifeste Agile. J’ai interagi avec eux lors de conférences où nous avons présenté et partagé nos histoires ou fait des interviews ensemble. J’ai lu leurs livres, articles, blogs et bien plus encore. J’ai eu des discussions avec eux sur LinkedIn, Twitter, Slack ou par e-mail. J’ai également interviewé la plupart d’entre eux en tant que rédacteur en chef pour InfoQ car je voulais partager leur expérience.
Voici comment je me suis inspiré d’eux : Vous trouverez ci-dessous mes histoires inspirées du deuxième bloc de six auteurs du manifeste agile (par ordre alphabétique).
James Grenning
James Grenning
J’ai rencontré James Grenning pour la première fois à la conférence OOP 2015. Nous avons parlé des odeurs du code, ce sur quoi j’ai travaillé en combinaison avec des revues de code. Inspiré par mon expérience, nos discussions et la réflexion sur la façon dont je facilite et enseigne en facilitant les rétrospectives agiles, j’ai trouvé le concept d’odeurs rétrospectives : Des signaux qu’il y a potentiellement quelque chose qui ne va pas dans votre rétrospective. J’ai écrit series of articles on retrospective smells et créé les Agile Retrospective Smells Cards.
J’ai fait un Q&R avec James sur Test Driven Development et Code Smells pour InfoQ où je lui ai demandé pourquoi les programmeurs doivent avoir un bon nez pour les odeurs du code :
Le programmeur qui veut améliorer le code sur lequel il travaille a besoin de trois compétences essentielles. Un bon nez pour le code, des compétences pour envisager un design amélioré et les compétences pour transformer le code malodorant en un meilleur code.
Dit plus simplement, si vous ne pouvez pas identifier avec une certaine précision un problème dans la structure du code, comment pouvez-vous le résoudre ? Je me souviens que les revues de code dans ma carrière n’étaient généralement qu’une question d’opinion. « Je n’aime pas ça, j’aurais fait ça », totalement non justifié. N’importe quel programmeur peut annoncer « ce code pue », mais ce n’est pas suffisant. Un chef dans la cuisine hume une bouffée d’air et dit « jetez les pommes de terre, elles sont mauvaises, et prenez-en des fraîches ». Les programmeurs doivent être en mesure d’identifier des odeurs spécifiques pour avoir une idée de la façon d’améliorer le code.
James Grenning sur InfoQ
James a eu l’idée du planning poker. C’est un excellent moyen d’appliquer la gamification et les jeux pour augmenter la participation des développeurs et créer un environnement sûr permettant aux gens de partager leurs idées et leurs sentiments sur quelque chose d’aussi délicat que les estimations. Dans le planning poker, tomber d’accord ne nécessite pas de débats inutiles. Mon expérience est la même avec des techniques telles que les estimations Delphi à large bande et les bilans de santé ; en utilisant ces techniques, je suggère de passer du temps à discuter des différences car c’est là que se trouvent les apprentissages.
Jim Highsmith
Livre sur Amazon
J’ai vu Jim Highsmith faire une présentation à l’une des premières conférences SM/ASM auxquelles j’ai assisté, je crois que c’était en 2001 ou 2002. Ce sont les premières grandes conférences américaines auxquelles je suis allé et dans lesquelles j’ai ensuite pris la parole. J’ai beaucoup appris lors de ces conférences que j’ai utilisées au fil des ans pour mesurer et améliorer la qualité des logiciels lorsque je travaillais chez Ericsson, et j’ai étendu mon réseau professionnel à de nouveaux domaines.
En 2004, Jim Highsmith a publié le livre Agile Project Management. Il est recommandé de lire si vous devez faire des projets et que vous voulez apprendre à mieux les faire :
Dans un projet agile, l’équipe s’occupe des tâches et le chef de projet s’occupe de l’équipe.
Gestion de projet agile par Jim Highsmith
Appliquer le concept d’agilité à la façon dont les projets sont gérés avait du sens au départ pour moi, mais j’ai vu cela échouer beaucoup plus souvent que réussir. L’échec était le plus souvent dû au fait de ne pas adopter l’état d’esprit agile, mais plutôt d’utiliser à mauvais escient l’agilité comme excuse pour répartir le travail de planification entre les membres de l’équipe tout en essayant de tout micro-manager.
Andrew Hunt a écrit le livre The Pragmatic Programmer (avec Dave Thomas). Il a été publié à l’origine en 1999, mais la version que j’ai lue est l’édition du 20e anniversaire publiée en 2019.
L’essence de l’agilité, comme indiqué dans « le programmeur pragmatique »
Agile est un adjectif : c’est comment on fait quelque chose. Vous pouvez être un développeur agile. Vous pouvez faire partie d’une équipe qui adopte des pratiques agiles, une équipe qui réagit au changement et aux revers avec agilité. L’agilité, c’est votre style, pas vous.
David Thomas et Andrew Hunt dans The Pragmatic Programmer – Édition du 20e anniversaire
Livre sur Amazon
Je partage ce point de vue ; agile n’est pas ce que vous êtes, mais ce que vous faites et comment vous le faites. Le manifeste ne fournit qu’un ensemble de valeurs et de principes, il appartient à chaque individu de réfléchir à la façon de les appliquer et d’agir d’une manière qui a du sens.
En lisant ce livre, je voulais faire un Q&R (interview écrite) avec Andrew et Dave. J’ai posé des questions sur des sujets dans lesquels se plonger. Il s’est avéré qu’Andrew et Dave préféraient faire un podcast ; Voici l’interview que mon collègue rédacteur en chef d’InfoQ, Shane Hastie, a réalisé avec eux : Dave Thomas & Andy Hunt on the 20th Anniversary Edition of The Pragmatic Programmer.
Andrew a fondé la série Pragmatic Bookshelf avec Dave. Il s’avère que j’ai lu beaucoup de livres publiés par eux :
J’ai été en contact avec Ron Jeffries au fil des ans par courriel. Nous avons eu de brefs échanges liées à des discussions sur Twitter, des publications sur InfoQ ou l’un de mes livres. Ron est assez direct sur ce qu’il peut ou ne peut pas faire, quelque chose que je reconnais et apprécie (je suis néerlandais).
Ron Jeffries a « inventé »les Story Points comme un concept pour estimer la taille des histoires dans XP. Avec les Story Points est venu la vélocité comme un moyen de suivre le nombre de Story Points qu’une équipe peut livrer. Oui, livrer : La seule façon d’obtenir des Story Points est lorsqu’une histoire est terminée, le logiciel livré, et donc la fonctionnalité décrite dans l’histoire est disponible pour les utilisateurs.
Au fil des ans, j’ai vu de nombreuses discussions sur l’attribution de Story Points lorsque les histoires sont partiellement terminées (aucune valeur livrée, alors ne le faites pas), l’obtention de Story Points pour résoudre les bogues (encore une fois aucune valeur car le bug n’aurait pas dû être là en premier lieu) et la normalisation des Story Points à travers plusieurs équipes (ce qui conduit généralement à comparer les équipes, ne le faites pas). Il semble y avoir beaucoup de choses qui vont mal et les gens ont du mal à comprendre. Ce qui est dommage.
Le véritable avantage que j’ai vu dans les Story Points est les discussions qu’ils déclenchent. Si tout le monde arrive avec le même nombre ou si les estimations sont proches les unes des autres, ma suggestion est de convenir rapidement d’un nombre et de passer à autre chose. Ne passez pas de temps à savoir si cela devrait être un 3 ou un 5, cela n’en vaut pas la peine. Lorsqu’il y a un écart plus important dans les estimations, discutez pour augmenter une compréhension partagée de l’histoire et non pour estimer. Une fois que les gens s’alignent sur le contenu de l’histoire, il est facile de l’estimer. Si c’est difficile à estimer, alors il y a un manque de bonne compréhension. Travaillez là-dessus.
En 2019, Ron a publié l’article Story Points Revisited où il a exploré comment les Story Points sont mal utilisés. J’aime cette déclaration sur la pression sur les équipes :
La meilleure façon de créer de la valeur n’est pas plus, plus, plus, c’est de faire de petites choses précieuses fréquemment. Si, au lieu d’estimer les histoires, nous les rendons « suffisamment petites », nous pouvons arriver à un flux de valeur fluide, livrant tout le temps.
Ron Jeffries dans Story Points Revisited
Compte tenu du temps perdu avec l’estimation, je suis devenu un fan de l’approche d’estimation que Pawel Brodzinski a mise au point (1 / TFB / NFC) et de #NoEstimates. Ce n’est pas une question d’estimation. Il s’agit de découper les choses jusqu’à la plus petite pièce qui a encore de la valeur et de fournir un flux continu de valeur qui compte.
Tout d’abord, les organisations ne doivent pas « adopter » l’agilité. Elles devraient créer des équipes vraiment agiles et apprendre d’elles. Deuxièmement, les méthodes agiles visent à donner aux équipes les moyens de travailler directement avec les gens du métier et les besoins de l’entreprise. Cela implique que bon nombre des choses faites généralement par les cadres intermédiaires sont prises en charge par l’équipe et son product champion. Les managers doivent l’accepter.
Ron Jeffries sur The Nature of Software Development
J’aime la façon dont il met l’accent sur l’autonomisation des équipes, la collaboration avec l’entreprise et ce que le produit doit faire. Il ne s’agit pas de devenir agile, cela revient aux valeurs du manifeste et à la façon de les mettre en pratique.
Jon Kern
J’ai rencontré Jon Kern lors de l’Agile Greece Summit 2018, une conférence avec de nombreux auteurs du Manifeste Agile. C’était formidable de parler avec lui et d’entendre ses expériences dans sa conférence A Day in the Life of a Jon Kern Agile Project.
Après la conférence, j’ai travaillé avec lui sur l’article d’InfoQ Agile in the Context of a Holistic Approach. C’est un excellent article avec de nombreuses idées pratiques sur l’agilité et l’utilisation de pratiques agiles.
Dans l’article, Jon a partagé son point de vue sur l’état du Manifeste Agile :
Parfois, on me demande si je reviendrais en arrière et changerais le manifeste si je le pouvais.
« Non » est ma réponse.
Au contraire, nous devons nous efforcer de (ré)éduquer les gens sur ce que nous avions l’intention de faire lorsque nous avons écrit le Manifeste.
Jon Kern dans Agile dans Agile in the Context of a Holistic Approach
Je suis d’accord avec lui. Les valeurs du manifeste agile sont grandes et elles n’ont pas vieilli avec le temps. Débattre si elles doivent être mis à jour ou remplacer quelques mots ne nous aide pas beaucoup. Comprendre de quoi il s’agit et le mettre en pratique est ce qui compte.
Ce que nous avons promis, c’est : « Nous vous donnerons des logiciels fonctionnels tous les mois, toutes les deux semaines, que vous pourrez réellement utiliser et montrer. Vous comprenez. Nous vous promettons que si vous décidez à mi-chemin du projet que nous avons en réalisé toutes les fonctionnalités que vous vouliez, vous pouvez simplement vous arrêter, livrer ce que vous avez à ce moment-là et licencier tout le monde, et ne pas aller plus loin dans le projet » – ce qui est très attrayant pour les managers.
Ce que nous n’avons pas promis, c’est : « Nous ne prétendons plus vous dire exactement quel type d’éditeur de texte vous aurez à la fin de l’année. Mais nous vous promettons que vous aurez le meilleur éditeur de texte, l’éditeur de texte le plus complet, avec les fonctionnalités les plus importantes que vous pouvez avoir avec cette équipe à la fin de cette année. Nous ne pouvons tout simplement pas vous dire maintenant ce que ce sera. Vous pourrez le faire, vous apprendrez à le savoir, parce que nous allons vous laisser nous dire quelles sont les choses les plus importantes, et nous les ferons tout de suite, plutôt que de passer un an à en écrire les fondations avant que vous puissiez voir quoi que ce soit. C’est à la fois un bon moyen de développer des choses pour la plupart des types de choses, la plupart des types de logiciels, et c’est aussi un argument de vente très puissant.
Brian Marick dans l’interview de Leanpub Frontmatter
Tenir cette promesse était et a été un élément clé dans de nombreuses entreprises qui envisageaient d’adopter l’agilité. Agile consiste à fournir de la valeur là où vous devez investir du temps pour découvrir quelle devrait être cette valeur. Il ne s’agit pas de spécifications ou d’exigences de projet. Ce qui compte, c’est une discussion intensive et transparente continue qui aide à déterminer ce dont les utilisateurs ont le plus besoin maintenant et à le faire. Si une organisation n’est pas prête à en discuter, alors ne faites pas d’agilité.
En 2018, j’ai été invité à la conférence eXperience Agile 2018 où j’ai parlé avec Brian Marick. Après la conférence, Brian a commencé à travailler sur un article sur la cognition incarnée. Malheureusement, nous ne l’avons jamais terminé et publié. Mais nous avons eu d’excellentes discussions.
Agile a du sens
Les idées mentionnées ci-dessus ne sont que quelques-unes des choses auxquelles je pouvais penser en écrivant ce billet. Cela résume à quel point l’agilité a eu du sens et a encore du sens pour moi. Comme vous pouvez le constater, les auteurs du manifeste agile ont été une source d’inspiration tout au long de ma carrière et à bien des égards.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).
Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Qu’est-ce qu’un sprint ?
Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.
Il n’y a pas d’activité en dehors du sprint.
Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.
Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.
Pourquoi est-il timeboxé ?
La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.
Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !
Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !
La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).
Quand un sprint est-il terminé ?
La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).
Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).
Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).
Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.
L’important est que la timebox régulière soit respectée.
De quelles autres façons un sprint peut-il se terminer ?
Il n’y a que deux autres façons dont un sprint peut se terminer.
La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.
Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.
L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.
partagez ce billet avec vos amis, collègues et relations professionnelles
Bien qu’il y ait probablement plus que ces 7 manières de gaspiller de précieuses revues de projet, apprenez pour commencer à reconnaitre et éviter celles-ci.
Votre équipe suit un framework Agile spécifique ou a adopté une approche mixte dans ses pratiques, un principe d’Agile est l’utilisation de courtes boucles de rétroaction pour soutenir l’inspection et l’adaptation.
Que votre équipe fixe une cadence régulière pour les évaluations externes des livrables ou qu’elles soient effectuées dans la foulée, il est important d’obtenir des retours exploitables. Mais mener une revue n’est pas seulement une question de rassembler les gens.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Bien qu’il y ait probablement plus que ces façons de gâcher les revues, en voici sept dont j’ai été témoin.
#1 – Le seul participant est un Product Owner (ou un rôle similaire représentant la voix du client).
Bien que nous nous attendions à ce que les Product Owners soient bien informés, leurs retours sont à un pas de distance de celui des véritables parties prenantes externes. Le Product Owner peut juger si le produit répond aux besoins, mais l’équipe perd l’avantage de poser des questions comme « Quelles nouvelles idées cette fonctionnalité vous donne-t-elle pour le produit ? » ou « Comment pourrions-nous faire en sorte que cette fonctionnalité ajoute plus de valeur pour vous ? ». De plus, les retours du Product Owner devraient (idéalement) être reçus par l’équipe quotidiennement plutôt que d’organiser un événement spécial uniquement à cette fin.
Visitez le site de notre partenaire Virage Group
#2 – Trop en mettre dans une seule revue et ne pas laisser suffisamment de temps aux parties prenantes pour digérer ce qu’elles ont vu.
Au fur et à mesure que les équipes s’améliorent dans la livraison, elles peuvent être en mesure d’effectuer plus de travail sur un même laps de temps.
ne chargez pas trop les revues
Dans ce cas, la fréquence des examens externes devrait être rapprochée afin que le contenu examiné soit moins important et que le contenu couvert soit organisé par ordre de priorité.
#3 – Organiser une démonstration plutôt qu’un échange bidirectionnel.
Si le seul but d’une revue est de montrer ce que l’équipe a accompli, cela pourrait être enregistré et envoyé aux parties prenantes pour qu’elles les regardent à leur guise.
La vraie valeur d’un examen réside dans la richesse des discussions entre les membres de l’équipe et les parties prenantes et entre les différentes parties prenantes en fonction de ce qu’elles voient.
L’utilisation de questions puissantes et ouvertes est un moyen de s’assurer que le partage des connaissances ne se fait pas dans une seule direction.
#4 – Avoir les mauvaises personnes dans la revue.
Il est presque aussi mauvais d’avoir les mauvais intervenants externes dans la salle que de n’en avoir aucun. Si des personas sont utilisés pour faciliter la découverte des exigences, il devrait y avoir au moins un représentant pour chaque persona si le contenu de ce qui est examiné les affecte.
Et parce qu’une revue est une séance de travail et pas seulement un forum de partage d’informations, nous ne voulons pas non plus avoir trop de monde dans la salle.
#5 – Prendre des engagements pendant la revue.
ne prenez pas d’engagements trop rapidement
Il peut être tentant pour un membre de l’équipe ou le Product Owner d’essayer de s’attirer les faveurs d’une partie prenante externe puissante en s’engageant à un changement spécifique du livrable ou sur une date de livraison, mais ce n’est pas le bon forum pour cela.
Le contenu et les dates souhaités peuvent être notés, mais le Product Owner et l’équipe doivent prendre le temps de comprendre les impacts de ces changements.
#6 – Critique ouverte du travail de l’équipe.
Il est naturel qu’une partie prenante externe soit frustrée si ses attentes n’ont pas été satisfaites pour le contenu examiné. Ces critiques sont essentielles pour aider l’équipe à s’améliorer au fil du temps.
Mais si cette critique est fournie de manière abusive, le moral et la productivité de l’équipe en prendront un coup.
#7 – Ne pas prendre suffisamment de temps pour analyser ce qui a été appris lors d’une revue.
Si nous mobilisons un temps précieux pour les parties prenantes, il nous incombe de bien utiliser leurs retours. Il peut être pratique d’organiser une rétrospective ou un artefact similaire immédiatement après une revue, mais cela peut ne pas laisser le temps nécessaire à l’équipe et au Product Owner pour digérer correctement les retours qu’ils ont reçus.
Des critiques bien managées sont un ingrédient clé de la construction du bon livrable pour nos clients, donc éviter ces sept péchés contribuera grandement à tirer une valeur réelle de ces rencontres critiques.
partagez ce billet avec vos amis, collègues et relations professionnelles
Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.
En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.
CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Ayez une attitude constructive et une approche communicative
Une grande partie des problèmes se résument à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».
Une discussion en face à face est souvent plus efficace.
En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.
Coachez les autres membres de l’équipe sur les aspects pertinents du test .
En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.
L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.
Collaborez avec les développeurs, le Product Owner et les stakeholders pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.
Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.
Les testeurs doivent être impliqués dans les sessions de Pré-planification et de user stories grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :
Définition des user stories et des critères d’acceptation
Participation aux analyses de risques et de qualité de projet
Création de tests d’acceptation pour les user stories
Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .
Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.
Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.
Reportez les défauts et travaillez avec l’équipe pour les résoudre.
Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise temps et budget.
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai été impliqué dans Agile depuis environ 20 ans et j’ai remarqué un anti-modèle répétitif qui semble ne jamais changer.
Les gens attendent trop longtemps pour demander de l’aide !
Je l’ai remarqué dans mon activité de coach. D’habitude, au moment où je suis appelé dans une organisation qui essaye de mettre en œuvre Agile, la situation est (j’ose le dire) que les wagons sont sortis des rails. Bien sûr, une partie de moi pense que c’est une chose bonne ou normale. Mais c’est seulement la partie de génération de revenus qui parle.
La partie principale de moi qui est coach agile regrette toujours qu’ils ne se soient pas venus plus tôt. Ceci aurait évité tant d’aggravation et de frustration, de gaspillage de temps et d’efforts et de coûts en bout de ligne.
Mais ce n’est pas seulement en tant que coach. Ceci s’applique aussi à mon expérience de leader.
Si un projet avait déraillé ou qu’un engagement était manqué, je le découvrais le plus souvent à la dernière minute. Bien plus tard que quand j’aurais encore pu faire quelque chose ou aider. Je travaille toujours dur comme leader pour créer de la sécurité pour l’annonce de mauvaises nouvelles, être accessible et être reconnaissant de cela. Très dur. Mais cela me choquait toujours de constater combien de fois les gens attendaient trop longtemps pour partager quelque chose avec moi. Je me demande souvent, que devrais-je faire pour créer une culture où le partage des problèmes serait récompensé, serait la norme et ne serait pas craint ?
Cela s’applique même à mon coaching et à mes collègues agiles dans les diverses communautés agiles dont je fais partie. Je m’assimile souvent “à un coach de coaches” et c’est ce que je suis. Mais de nouveau, presque 100 % des gens attendent trop longtemps pour m’appeler à l’aide.
Je ne leur dis normalement rien directement parce qu’il est trop tard pour cela. Mais je pense souvent par devers moi que les résultats pourraient être significativement différents s’ils étaient seulement venus me voir plus tôt. Mon coaching, ou celui de qui que ce soit, pourrait avoir évité tant de frustrations et d’aggravation en évitant des erreurs coûteuses.
Vous m’avez compris. Avant que nous n’allions plus loin, je souhaiterais partager avec vous l’une de mes métaphores préférées autour de ce sujet …
Le Statut Pastèque
Je ne peux pas me rappeler la première fois quand je l’ai entendu mais j’aime la notion de « statut pastèque ».
C’est un projet qui est vert à l’extérieur (annoncé comme étant sur les rails, excellent) et rouge à l’intérieur (déraillé, en retard sur les délais, dépassant le budget).
Une fois que j’ai entendu cette métaphore, elle a résonné sur CHAQUE projet que j’avais mené comme leader. 90 % du temps, les membres de mon organisation annonçaient un statut pastèque.
Et, vous découvrez que c’est rouge SEULEMENT à la toute dernière minute. Au point que, en tant que leader, vous n’avez que très peu d’options pour aider ou faire quoi que ce soit.
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
Les Raisons Possibles
J’ai alors mis mon chapeau remue-méninges / brainstorming et essayé de penser à toutes les raisons pour lesquelles on pourrait ne pas vouloir demander de l’aide.
Optimisme – Espoir
Crainte …
D’échec, de ramifications, de sembler mauvais, de perdre son travail, ou d’être rétrogradé
Ignorance
Sentiment de propriété – c’est mon travail
Apathie
Réparer, c’est mon défi …
Manquer de …
Compétences, connaissances, expériences, sécurité, ou courage
Orgueil ou Obstination
Budgets serrés
Timidité
Ne pas vouloir « déranger » qui que ce soit
Responsabilité ou Devoir
Recherche d’un nouveau travail
Sabotage
Voici certaines raisons qui me sont venues à l’esprit. Mais je suis sûr qu’il y a d’autres et j’espère que vous en ajouterez dans les commentaires.
Certaines d’entre elles sont liées à nos opinions ou à des bagages historiques et d’autres plus dépendantes de notre culture actuelle. Quoi qu’il en soit, j’ai voulu illustrer un large spectre de raisons et que je me rends compte que ce sujet est complexe et nuancé.
Je veux rediriger cette discussion sur un jeu de 5 leçons durement apprises que j’ai expérimentées dans ce domaine. J’espère que vous pouvez les prendre avec vous et qu’elles pourront vous servir d’encouragement pour à aller chercher plus d’aide.
#1 – Typiquement, le temps n’améliore pas les choses …
Une de mes leçons apprises à travers toute ma carrière est que quand vous faites face à un challenge :
Challenge de client;
Challenge de personnel;
Challenge de projet;
Challenge personnel;
Challenge de direction;
Presque n’importe quel Challenge …
Attendre ne semble pas aider. Cela rend typiquement les choses plus mauvaises. Bien pires !
Leçon : N’attendez pas trop longtemps pour demander de l’aide. Faites-le maintenant!
#2 – Comment vous commencez est critique
Rappelez-vous pourquoi vous avez commencé.
Le début de toute entreprise est critique. C’est là que votre stratégie est définie. C’est là que le pourquoi et les objectifs sont établis. S’il y a un meilleur moment pour demander l’aide, c’est au début d’un effort. Et plus l’effort est important (dans sa portée, sa valeur, son impact, etc.), plus critique il est de demander de l’aide au commencement.
Leçon : quoi que ce soit qui mérite d’être fait, particulièrement dans des initiatives critiques, il vaut mieux bien démarrer. Commencez en ayant la finalité à l’esprit.
#3 – Trop d’espoir et d’orgueil …
L’espoir n’est pas une stratégie et il y a trop d’orgueil dans le monde. Ces deux-là empêchent de demander de l’aide. Vous devez regarder au-delà de votre propre personne quel sera l’impact de ce challenge sur les autres. Autrement dit, rendez-vous compte que ce n’est pas de vous qu’il s’agit. Il en va de votre équipe ou de votre organisation toute entière.
J’ai constaté que de me rappeler à moi-même la portée et l’impact d’un défi (au-delà de ma personne) pouvait servir à me motiver à demander/trouver de l’aide. Montrez plus de vulnérabilité.
Leçon : Regardez au-delà de vous-même quel sera l’impact (si cet obstacle est incorrectement traité) sur votre univers au sens le plus large. De cette perspective, demandez-vous ensuite si vous avez besoin d’aide …
#4 – Plus haut vous êtes, plus dur il y parait …
J’ai aussi remarqué que plus votre position dans l’organisation est élevée (promotion, niveau, titres etc.), plus il semble difficile de devoir demander l’aide.
Et pas seulement de consultants/coachs externes, mais pour que quelqu’un à l’intérieur de l’organisation puisse aussi vous aider.
Leçon : Peu importe notre titre, nous avons tous besoin de l’aide, alors demande-la. C’est en réalité un signe de force, pas de faiblesse et cela fait grandir votre organisation …
#5 – Le budget semble toujours être un challenge …
Nous ne pouvons pas nous le permettre. Je n’ai pas le budget pour cela. Si je leur demande de l’aide, ils me la feront payer. Beaucoup de leaders manquent du courage de défier le statu quo quand on en vient aux contraintes. Je soutiendrais qu’il y a d’habitude davantage de capacité et de flexibilité dans les organisations pour dépenser de l’argent pour des initiatives critiques ou résoudre des problèmes critiques. Cela demande seulement à certains de lever la main et de demander, de demander de l’aide.
Leçon : Vous ne pouvez pas vous permettre de ne pas payer pour l’aide dont vous avez besoin. Demandez-vous quel sera le coût de l’échec ? De ce point de vue, il est souvent meilleur marché de demander l’aide…
En conclusion
Dans le doute… demandez de l’aide!
Je veux demander à chaque lectrice et lecteur de ce billet de l’aide.
S’il vous plaît, réfléchissez à cet article et comment il résonne avec votre voyage personnel et professionnel. Puis, partagez s’il vous plaît des commentaires pour complémenter ce billet.
J’aimerais entendre vos histoires, vos perspectives et vos diverses réactions.
Restez agile mes amis,
Bob.
Post-scriptum
Il y a un point de vue intéressant dans cette vidéo de Richard Sheridan où il explore le fait de dire la vérité dans ses projets. Je pense qu’il est parfaitement en ligne avec le thème de ce billet…
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans notre voyage vers Agile, nous nous demandons souvent par où commencer, quels pratiques, outils et processus devrions-nous nous utiliser ?
Ce que j’ai appris pendant mon propre voyage est que nous n’avons pas besoin d’une « autre » méthode. Aucune de celles-ci n’est une solution miraculeuse de toute façon. Elles sont toutes formidables pour entamer comment changer la façon dont vous travaillez et les mentalités.
Mais la partie la plus importante de votre voyage est le succès.
Pouvez-vous partager une histoire de réussite ?
Pouvez-vous utiliser vos propres mots pour décrire comment votre propre environnement a changé et montrer l’impact de ces nouvelles manières différentes de travailler ?
Si oui, les gens vont s’y mettre et essayer d’atteindre un impact similaire.
Les transformations agiles les plus réussies que j’ai vues ont commencé exactement comme cela. Avec une petite équipe expérimentant de nouvelles pratiques et partageant l’impact observé avec d’autres. Selon le point de départ, ces équipes partagent des histoires de réussite différentes et diverses, comme. 5 fois moins de bogues reportés par des clients, 3 fois plus de valeur livrée sur une période donnée (ce n’est pas la même chose que plus de fonctionnalité, mais souvent le contraire), un délai de mise sur le marché significativement plus rapide, une motivation plus élevée et un meilleur niveau d’engagement, plus d’innovations qui aboutissent à une satisfaction client meilleure… l’impact varie en fonction de l’environnement.
Pour nous, il y a quelques années c’était plus de flexibilité, apprendre plus rapidement et une meilleure satisfaction client.
Partager sur les succès n’a rien de nouveau dans le management du changement. C’est l’une 8 étapes dans Conduire le changement: Feuille de route en 8 étapes de John Kotter que pour quelque raison on ne connait toujours pas assez largement dans la communauté agile, donc j’ai pensé à vous les rappeler ici .
#1 – Créez le sens de l’urgence
Sur Amazon
À moins que vous ne sachiez pourquoi vous changez la façon dont vous travaillez (pour être plus agiles, Scrum ou Kanban), ne le faites pas. Ni Agile, ni Scrum, ni Kanban ne sont votre but. Ce sont juste des ‘béquilles’ vous aidant dans votre voyage vers la réussite. Vous devez avoir un objectif plus élevé défini qui sera plus fort que les objectifs individuels et unifiera donc les personnes.
#2 – Construisez une coalition de direction
Vous ne pouvez jamais changer l’organisation si vous êtes seul. Vous devez trouver des partisans (des enthousiastes agiles dans votre cas) qui créeront une équipe qui vous aidera à changer le système. Ainsi, au minimum deux personnes complémentaires qui sont de vrais aficionados agiles, car trois personnes constituent l’équipe la plus petite. Les autres vous rejoindrons en observant des résultats.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
#3 – Formez une vision et des initiativesstratégiques
Parfois avoir d’un but n’est pas suffisant car les gens ne voient pas de manière d’y arriver et le changement dans sa globalité est trop abstrait. C’est un espace où les structures, les méthodes et les pratiques sont utiles.
#4 – Enrôlez une armée de volontaires
Recrutez des enthousiastes.
Finalement, c’est le moment de le rendre plus grand. Faites-en un mouvement, pas juste un autre projet. Faites-y adhérer un plus grand groupe. Faites-les s’impliquer. De nouveau, si vous sautez certaines des étapes précédentes, cela ne pourra pas grandir.
#5 – Permettez l’action en faisant tomber les barrières
Libérez les énergies.
Maintenant, une fois que vous avez l’énergie de votre côté, vous devez l’aider et éliminer les barrières (hiérarchie, silos, positions détaillées, KPIs individuel, …), sinon, tout l’enthousiasme initial va s’évaporer avant que vous ne le compreniez.
#6 – Générez des victoires dans le court terme
Célébrez toutes les avancées.
Générez du succès rapidement et souvent et rendez-le visible à toutes et tous. Partagez des histoires d’améliorations, célébrez même de petits pas de progrès. Le succès est un moteur puissant pour le changement. Accélérez, multipliez les succès. Sans cela, tout changement mourra.
#7 – Soutenez l’accélération
Continuez tout le temps de pousser.
Vous pouvez la célébrer, mais vous ne pouvez pas arrêter de pousser après la première victoire, ne soyez pas trop satisfait. Il y a toujours une meilleure manière. Trouvez un autre défi, découvrez une meilleure façon de travailler jusqu’à ce que la vision de la nouvelle façon de travailler définie par le but original devienne vraie.
#8 – Institutionnalisez le changement
Utilisez ce levier pour accélérer.
Finalement en créant des liens entre la nouvelle façon de travailler et le succès vous tenez le levier du changement.
Ces liens sont la glu qui empêche l’environnement de retomber en arrière dans l’ancienne façon de travailler.
Agile est un changement majeur et sans le conduire comme un changement vous aurez beaucoup de mal à réussir.
N’oubliez donc pas de définir à quoi ressemble le succès, célébrez-le et rendez-le meilleur au fil du temps.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance.Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.
Mesurable.
La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.
Atteignable
Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.
Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.
Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.
Réaliste
Une approche pratique de comment planifier et implémenter le changement
En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.
Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.
La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.
Temporel – contraint par le Temps
L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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 !
Au minimum, les membres de l’équipe différeront sur la façon de résoudre les problèmes. Plus fondamentalement, vous devrez peut-être faire face à des conflits de personnalité entre les membres de l’équipe ou à des demandes irréalistes de la part des parties prenantes.
Que pensez-vous de ces sept questions ?
Appliquer le concept d’agilité à la façon dont les projets sont gérés avait du sens au départ pour moi, mais j’ai vu cela échouer beaucoup plus souvent que réussir. L’échec était le plus souvent dû au fait de ne pas adopter l’état d’esprit agile, mais plutôt d’utiliser à mauvais escient l’agilité comme excuse pour répartir le travail de planification entre les membres de l’équipe tout en essayant de tout micro-manager.
DantotsuPM.com 