L'introduction ultime à la gestion de projet agile

Le bref

Vous êtes chargé de livrer la dernière et la plus grande initiative de votre entreprise qui va changer à jamais le visage de "Widgets International". Il s'agit d'un projet logiciel qui engagera et captivera vos clients, facilitera la vie de vos collègues et rapportera à l'entreprise des millions de revenus. Il y a beaucoup d'anticipation, de ferveur, d'excitation et d'attente. Vous devez le faire le plus rapidement possible afin que votre entreprise puisse commencer à en récolter les bénéfices. Le succès futur de l'entreprise dépend de vous. Tous les yeux sont sur vous. Vous ne pouvez pas échouer.

Au début, vous vous dites : « Génial, je suis prêt à relever le défi. Faisons cette chose! Vous vous arrêtez un instant, prenez du recul et pensez à vous-même : "D'accord, alors comment on fait ça ?" Vous commencez à parler à vos collègues et pairs. Vous passez du temps à rechercher les meilleures pratiques en matière de développement de logiciels et de techniques de gestion de projet, mais les options et les approches sont innombrables. Il existe une multitude d'acronymes et de méthodologies. Les notables montent au sommet. Le doute s'insinue. Lequel utiliser ? Comment puis-je garantir le succès ? Et si je prends les mauvaises décisions ?

Lorsqu'il s'agit de gérer des projets logiciels, il existe un mélange grisant d'options soutenues par une myriade d'opinions. Des voix provenant des coins de la pièce chuchotent : « Essayez de faire comme ça » ; d'autres crient : « C'est la seule façon de le faire » ; et les autres se contentent de gémir : "Ne le faites pas du tout, continuez simplement." En réalité, toutes ces voix disent une part de vérité. Mais ce qui est important, c'est de déterminer ce qui convient à vos besoins, à votre équipe, à votre entreprise et à vos clients.

Mise en scène

Il fut un temps où la gestion de projet logiciel se situait carrément dans l'un des trois camps. Il y avait les cadres lourds qui vous permettaient de prendre des décisions sur la façon dont vous exécutez et livrez tout en offrant une structure pour maintenir le contrôle et la gouvernance. Il existait des méthodologies séquentielles prescriptives comme la cascade qui vous obligeaient à planifier de longs projets, à comprendre et à vous engager dans toutes vos exigences, à concevoir et à valider des systèmes complexes, à écrire beaucoup de code, puis à tester (le tout avant que votre client ne le voie pour la première fois). temps). Et enfin, les cycles de vie de développement logiciel (SDLC) moins normatifs mais itératifs qui encouragent le prototypage rapide ou la conception, la construction et la livraison de systèmes plus grands par étapes incrémentielles, chacune se construisant au-dessus de l'autre.

Le développement logiciel Agile et la gestion de projet Agile sont nés des insuffisances de la cascade et des avantages des approches itératives de la livraison de logiciels. Ils peuvent retracer leurs racines dans les années 1950, le leadership éclairé dans les années 70, la maturité dans les années 90 et l'adoption dans les années 2000. En 2001, un groupe de praticiens et d'experts a créé le Manifeste Agile, visant à définir 4 valeurs et 12 principes directeurs qui cherchent à incarner l'esprit du développement logiciel Agile et à encourager son évolution. Et ça a forcément évolué.

Maintenant, appeler simplement quelque chose Agile n'est pas particulièrement utile. Le mot, même dans un contexte logiciel, signifie différentes choses pour différentes personnes ou organisations. Il existe de nombreuses facettes, définitions, implémentations et interprétations. Chaque corps qui adopte Agile a tendance à essayer de lui donner sa propre définition.

Qu'il suffise de dire que le développement logiciel Agile et la gestion de projet sont un groupe de comportements, de cadres, de techniques et de concepts connexes qui favorisent fondamentalement la livraison du bon logiciel de travail le plus tôt et le plus souvent possible.

J'ai mentionné plus tôt qu'Agile, appliqué au développement de logiciels ou à la gestion de projet, peut être différentes choses. En un mot, le développement logiciel Agile s'occupe de développer d'excellents logiciels dans un contexte de business as usual (BAU) ou de projet. La gestion de projet agile, quant à elle, prend en charge la gouvernance et le contrôle nécessaires pour livrer des projets complexes, y compris, mais sans s'y limiter, les logiciels.

Il existe de nombreuses méthodes de développement logiciel Agile, telles que Scrum, Kanban, XP et Lean Software Development. Mais tout comme le rugby ne se limite pas à la mêlée, Agile l'est aussi. Pris isolément, ces paradigmes Agile n'abordent pas le cycle de vie complet de la gestion de projet requis dans des projets complexes tels que la gouvernance, les ressources, la gestion financière et explicite des risques et de nombreux autres concepts importants de gestion de projet. Pour ceux-ci, vous voudrez peut-être envisager PMI Agile ou PRINCE2 Agile – pensez-y comme « Agilité Gouvernée ».

Pourquoi devons-nous être agiles ?

Il y a longtemps, nous parcourions la terre pour trouver de la nourriture et un abri pour survivre. C'étaient des besoins simples, mais assez agiles. Quelque temps plus tard, les pays et les économies ont grandi et prospéré grâce à la révolution industrielle. Ce fut la naissance de la gestion et du contrôle et la perte d'agilité. Nous sommes maintenant à l'ère ou à la révolution de l'information, où les entreprises emploient des travailleurs du savoir. Les travailleurs du savoir sont vous, vos partenaires et vos collègues et pairs, qui s'efforcent de créer d'excellentes solutions aux problèmes des clients, des affaires, sociaux, économiques et mondiaux. Les travailleurs du savoir appliquent l'analyse, les connaissances, le raisonnement, la compréhension, l'expertise et les compétences à des besoins souvent vaguement définis et changeants. Ces entreprises et ces travailleurs ont besoin de méthodes et de techniques qui ne peuvent être satisfaites par les processus et procédures de l'ère industrielle. Agile prend en charge les interactions.

Pratiquement aucun projet logiciel ne peut démarrer en toute confiance et savoir tout ce dont il a besoin pour fournir un logiciel de travail précieux sans changement. Le changement présente à la fois des opportunités et des risques pour le succès d'un projet. Les opportunités non gérées peuvent faire la différence entre une grande entreprise et une entreprise géniale. Un risque non géré est synonyme de désastre et de ruine. Agile gère le changement.

L'adoption d'Agile vous permet d'être réactif à l'évolution ou aux nouvelles exigences. Il permet aux équipes de développement d'être les experts et de prendre des décisions soutenues par une entreprise engagée, confiante et informée. Il vous permet d'offrir aux clients ce qu'ils veulent vraiment. En fin de compte, cela vous donne, à vous et à votre organisation, le contrôle de la fourniture de logiciels précieux et de haute qualité qui répondent aux besoins et aux attentes des clients tout en extrayant un retour sur votre investissement le plus tôt possible. Agile crée de la valeur.

L'adoption d'Agile a un coût. Ce n'est pas gratuit. Passer à une approche Agile pour la livraison de logiciels peut être un chemin difficile à suivre. Cependant, si vous intériorisez la philosophie Agile, faites preuve de prudence, engagez la bonne équipe avec la bonne attitude, décomposez les choses, rendez-les réalisables et réalistes et répondez aux commentaires, vous en récolterez les fruits. Agile met l'accent sur la collaboration.

La liste suivante répertorie certains avantages auxquels vous pouvez vous attendre :

• La rapidité de commercialisation
• Génération de revenus plus tôt
• Livraison régulière de valeur réelle
• Protection de votre investissement
• Données, données, données
• Meilleure qualité du produit
• Attentes gérables
• Une plus grande satisfaction client
• Des équipes plus performantes
• Amélioration de la visibilité sur les progrès
• Prévisibilité, transparence et confiance
• Risque gérable

Le succès n'est pas définitif, l'échec n'est pas fatal : c'est le courage de continuer qui compte.

Winston Churchill n'a peut-être jamais dit cela, mais je pense que c'est un assez bon résumé d'Agile. Nous savons qu'Agile est la meilleure solution pour la plupart des projets. Cela vous encourage à lutter pour le succès, mais nous itérons toujours et continuons à construire dessus. Agile vous encouragera à échouer, mais échouez tôt et passez à autre chose. Avoir le courage de continuer et de construire la bonne solution basée sur les informations fournies par votre client est ce qui apporte la récompense.

La chose à garder à l'esprit est que vous pouvez adapter Agile à vos besoins. Utilisez la méthode et la gouvernance qui conviennent à votre entreprise. Où que vous commenciez, soyez fidèle au contenu, au contexte et à l'esprit de la méthode que vous utilisez - restez basique. Si vous débutez, apprenez . Si vous le faites depuis un certain temps, comprenez . Si vous devenez génial, postulez . Enfin, si votre entreprise et vos projets sont complexes et interdépendants, gouvernez . Au fil du temps, vous et vos équipes découvrirez ce qui fonctionne le mieux pour votre entreprise.

Faisabilité

Alors maintenant, vous pensez : « D'accord, j'ai compris. Comment commencer ? Où est-ce que je commence?" Eh bien, avec toutes les bonnes choses, nous commençons par le début. Et avec Agile, c'est en vous demandant « Quelle valeur commerciale est-ce que je veux apporter ? » Après tout, c'est pour cela que nous entreprenons des projets, pour générer de la valeur commerciale. Afin d'établir si le projet vaut la peine d'être entrepris pour en tirer la valeur commerciale, vous devez comprendre s'il est réalisable.

Vision

Votre projet prévoit-il d'augmenter les revenus, d'entrer sur un nouveau marché, d'acquérir plus de clients, d'améliorer la perception des clients ou de faciliter la vie pour un problème donné que vous avez identifié ? Dans cet esprit, vous pouvez énoncer votre « vision ».

• Votre vision peut provenir de différentes sources : votre propre startup audacieuse pour résoudre un problème commun, une stratégie de gestion d'entreprise, le projet favori de votre PDG, une équipe de produit spécifique ou même les besoins de votre client.
• Essayez de prendre du recul par rapport à vos propres chaussures et « voyez » à quoi ressemble l'avenir avec votre nouveau produit ou service entre les mains de vos clients.
• Engagez vos parties prenantes : le PDG, le responsable produit et les clients. Travaillez-le, n'essayez pas de l'isoler. Remettez en question les hypothèses et validez les arguments.
• Écrivez-le, soyez bref. Concentrez-vous sur la valeur commerciale.
• Affinez-le jusqu'à ce que vous soyez tous d'accord sur le fait que la vision résonne avec tout le monde et répond à une interprétation commune qui indique où vous vous dirigez.
• Votre vision, si elle est valide, change rarement. Comment vous y arriverez très certainement.

Les gens n'achètent pas ce que vous faites, ou comment vous le faites. Ils achètent le "pourquoi" vous le faites. C'est ce qui crée le lien émotionnel entre votre entreprise et vos clients. La vision aidera à illustrer cela.

Est-ce faisable ?

La faisabilité se décline en au moins deux nuances. En règle générale, vous voudrez comprendre si votre vision d'un avenir meilleur pour votre entreprise et vos clients est à la fois techniquement réalisable et s'il est possible pour votre entreprise de la concrétiser.

• Si votre vision est de faire voyager n'importe où à travers le monde en moins d'une heure, vous pouvez avoir un problème avec la faisabilité technique. Étant donné que la science, la physique et la technologie n'ont pas encore tout à fait rattrapé ce rêve, votre solution technique peut ne pas être viable autrement qu'en théorie. De plus, si votre solution était nouvelle, cela irait bien au-delà de l'idée d'un produit minimum viable (MVP).

• Pour tester la faisabilité technique de votre produit, envisagez soit de l'explorer davantage dans un projet de prototype Discovery, soit de lancer un pic dans les premières étapes du projet. Vous saurez quelle méthode utiliser en pensant à l'échelle ou à la complexité de la solution que vous avez en tête.

  "Certaines des meilleures connaissances que mes équipes ont acquises dans la compréhension de la faisabilité technique proviennent de la réalisation d'un pic. Et souvent, c'est la solution la plus simple qui l'emporte !

• La deuxième nuance de faisabilité à considérer est de savoir si vous, votre équipe ou votre entreprise avez les compétences et la motivation pour le faire fonctionner. En utilisant un exemple, si vous êtes doué pour faire des gâteaux à la maison pour l'anniversaire de vos enfants, c'est gentil. Mais si vous voulez en faire une entreprise vendant les meilleurs gâteaux au monde, vous devez comprendre si vous pouvez la faire évoluer, gérer l'entreprise ainsi que la production, gérer la distribution et l'exécution, et prendre soin du service client.
• Ce type de vision pourrait être réalisable à long terme. Mais pour l'instant, peut-être pas. Alors, réduisez-le, pensez petit, prenez un petit morceau qui semble réaliste et concentrez-vous sur la meilleure aspiration possible. Si cela parvient à engager et à ravir vos clients, faites-les revenir pour en savoir plus et en parler à leurs amis, puis augmentez-le à partir de là en utilisant les commentaires de vos clients comme guide et boussole.
• Aussi, vous devez savoir si votre projet est réalisable en termes de budget et de délais. Votre entreprise peut-elle se permettre de réaliser ce projet ? Le délai est-il réalisable ? Le temps et l'argent sont deux des trois contraintes fixes d'un projet Agile. Notre objectif est de livrer dans un délai donné et dans le cadre d'un budget fixe donné.
• La qualité d'un produit fait référence au produit final utilisé par vos clients et aux pratiques d'ingénierie que votre équipe utilise pour fournir un logiciel performant, robuste et fiable. La qualité est aussi quelque chose que nous ne négligeons pas. Les critères de qualité, en revanche, peuvent changer. Si vous ne vous apprêtez pas à construire une Ferrari, le produit peut ne pas avoir une perception de haute qualité. Si vous ne construisez pas de fusées spatiales, les tolérances atteintes en termes de production peuvent être beaucoup plus élevées. Définissez le ton et les attentes appropriés dès le début.

Alors maintenant que vous avez confirmé que votre rêve est plus qu'une fantaisie chocolatée, commencez à tester vos hypothèses et à prouver aux gens que cette entreprise vaut la peine d'investir.

Justification

Maintenant, selon votre situation, la justification se présentera sous différentes formes. Mais essentiellement, vous voulez prouver que ce projet satisfera aux critères de réussite du client, a une chance de succès, apportera de la valeur et est abordable.

• Énoncez vos hypothèses en fonction des besoins de votre client, puis validez-les. Le Lean Startup donne d'excellents conseils pour identifier et prouver que votre produit est nécessaire à vos clients et qu'il créera de la valeur.

• Rédigez, testez et validez votre business plan. Maintenant, cela ne ressemble en rien à ceux que votre banque ou votre major en affaires et en finance vous a dit de produire. Ne les utilisez pas, ils seront périmés avant que l'encre ne soit sèche. Au lieu de cela, consultez le Business Model Canvas. Il s'agit essentiellement d'un plan d'affaires abrégé qui vous permet de vous concentrer sur votre proposition de valeur, vos clients, vos revenus et vos coûts. Utilisez-le pour valider si vous avez une entreprise qui fonctionnera.

  "J'ai ignoré ce conseil une fois et j'ai passé beaucoup de temps à rédiger un long plan d'affaires traditionnel de 50 pages. Cela ne m'a mené nulle part. Toutes les hypothèses que j'avais faites étaient infondées et toutes les projections que j'avais faites ne pouvaient pas être validées. Ce fut une expérience douloureuse et coûteuse qui m'a appris à ne plus jamais recommencer.

• Si vous êtes dans une entreprise mature avec des portefeuilles de projets livrés dans un environnement complexe, la modélisation financière peut être nécessaire. Si vous devez le faire, ne le faites qu'après avoir prouvé ce qui précède.
• Une fois que vous avez construit votre MVP, il peut être judicieux de créer un plan d'affaires plus traditionnel, par exemple, si vous devez rechercher un financement ou une sélection au sein du portefeuille de projets et de ressources concurrents de votre entreprise. Mais ce sera un plan d'affaires basé sur et informé par les outils utilisés ci-dessus. Ce sera aussi plus léger.
• Dans tous les cas, utilisez ces outils comme des artefacts vivants et respirants. Utilisez-les comme guide et guide. Ils ne sont jamais statiques. Consultez-les et révisez-les au fur et à mesure que votre projet ou votre entreprise évolue.

Une fois que vous avez votre justification et que toutes vos parties prenantes sont à bord, vous serez en feu.

La phase de faisabilité est généralement effectuée une fois dans la vie de votre projet. Il se peut que vous reveniez sur la vision et la faisabilité du projet, surtout si vos données, vos clients, votre marché ou votre entreprise l'indiquent. À tout le moins, ils seront vos phares tout au long.

Initiation

Impressionnant. La décision est prise, le projet a le feu vert et vous êtes prêt à construire. Eh bien, presque. Je sais que tu penses, « Allez déjà, vraiment ? Si nous ne le faisons pas maintenant, nous ne le ferons jamais. Mettons ce spectacle sur la route ! Mais considérez ceci : Agile ne consiste en rien sinon à fournir de la valeur tôt et souvent tout en ravissant vos clients en cours de route. Prendre le temps de trouver la meilleure façon de réaliser votre projet est la meilleure base pour réussir.

L'équipe

Dans le sport, en pensant à votre jeu d'équipe préféré, vous serez en mesure de reconnaître les rôles clés qui permettent à l'équipe de performer comme elle le fait. Traditionnellement, vous trouverez un manager, un capitaine et le reste de l'équipe. En dehors de cela, vous trouverez des entraîneurs, des physiothérapeutes, des nutritionnistes et un assortiment de personnel de soutien. Mais si on regarde le rugby, il y a une équipe dans une équipe : les joueurs qui composent la mêlée. Ce pack est composé de joueurs désignés dont le travail consiste à récupérer le ballon et à continuer à jouer. Lorsqu'une mêlée est en jeu, les joueurs de chaque côté travaillent alors, sans leader, comme une seule unité de manière aussi collaborative, communicative et efficace que possible pour récupérer le ballon en possession. C'est le jeu de rugby qui a inspiré Jeff Sutherland à nommer sa méthodologie de développement logiciel "Scrum".

• Scrum n'est pas la seule méthode de développement logiciel dans le playbook Agile. Mais c'est celui qui décrit le mieux le concept Agile et les comportements de travail en équipe, de motivation des individus, de création de relations de confiance, d'auto-organisation, de leadership-serviteur, de communication, de transparence et de collaboration.
• Votre équipe sera formée en grande partie par les circonstances dans lesquelles vous vous trouvez. Vous pouvez avoir des développeurs à votre disposition. Certains, aucun ou tous peuvent être familiers avec Agile à des degrés divers. Vous voudrez peut-être embaucher une nouvelle équipe ou vous associer à un tiers.
• D'autres rôles seront également nécessaires, mais nous en discuterons plus tard.
• Il a été dit que si vous formez votre équipe de développement, alors vous avez choisi votre technologie. Selon l'endroit d'où vous rassemblez votre équipe, ils viendront avec des compétences spécifiques. Alors, réfléchissez bien à la façon dont vous formez votre équipe de développement et si vous devez effectuer une évaluation technique avant d'en arriver à ce stade de votre parcours.
• Cela nous amène à des équipes interfonctionnelles. Les équipes fonctionnent mieux lorsqu'elles travaillent ensemble, lorsque les individus se mobilisent pour faire le travail, quel que soit leur titre. Essayez de construire une équipe qui se suffit à elle-même et des individus qui assument plus d'un rôle.
• Créez un environnement, une culture et un centre de relations, un endroit où l'équipe peut livrer, sans contraintes ni restrictions. Donnez à l'équipe les outils, les personnes, les ressources et l'espace nécessaires pour être efficace et performante.
• Gardez la taille des équipes à pas plus de sept ou huit. Si vous avez besoin de beaucoup plus de développeurs, divisez l'équipe en plusieurs nouvelles équipes. Chaque équipe pourrait alors être responsable d'un domaine fonctionnel donné. Si vous avez plusieurs équipes dans plusieurs endroits, envisagez d'organiser un Scrum of Scrums. Et là où ceux-ci sont nombreux dans des environnements complexes, utilisez la gestion de projet Agile.
• Assurez-vous que l'équipe, l'entreprise, les parties prenantes et même les clients ont accès les uns aux autres. Assurez-vous qu'ils communiquent et collaborent, et supprimez tout ce qui entrave la progression. La communication quotidienne est le meilleur remède aux maux du projet. Quand les gens parlent, ils font avancer les choses.

Il existe de nombreuses façons de constituer une équipe pour fournir un logiciel.

Résumé du projet

Dans l'étape de faisabilité, vous avez compris le "pourquoi" de votre projet et soit vous avez renforcé votre confiance pour aller de l'avant avec votre startup, soit vous avez obtenu le soutien nécessaire pour continuer. La fiche de projet est le document vivant qui rassemble le « pourquoi » avec le « quoi », le « quand » et le « qui ». C'est "vivre" parce que, à mesure que vous progressez, vos connaissances, votre compréhension et votre chemin peuvent changer. Quitter ce document une fois écrit et ne jamais y revenir ne fait que consigner vos pensées à un moment donné. Dans un monde Agile, votre référence ponctuelle peut changer chaque semaine ou même chaque jour au début, il est donc important de garder cela à jour.

• Un excellent outil pour encapsuler et maintenir votre brief de projet est quelque chose que Jonathan Rasmusson appelle le « deck de lancement » dans son livre The Agile Samurai . Ici, vous trouverez d'excellents conseils pour vous assurer que toutes les personnes intéressées, affectées ou impliquées dans votre projet sont sur la même page.
• Le plus grand ennemi de la réalisation de projets est d'avoir une compréhension peu claire, incohérente ou tout simplement différente de ce qu'est le projet et des «exigences» à satisfaire. Si même une partie prenante importante a une compréhension ou une vision différente de ce que vous faites, les conséquences peuvent être considérables.
• Un bon dossier de projet communique :
  1. Une attente commune et convenue entre les parties prenantes et les membres de l'équipe.
  2. Une compréhension du projet, avec la même compréhension pour toutes les parties.
  3. Le but, la vision, l'objectif, la portée et le contexte du projet.
• Vous aurez beaucoup de bonnes informations pour le mémoire recueillies à partir de la faisabilité. Le résumé du projet vous aidera à définir et à trouver les réponses aux questions de recherche. Il rassemblera les parties prenantes, votre raison d'être , la portée de haut niveau, les risques, la solution cible, le budget, le calendrier, les attentes et les priorités.

Un collègue m'a arrêté une fois dans un couloir et m'a demandé où il pouvait obtenir le dossier de projet pour le projet. J'ai plaisanté 'Nous n'avons pas besoin d'un brief, nous sommes agiles'. Il avait l'air confus, comme s'il remettait en question ma santé mentale ou mon autorité. Il avait raison de le faire.

Avant de continuer, assurez-vous que tout le monde est sur la même longueur d'onde, faites un atelier, posez les questions difficiles et clouez-le quelque part où les gens peuvent s'arrêter, le lire, le commenter et aider à le réviser.

Culture et méthodes de travail

Vous connaissez le fonctionnement de votre entreprise et sa culture, la façon dont elle aime faire avancer les choses. Agile, de par sa nature même, peut remettre en question certaines de ces méthodes de travail que votre entreprise a cultivées au fil des ans. Ne vous attendez pas à ce qu'Agile soit mis en œuvre et que tout le monde l'adopte avec amour dès le départ. Certaines personnes peuvent trouver cela déroutant et ne le voir qu'avec effroi et peur. Certaines personnes peuvent refuser ouvertement de s'y engager. Ce sont des défis et des perceptions que vous devez surmonter. Mais à vos débuts, ne vous promenez pas en agitant le bâton Agile en battant quelqu'un qui ne veut pas l'écouter. Cela ne renforcera pas la confiance, l'adoption ou l'engagement.

J'étais fan d'agiter de gros bâtons proverbiaux une fois, et cela m'a valu beaucoup de presse négative. Je l'ai retourné, mais pas avant d'avoir d'abord ressenti une douleur considérable.

Alors que vous vous engagez sur la voie de l'adoption, avancez prudemment, respectueusement et avec empathie. Si vous êtes dans une vieille entreprise traditionnelle grinçante, ce ne sera peut-être pas la meilleure approche pour aligner l'ensemble de l'entreprise. Commencez petit et gagnez progressivement le respect et la reconnaissance. Commencez avec votre équipe uniquement. Une fois que vous commencerez à fournir des logiciels plus rapides avec une meilleure qualité que jamais auparavant, les gens commenceront à le remarquer et voudront venir jouer à votre jeu. Lorsqu'ils le font, offrez-leur le ballon, emmenez-les prendre un café et faites-les entrer dans votre nouveau monde. Les aider à.

Avec votre équipe, maintenant qu'ils savent en quoi consiste le projet et que vos plans d'adoption Agile sont convenus, laissez l'équipe décider comment elle souhaite se comporter et fonctionner en équipe.

• Guidez votre équipe pour identifier les concepts, techniques, comportements et cadres Agiles qui, selon vous, correspondent à vos besoins collectifs.
• Répondez aux demandes des membres de votre équipe quant aux exigences dont ils disposent pour les aider à fonctionner au mieux de leurs capacités. Certaines de ces demandes, vous serez en mesure de résoudre immédiatement. D'autres, vous devrez peut-être obtenir un budget ou une aide extérieure. Faites ce que vous pouvez pour que cela se produise.
• Ce sont vos premiers pas pour devenir un véritable leader-serviteur.
• Envisagez d'organiser une formation appropriée sur les concepts et les techniques que votre équipe choisit d'adopter. C'est le meilleur moyen de vous assurer que tous les membres de votre équipe, même les parties prenantes, sont sur la même longueur d'onde et reçoivent le même message. Travaillez avec une organisation de fournisseurs qui peut adapter son offre à vos besoins.
• Soyez prudent. Personne ne sera un ninja Agile après quelques jours dans un atelier pour apprendre à devenir Agile. Votre chemin sera long. Le mot « devenir » est tout à fait déterminant. Ce n'est que lorsque vous adopterez vraiment Agile que vous verrez sa valeur. Cela devrait vous exciter. Si cela vous excite, alors allez exciter les autres aussi.
• Maintenant que votre équipe s'est mise d'accord sur les concepts et les techniques, que ses souhaits ont été exaucés et qu'elle est en formation Agile, tournez l'attention de votre équipe sur elle-même et sur ce qu'elle attend de vous, de l'entreprise et des autres.
• Définir certaines méthodes de travail (WoW) au sein et par l'équipe aide à renforcer la confiance, les relations et les attentes. Le WoW n'est pas la guerre et la paix . Il doit être court et précis, entre sept et dix phrases pointues. Ces phrases indiquent clairement comment les gens se comportent, communiquent, collaborent, soutiennent, livrent et performent ensemble. Il doit également indiquer ce que l'équipe attend de l'entreprise.

• Agile est autant un état d'esprit que des principes directeurs et des concepts. Il vous aide à développer votre façon de vous comporter, de penser, de négocier, d'interagir, de communiquer, de performer et de vous améliorer. Il repose sur des individus motivés qui se soutiennent mutuellement pour atteindre un objectif commun, ensemble comme un seul. Il y a un proverbe africain :

À présent, votre équipe devrait être super excitée, énergisée et motivée. Maintenant, engagez-les davantage avec votre carnet de récits d'utilisateurs.

Arriéré

N'ayez aucun doute dans votre esprit qu'il y a de l'incertitude dans votre projet. Vous ne pouvez pas savoir exactement ce qu'il faudra pour créer le bon produit pour vos clients si tôt dans sa vie. Vous ne pouvez pas regarder avec nostalgie dans une boule de cristal et prédire l'avenir.

Le «backlog» ou «product backlog» est l'endroit où résident vos exigences. Agile favorise la rédaction d'énoncés courts et concis qui capturent l'essence d'une « exigence ». Le backlog est simplement une longue liste d'entrées, chaque entrée définissant une « exigence » unique et discrète en tant que user story. Et à partir de maintenant, nous utiliserons le mot user story, et non « exigence ». Vous demandez probablement "pourquoi?" C'est une bonne question. Pendant ce qui semble être une éternité, l'énoncé des fonctionnalités ou des facettes nécessaires à un projet logiciel par un client a toujours été considéré comme une exigence. Ce mot a une interprétation qui n'a aucune valeur en Agile. Le dictionnaire Oxford le définit ainsi :

Une chose dont on a besoin ou qu'on veut. Ou, Une chose qui est obligatoire; une condition nécessaire.

Et malheureusement, si nous nous efforçons de définir ce que devrait être notre solution, en déclarant que les choses sont «obligatoires», nous finirons par avoir des ennuis. C'est trop facile de dire que toutes ces user stories sont obligatoires. Si nous adoptons ce point de vue, nous courons le risque de dépasser le calendrier et le budget en tentant de livrer l'ensemble d'une portée donnée. Ce n'est pas un problème de dire que, pour ce produit, ces histoires sont nécessaires pour que la solution soit viable, nous voulons simplement éviter l'interprétation de ce mot particulier.

• Écrivez toujours des histoires du point de vue d'un personnage. Un persona représente un utilisateur ou une partie prenante de la solution. C'est une bonne idée de développer ces personnages avant de commencer un backlog.
• À ce stade, n'écrivez que des déclarations courtes et simples qui suggèrent essentiellement un rappel pour avoir une conversation plus approfondie sur l'histoire de l'utilisateur lorsque le moment sera venu.
• Les vraies personnes pensent en termes de tâches qu'elles doivent accomplir pour atteindre un objectif. Écrivez vos histoires du point de vue de la personnalité et en termes de ce qu'elles doivent faire.
• Vous n'avez pas besoin d'écrire tout le backlog, écrivez simplement tout ce dont vous pouvez imaginer que vos clients auront besoin pour que votre produit soit viable.
• Vous découvrirez plus tard au cours de la vie du produit que les user stories changeront, deviendront plus ou moins importantes ou pourront être complètement supprimées. Le fait de publier souvent, d'obtenir des commentaires et d'évaluer ce qui est prioritaire informera ce comportement.
• N'écrivez pas des histoires isolément. Engagez votre équipe, vos parties prenantes et même vos clients. Les histoires peuvent être mises à jour à tout moment dans la vie d'un projet mais doivent éviter d'être modifiées une fois que le travail de développement a commencé sur celles-ci.
• Certaines de vos histoires peuvent être considérées comme des "épopées". Ce sont de grandes histoires qui couvrent beaucoup de choses et seront décomposées plus près du moment de la livraison en histoires plus petites.
• Envisagez d'utiliser le modèle INVEST, une liste de contrôle pour valider la qualité d'une bonne user story.
• N'importe qui peut ajouter une histoire au backlog. Il doit être placé en bas ou dans un «parking» spécialement créé. Cette histoire ajoutée sert d'incitation à discuter avec l'équipe et l'entreprise. Si l'entreprise et l'équipe le soutiennent, il peut alors être estimé et priorisé
• Vous pouvez également considérer les parties du système qui présentent le plus de risques. Si vous avez une user story ou une fonctionnalité complexe, nouvelle ou techniquement inconnue, donnez-leur la priorité en haut de votre backlog. De cette façon, vous n'essayerez pas de livrer les parties difficiles et critiques de votre produit quelques semaines seulement avant votre première version.

Une fois que vous avez un backlog qui répond à vos besoins, vous pouvez estimer les histoires qu'il contient, les classer par ordre de priorité et créer un plan de publication.

Estimation et priorisation de haut niveau

L'estimation de haut niveau est le processus de dimensionnement de votre backlog. Quelle est la « taille » du projet et quelle valeur apporte-t-il ? La priorisation est le processus qui consiste à décider quelles histoires sont les plus importantes pour vous, la viabilité du produit et les intérêts de vos clients. Nous voulons livrer les articles de la plus haute valeur le plus tôt possible pour offrir le plus de valeur à l'entreprise, obtenir les commentaires du client et ne pas transpirer les petites choses. Le résultat sera un carnet de commandes ordonné, classé par ordre de priorité et dimensionné de manière appropriée.

• Les histoires au sommet sont considérées comme les plus précieuses. Nous voulons livrer les articles les plus précieux le plus tôt possible.
• Il existe de nombreuses techniques de dimensionnement et d'estimation, mais à ce stade, vous souhaitez simplement avoir une bonne idée de la taille d'une histoire.
  • Utilisez des tailles de t-shirt, des tailles relatives, des jours idéaux ou des points d'histoire.
• Vous n'aurez pas non plus toutes les informations disponibles à ce stade, et ce n'est pas grave. Il suffit de courir avec.
• Engagez les parties prenantes de votre entreprise ou le chef de produit si vous en avez un, ainsi que l'équipe qui effectuera le travail.
• Nous voulons que ceux qui concevront, développeront et testeront le travail pour le dimensionner, car les meilleures personnes pour estimer sont les experts.
• L'équipe peut commencer à décomposer les histoires en parties plus petites. Si cela se produit, écrivez des histoires plus granulaires mais discrètes.
• L'équipe peut également commencer à classer certaines histoires, car naturellement certaines choses doivent être livrées avant d'autres pour prendre en charge la technologie ou un parcours utilisateur donné.
• Entre vous et l'équipe, vous pouvez également commencer à trouver des trous dans l'arriéré qui doivent être comblés. Remplissez simplement ces trous avec de nouvelles histoires et estimez et hiérarchisez le cas échéant.
• La hiérarchisation s'effectue plus facilement à l'aide d'une analyse MoSCoW. MoSCoW est une technique simple qui vous aide à décider quelles histoires sont « incontournables » pour que votre produit réussisse.
• Vous pouvez effectuer une passe de priorisation avant le début de l'estimation. Cependant, le dimensionnement de certains éléments peut également déterminer une décision sur la priorité et la valeur commerciale réelle. Alors jouez l'estimation et la priorisation l'une contre l'autre, mais ne vous querellez pas dessus !
• Aucune histoire ne peut être aussi importante que l'autre. L'histoire au rang 1 est plus importante ou précieuse que l'histoire au rang 2.
• Une excellente façon de démontrer l'importance ou la valeur d'une histoire est de lui ajouter une valeur monétaire. Si, par exemple, on pense que l'histoire A rapporte 5 000 $ de revenus supplémentaires et que l'histoire B peut attirer 100 $, alors l'histoire A a plus de valeur. De même, si l'histoire C sauve l'entreprise plus que l'histoire D, l'histoire C a plus de valeur.
• Une fois que vous avez dimensionné votre backlog, il vous restera un chiffre. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. La morale de l'histoire est la suivante :

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Planification adaptative

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Travailler par petits incréments a un énorme avantage. Cela signifie que vous vous concentrez uniquement sur l'avenir immédiat de la livraison et, avec de nouvelles entrées, commentaires et apprentissages, vous pouvez réagir au changement dans un court cycle itératif.
• Au début d'une version, effectuez un sprint 0. Cela permet à l'équipe, à l'entreprise et à la version de votre projet de se préparer et définit l'état d'esprit pour une livraison réussie. Dessinez le cadre technique et l'architecture de base qui prendront en charge la base de la version. Configurez des environnements, des comptes et des outils. Effectuez des pointes pour comprendre les problèmes difficiles ou inconnus. Élaborez vos user stories en vue du sprint 1. Le sprint 0 consiste à se préparer.
• Lors d'une release, continuez à affiner le backlog. Au fur et à mesure que vous en comprenez plus ou que vous apprenez quelque chose de nouveau, vos priorités peuvent changer, de nouvelles exigences peuvent apparaître et ce que vous pensiez auparavant être une fonctionnalité intéressante peut être entièrement supprimé.
• Ne commencez pas un travail qui n'a aucune chance de se terminer dans un sprint. Si ce n'est pas le cas, divisez-le en petits morceaux. Et ne commencez pas un nouveau travail lorsque le travail précédemment commencé n'est pas terminé. Vous ne créez aucune valeur en commençant beaucoup de choses qui ne peuvent pas être considérées comme complètes. De plus, évitez le changement de contexte. C'est l'activité de commencer une tâche, d'être dérangé, d'en commencer une autre et, dans sa forme la plus problématique, de ne pas terminer non plus.
• Limitez la quantité de travail en cours par l'équipe à tout moment. Par exemple, si vous avez trois développeurs et un testeur, vous pouvez imposer une limite WIP aux développeurs et au testeur.
• N'ajoutez jamais plus de travail à un sprint après qu'il a été planifié. N'arrêtez jamais un sprint en cours de route. Les exceptions à cela sont :
  • Si vous avez exécuté plus rapidement que prévu, envisagez de prendre l'histoire suivante à partir du haut du backlog, tant qu'elle est convenablement préparée.
  • Si le sprint fonctionne si mal qu'il ne se terminera pas. Cela ne se produit généralement que lorsqu'il y a eu une catastrophe d'une certaine description.
  • Si l'objectif de sprint ne peut plus être pris en charge en raison de l'évolution immédiate des besoins de l'entreprise.
• Si vous annulez un sprint, faites-le gracieusement, prenez le temps de vous recentrer et démarrez un nouveau sprint comme vous le feriez pour n'importe quel autre.
• Vers la fin d'une version, envisagez un sprint de version finale. Aucune nouvelle fonctionnalité n'est écrite, certains bogues peuvent être corrigés et des préparatifs peuvent être faits pour publier une nouvelle version de votre produit pour vos clients. Cela ne veut pas dire que vous ne pouvez pas faire de versions client incrémentielles entre-temps, c'est simplement qu'il s'agit d'un mécanisme de version contrôlé, mesuré et durable.
• À la fin d'une version, vous pouvez envisager un sprint d'une semaine. Dans ce sprint, vous pouvez travailler avec l'équipe pour décomposer de nouvelles idées ou découvrir de nouvelles technologies. Ce sont d'excellents outils qui profitent à l'entreprise, et cela donne à l'équipe un espace de briefing pour réfléchir et être créatif. Ce n'est pas pour faire des gaffes et cela créera toujours de la valeur. De même, tout le monde a besoin d'une pause. Prendre des vacances à ce moment-là aide à maintenir votre cadence et votre vitesse en bon état lorsque vous êtes à mi-course.

Définir Terminé

Définir ce que « fait » signifie vraiment est très important. Il existe de nombreuses versions de "terminé" dans la vie de votre projet - ce que signifie être "terminé" avec une histoire, une version ou un projet entier. Tout se résume à ce que vous, votre équipe et votre entreprise considérerez comme complet au bon niveau de qualité pour satisfaire la préparation à l'expédition.

Pour votre équipe, la définition d'une histoire "terminée" sera quelque chose comme tout le code complet, revu par les pairs, répondant aux critères d'acceptation définis, testé par unité, UAT et poussé vers votre référentiel de code. Pour permettre le passage d'une histoire du concepteur au développeur puis au testeur, les définitions de « fait » devront être acceptées par la personne suivante dans la chaîne. Votre propriétaire de produit aura des attentes quant à ce que cela signifie pour lui afin de proposer l'incrément de produit à vos clients. Dans tous les cas, tout le monde doit être conscient de ce que signifie « fait » et être une partie responsable pour s'assurer que sa signification est respectée. Définissez votre définition de « terminé », communiquez-la, mettez-vous d'accord dessus et faites-la évoluer. Fait fait.

Mesure continue

Si vous ne pouvez pas le mesurer, vous ne pouvez pas le gérer. Il en va de même pour les améliorations. Le besoin de rassembler des données empiriques dans un projet Agile est presque aussi vital que d'avoir du sang qui coule dans ses veines ! Comment savez-vous ce qui doit être géré, corrigé ou amélioré s'il n'y a pas de données ? Eh bien, tout simplement, vous vous fierez à votre intuition et à des suppositions non fondées, qui s'effondrent assez rapidement sous l'examen minutieux. Et selon qui fait le contrôle, cela peut être un endroit plutôt inconfortable. Donc, dès le début de votre projet, assurez-vous de savoir comment vous allez démontrer vos progrès et par quelles mesures les autres vont voir votre succès.

Heureusement, Agile est livré avec des outils et des techniques utiles. La première chose à faire est de revenir au Manifeste Agile, de taper les mots suivants dans votre traitement de texte préféré, de les agrandir à 96pt, de les imprimer et de les appliquer au mur pour que tout le monde puisse les voir :

Votre plus grand pouvoir démontrable dans la livraison de logiciels est de le montrer aux gens qui travaillent, font ce qu'ils sont censés faire. Non seulement cela rendra vos clients heureux, mais cela gagnera un grand respect à votre équipe et graissera les rouages ​​pour une plus grande adoption dans l'entreprise.

Voici quelques autres outils :

• Le stand-up quotidien : Il existe quelques variantes de cette cérémonie, mais l'essentiel est que tous les membres de l'équipe se parlent face à face : restez bref, restez concentré et restez léger. Si quelque chose nécessite une discussion approfondie, garez-le pour une conversation plus longue entre ceux qui sont nécessaires après le stand-up. Si des obstacles sont soulevés, écrivez-les comme une histoire, ajoutez-les à votre backlog et résolvez-les dès que possible. Tout ce qui entrave votre équipe ralentit sa progression et se manifestera par une vitesse réduite et un logiciel qui ne répond pas aux attentes.
• Vélocité : Est un outil historique. C'est un peu comme ces avertissements financiers qui disent que les performances passées ne préjugent pas des performances futures. Mais dans le cas d'Agile, nous espérons atteindre une vitesse d'équipe largement fluide. C'est la vélocité qui nous permet de projeter les performances futures et la confiance dans nos plans. Il peut y avoir des influences indépendantes de votre volonté qui pourraient réduire le nombre de points d'histoire générés pour un sprint donné. Si cela se produit, vous pourrez probablement récupérer. N'utilisez jamais la vélocité comme bâton pour battre votre équipe ; cela ne vous gagnera aucune faveur. Une chose est sûre, la vitesse sera erratique pendant les 2 à 4 premiers sprints. Quelque part au cours de cette période, cependant, vous devriez commencer à voir la cohérence et la stabilité. Si votre vélocité oscille d'un extrême à l'autre, vous avez un problème qu'il vous faudra régler avec votre équipe.
• Le burndown chart : Maintenant, cette mesure de progrès est épineuse. Pour cette raison, je n'ai pas donné de lien pour en savoir plus - vous devrez faire vos propres recherches et convenir en tant qu'équipe et entreprise de ce qui fonctionne pour vous. La raison pour laquelle c'est épineux ? Eh bien, aucune ressource ne raconte la même histoire ! Une chose convenue est qu'il montrera, dans un sprint ou une release, comment vous vous comportez par rapport à votre timebox. S'il est entretenu quotidiennement, il indiquera si vous êtes sur la bonne voie ou si vous déviez. Certaines équipes l'utilisent pour représenter la valeur qu'il reste à créer, le plus souvent, d'autres l'utilisent pour montrer la quantité de travail qu'il reste à accomplir. Le premier est une célébration du succès et de la création de valeur, le second est moins inspirant et motivant.
• Le burnup chart : Si vous devez afficher les taux d'achèvement des travaux, utilisez le burndown chart pour cela. Mais l'utilisation du burnup chart vous permet de montrer combien de valeur a été créée et combien de valeur supplémentaire vous prévoyez de créer d'ici la fin du sprint. Un outil beaucoup plus motivant pour une équipe pour à la fois montrer à l'entreprise ce qui a été fait (ou peu si ça va moins bien…) et ce qu'elle a encore en vue. Dans tous les cas, utilisez les graphiques pour repérer les progrès qui ne suivent pas comme prévu et recherchez des modèles ou des écarts et surmontez-les pour résoudre le problème sous-jacent dès que possible. Mettez-les à jour quotidiennement pour les sprints et une fois à la fin d'un sprint pour les graphiques des versions de publication.
• Tableaux de tâches : ce sont d'excellents radiateurs visuels pour démontrer la création de valeur. Lorsqu'ils sont mis à jour quotidiennement, ou à tout moment de la journée, ils montrent immédiatement les progrès réalisés. S'ils sont combinés avec Kanban, ils sont également d'excellents outils pour visualiser les flux et les blocages dans le système. Si vous constatez que de nombreux développements ont été réalisés, mais que les tests ne sont pas aussi productifs, vous pouvez voir le problème se produire et réagir de manière appropriée et rapide.

D'autres outils à considérer sont la valeur acquise Agile, le temps de cycle et les diagrammes de flux cumulés (CFD).

Gardez ces mesures, tableaux et autres outils visibles, de préférence bruyants et fiers sur un mur à la vue de tous. L'équipe, les parties prenantes et les autres parties intéressées peuvent voir immédiatement l'état d'un projet. Il est transparent et constitue un précieux outil de communication. Si vous ne pouvez pas mettre ces artefacts sur un mur, utilisez des outils partageables et collaboratifs et assurez-vous que ceux qui veulent y accéder l'ont.

Amélioration continue

Tout au long de votre vie Agile, cherchez à identifier et à apprendre où des améliorations peuvent être apportées. Les leçons ne sont pas capturées et apprises à la fin d'un projet. C'est comme réussir votre examen de conduite et tenter de faire votre premier trajet sans instructeur. Vous saurez ce qui fonctionne et ce que vous êtes censé faire, mais au fil du temps, vous adapterez vos compétences et capacités de conduite, en apprenant de nouvelles techniques. Vous prendrez même de mauvaises habitudes. Recherchez-les, comprenez-les et trouvez des moyens de vous améliorer.

Il existe de nombreuses possibilités d'identifier ce qui ne fonctionne pas et d'appliquer des solutions. L'approche intégrée à cela dans Agile est la rétrospective. C'est le principal outil de réflexion et d'ajustement. À la fin de chaque sprint, prenez le temps avec l'équipe d'améliorer la façon dont le travail est effectué, la qualité fournie, la manière dont l'efficacité peut être maximisée, la manière dont le gaspillage peut être minimisé et la manière dont la capacité est augmentée. Lorsque vous identifiez des mesures d'amélioration, ne soyez pas tenté de régler tous vos problèmes tout de suite. Identifiez ceux qui auront le plus d'impact et qui pourront être mis en œuvre lors du prochain sprint. Mesurez et observez. Si cela a eu l'impact souhaité, enfermez-le, écrivez-le dans vos méthodes de travail et vos définitions de terminé. Si cela ne fonctionne pas, détrompez-vous. Toutes les leçons apprises qui ne sont pas intégrées au sprint à venir peuvent être mises de côté et priorisées pour être prises en compte lors du prochain sprint.

Adaptez le processus. Supprimez tout ce qui ne fonctionne pas. Supprimer les obstacles. Votre maturité en tant qu'équipe Agile ne connaîtra pas de limites si vous la laissez faire.

Au-delà de la gestion de projet agile

Il est important de savoir ce qui se passe après la livraison du projet. Le support et la maintenance sont essentiels pour s'assurer qu'une fois le projet entre les mains des clients, il reste performant ; les commentaires des clients peuvent être pris en compte dans les futures versions ; et les problèmes des clients sont traités de manière appropriée. Un projet est une entreprise unique, limitée dans le temps. Le produit qu'il livre a une vie après la dissolution de l'équipe du projet. Assurez-vous que vous êtes capable de prendre en charge le produit une fois qu'il est en ligne.

Les projets agiles coexistent avec des approches plus traditionnelles. Concilier les exigences de maîtrise budgétaire et de visibilité des parties prenantes avec les objectifs Agiles de flexibilité et de réactivité.

Un cadre de gouvernance ou un modèle de gouvernance Agile est utilisé conjointement avec un processus Agile standard, tel que Scrum. Ils fonctionnent de deux manières spécifiques :

• Ils fournissent un wrapper pour un projet Agile en clarifiant les processus qui se produisent en dehors des itérations de développement (sprints). Cela comprend la fourniture de critères clairs pour la réussite du lancement du projet et la validation appropriée des décisions et du plan.
• Ils déplacent l'accent sur des parties spécifiques du processus Agile standard et mettent en évidence des principes et des techniques particuliers qui nécessitent une gouvernance ou une gouvernance de soutien.

Dans le monde d'aujourd'hui en constante évolution, les organisations et les entreprises souhaitent adopter une approche plus flexible pour la réalisation de projets et souhaitent devenir plus agiles. Cependant, pour les organisations réalisant des projets et des programmes, et là où des processus formels de gestion de projet existent déjà, le caractère informel de bon nombre des approches Agiles est intimidant et est parfois perçu comme trop risqué. Ces organisations axées sur les projets ont besoin d'une approche agile mature — l'agilité dans le concept de livraison de projet — la gestion de projet agile .

Apprenez et évoluez avec votre adoption d'Agile. Ne faites que ce avec quoi votre équipe est à l'aise, assurez-vous que sa voix est entendue et répondez à ses demandes. Encouragez votre équipe à adopter de nouvelles techniques plus utiles au moment opportun. Négociez avec l'entreprise et encouragez-la à comprendre ce que signifie être une organisation Agile.

Profitez du voyage.