Scrum est un framework de gestion de projet Agile utilisé par les équipes de développement de logiciels pour collaborer. Il se base sur l’apprentissage par l’expérience, l’auto-organisation de l’équipe pour la résolution des problèmes, et la rétrospective périodique pour s’améliorer continuellement.

La méthodologie vient avec un ensemble de réunions, d’outils et de rôles qui interagissent de concert pour aider les équipes à structurer leur travail et à le gérer.

Dans cet article, nous verrons comment se compose le framework Scrum classique avec l’aide du Guide Scrum et comment ses concepts sont matérialisés sur Jira Software, l’outil Atlassian pour la gestion de projets.

Le framework

Scrum est un framework heuristique : il repose sur l’apprentissage continu et l’adaptation à des facteurs variables. Il se base sur le fait que l’équipe ne maîtrise pas tout au démarrage d’un projet et évoluera avec l’expérience. La méthodologie Scrum est structurée pour aider les équipes à s’adapter naturellement à l’évolution des conditions et des exigences des utilisateurs. La redéfinition des priorités et les cycles de livraison courts sont intégrés au processus pour permettre à votre équipe d’apprendre et de s’améliorer en permanence.

Même si Scrum est structuré, il n’est pas tout à fait rigide. Son exécution peut être adaptée aux besoins de n’importe quelle organisation. Cependant, afin de réussir sa mise en œuvre, la communication claire, la transparence et la volonté d’amélioration continue doivent rester les piliers de votre framework.

Artefacts Scrum

Les artefacts sont des outils créés pour résoudre un problème. Dans Scrum, ils sont au nombre de trois : le backlog produit, le backlog de sprint et l’incrément qui regroupe les tâches « terminées ».

• Le backlog produit est la liste principale des tâches à réaliser. Il est géré par le Product Owner ou le responsable produit. C’est une liste dynamique de fonctionnalités, d’exigences, d’améliorations et de correctifs qui fait office de point de départ pour le backlog de sprint. C’est la « to-do list » des équipes. Le backlog produit est constamment mis à jour, et ses priorités sont revues. Il est géré par le Product Owner qui le maintient en fonction de l’évolution du marché et du retour sur expérience de l’utilisateur.
• Le backlog de sprint est la liste d’éléments, d’user stories ou de correctifs de bug que l’équipe de développement a sélectionné en vue de leur implémentation dans le cycle de sprint actuel. Avant chaque sprint, une réunion de planification est organisée. Au cours de celle-ci, l’équipe choisit les éléments sur lesquels elle travaillera à partir du backlog produit. Un backlog de sprint peut être flexible et évoluer durant un sprint. Toutefois, l’objectif fondamental d’un sprint (ce que l’équipe souhaite atteindre à partir du sprint actuel) ne peut pas être remis en question.
• L’incrément (ou l’objectif de sprint) est le produit final exploitable qui a été obtenu pendant le sprint. L’« incrément » est présenté durant la démo de fin de sprint au cours de laquelle l’équipe montre ce qui a été effectué durant le sprint. Vous n’entendrez peut-être pas parler du terme « incrément », puisqu’il est souvent remplacé par la définition de « terminé » : une étape importante, l’objectif du sprint, voire une version complète de l’epic livré. Cela dépend de la façon dont les équipes définissent « terminé » et les objectifs de sprint. Par exemple, certaines équipes choisissent d’effectuer une livraison à leur client à la fin de chaque sprint. Pour elles, « terminé » signifie donc « livré ».Toutefois, cela peut ne pas être réalisable pour d’autres équipes. Par exemple, dans le cas où les livraisons client peuvent être opérées uniquement chaque trimestre. Les sprints sont de deux semaines, mais « terminé » est défini comme achever une portion d’une version plus large qui sera livrée par la suite. Il est utile de noter que plus vous avez besoin de temps pour livrer un logiciel, plus le risque qu’il puisse échoué est élevé.

Cérémonies Scrum

L’ensemble des cérémonies séquentielles que les équipes Scrum effectuent régulièrement constituent des composantes mieux connues du framework.

1. “Product Backlog refinement” : cet événement est sous la responsabilité du Product Owner. Ce dernier a deux tâches principales : faire de la vision du produit une réalité et rester constamment en ligne avec le marché et le client. Par conséquent, il tient à jour cette liste en s’appuyant sur le feedback des utilisateurs et de l’équipe de développement pour aider à définir des priorités et à maintenir un backlog propre et disponible à tout moment.
2. Planification du sprint : l’ensemble de l’équipe de développement planifie le travail à réaliser durant le sprint. Cette cérémonie est animée par le Scrum Master. À cette occasion, l’équipe détermine l’objectif du sprint. Les user stories sont ensuite ajoutées au sprint à partir du backlog produit. Ces stories correspondent toujours à l’objectif, et l’équipe Scrum s’accorde à dire qu’elles sont possibles à implémenter durant le sprint.À la fin de chaque réunion de planification, chaque membre de l’équipe Scrum doit savoir avec certitude ce qu’il est possible de livrer durant le sprint et comment réaliser l’incrément.
3. Sprint : un sprint désigne le délai défini par l’équipe Scrum pour terminer un incrément. Le délai classique d’un sprint est de deux semaines, mais il peut être d’une à quatre semaines. Ceci dit, plus le travail est complexe et plus les inconnues sont nombreuses, plus le sprint doit être court. Mais c’est à l’équipe de développement de voir. Le périmètre peut être renégocié entre le Product Owner et l’équipe de développement si nécessaire. C’est ce qui confère à la méthodologie Scrum sa nature empirique.Tous les événements, de la planification à la rétrospective, ont lieu durant le sprint. Dès lors que le délai du sprint est établi, il doit rester constant tout au long de la période de développement. L’équipe peut ainsi apprendre des expériences passées et appliquer ces enseignements aux sprints futurs.
4. Daily Scrum : mini-réunion quotidienne, rapide, de 15 minutes qui a lieu à la même heure le matin. L’objectif du « Daily Scrum » est de mettre tous les membres de l’équipe en phase avec l’objectif du sprint et de définir un plan pour les prochaines 24 heures.C’est l’occasion de faire part d’éventuelles préoccupations ou blocages concernant l’objectif du sprint.Le format de stand-up courant est de demander à chaque membre de l’équipe de répondre à trois questions sur la réalisation de l’objectif du sprint :• Qu’est-ce que j’ai fait hier ?
   • Qu’est-ce que je prévois de faire aujourd’hui ?
   • Y a-t-il des obstacles ?Le Daily Scrum a pour objectif de limiter les bavardages à une réunion quotidienne. L’équipe peut ensuite se concentrer sur son travail pendant le reste de la journée.
5. Revue de sprint : à la fin du sprint, l’équipe se rassemble afin d’effectuer une démo de l’incrément ou de l’inspecter. L’équipe de développement présente aux parties prenantes et à ses collègues les éléments du backlog terminés pour avoir leur avis. Le Product Owner peut décider de livrer ou non l’incrément.Cette revue est également l’occasion pour le Product Owner d’apporter des modifications au backlog produit sur la base du sprint actuel, lesquelles peuvent ensuite être intégrées à la session de planification du prochain sprint. Pour un sprint d’un mois, envisagez de « time-boxer » votre revue de sprint à un maximum de quatre heures.
6. Rétrospective de sprint : la rétrospective est l’occasion pour l’équipe de se rassembler afin de documenter ce qui a fonctionné ou non dans un sprint, un projet, des relations, des outils, chez des personnes, voire dans certaines cérémonies et d’en discuter. L’idée est de créer un espace dans lequel l’équipe peut se concentrer sur ce qui a bien fonctionné et sur les choses à améliorer.

Trois rôles essentiels pour la réussite de Scrum

Une équipe Scrum doit rassembler trois rôles : le Product Owner, le Scrum Master et l’équipe de développement. Et, comme les équipes Scrum sont pluridisciplinaires, l’équipe de développement comprend des testeurs, des concepteurs, des spécialistes de l’expérience utilisateur et des ingénieurs opérationnels, en plus des développeurs.

Le Product Owner Scrum

La priorité du Product Owner est de comprendre les exigences du business, des clients et du marché, puis de prioriser le travail de l’équipe d’ingénierie en conséquence. Le Product Owner efficace :

• crée et gère le backlog produit ;
• travaille en étroite collaboration avec le business et l’équipe pour s’assurer que tous savent en quoi consistent les tâches du backlog produit ;
• fournit à l’équipe des orientations claires sur les prochaines fonctionnalités à livrer ;
• décide du moment où le produit doit être livré, avec une prédisposition pour des livraisons plus fréquentes.

Le Product Owner fait en sorte que l’équipe de développement offre un maximum de valeur ajoutée au business. Il est également important que le Product Owner soit une seule personne. Aucune équipe de développement ne se réjouira de recevoir des directives différentes de plusieurs Product Owners.

Le Scrum Master

Les Scrum Masters sont les champions de Scrum au sein de leur équipe. Ils coachent l’équipe, les Product Owners et le business sur le processus Scrum et cherchent les façons d’affiner leur pratique en la matière.

Un Scrum Master efficace comprend parfaitement le travail que l’équipe doit réaliser et peut aider celle-ci à optimiser la transparence et le flux de livraison. En tant que chef d’orchestre, il prévoit les ressources nécessaires (humaines et logistiques) pour planifier le sprint, le stand-up, la revue et la rétrospective de sprint.

L’équipe de développement Scrum

Les équipes Scrum abattent le travail. Elles sont les championnes des pratiques de développement durables. Elles comptent généralement entre cinq et sept membres. Une façon de déterminer la taille de l’équipe consiste à suivre la règle des « deux pizzas » du PDG d’Amazon, Jeff Bezos : deux pizzas doivent suffire pour nourrir l’équipe.

Les membres de l’équipe présentent des compétences variées. Ils se forment les uns les autres afin qu’aucun ne devienne un goulot d’étranglement dans la livraison du travail. Les équipes Scrum efficaces s’organisent de façon autonome et adoptent une attitude du « nous » dans leur approche des projets. Les membres de l’équipe s’entraident tous afin de garantir la réussite du sprint.

L’équipe Scrum détermine le plan pour chaque sprint. Elle prévoit la quantité de travail qu’elle pense pouvoir assumer tout au long de l’itération en se servant de sa vélocité comme guide. En gardant une longueur d’itération fixe, l’équipe de développement bénéficie d’un feedback important sur son processus d’estimation et de livraison. Avec le temps, ses prévisions deviennent donc de plus en plus précises.

Scrum, Kanban et Agile

Scrum est un framework Agile si populaire que ces deux méthodologies sont souvent confondues l’une avec l’autre. Il existe toutefois d’autres frameworks, comme Kanban, qui est une alternative populaire. Certaines entreprises choisissent même de suivre un modèle hybride de Scrum et Kanban, appelé « Scrumban » ou Kanplan.

Scrum et Kanban utilisent tous deux des méthodes visuelles, comme le tableau Scrum ou Kanban, pour suivre l’avancement du travail. Tous deux donnent la priorité à l’efficacité et à la subdivision de tâches complexes en plus petits blocs gérables. Leur approche pour réaliser cet objectif diffère toutefois.

Scrum se concentre sur des itérations à durée limitée. Une fois la durée d’un sprint finalisée, les stories ou les entrées du backlog produit qui peuvent être implémentées durant ce cycle de sprint sont déterminées. Dans Kanban, le nombre de tâches ou la quantité de travail en cours (limite Work In Progress) à implémenter au cours du cycle actuel est fixé(e) au préalable. Le temps nécessaire pour implémenter ces fonctionnalités est ensuite calculé en remontant dans le temps.

Kanban n’est pas aussi structuré que Scrum. Hormis la limite Work In Progress, cette méthodologie est relativement ouverte à l’interprétation. Scrum intègre toutefois plusieurs concepts catégoriques dans le cadre de son implémentation, comme la revue de sprint, la rétrospective, la mêlée quotidienne (Daily Scrum), et bien d’autres. La méthodologie insiste également sur la transversalité, c’est-à-dire la capacité d’une équipe Scrum à ne pas dépendre de membres externes pour atteindre ses objectifs. Il n’est pas toujours simple de former une équipe transverse. En ce sens, Kanban est plus facile à adapter, alors que Scrum peut être considéré comme un virage fondamental dans le processus de réflexion et dans le fonctionnement d’une équipe de développement.

Mais, pourquoi Scrum ?

Le framework Scrum en lui-même est simple. Les règles, artefacts, événements et rôles sont faciles à comprendre. Son approche semi-normative aide véritablement à lever les ambiguïtés du processus de développement, tout en offrant aux entreprises la liberté suffisante pour ajouter leur propre touche.

L’organisation de tâches complexes en user stories gérables en fait la méthodologie idéale pour les projets complexes. Par ailleurs, la démarcation claire des rôles et les événements planifiés garantissent la transparence et la responsabilité collective tout au long du cycle de développement. Les livraisons rapides maintiennent la motivation de l’équipe et la satisfaction des utilisateurs à un niveau élevé, car il est possible de voir l’avancement dans un bref laps de temps.

Toutefois, la parfaite compréhension de Scrum peut prendre un certain temps, en particulier si l’équipe de développement est habituée à un modèle en cascade classique. Les concepts d’itérations plus restreintes, de mêlées quotidiennes (Daily Scrum), de revues de sprint et l’identification d’un Scrum Master pourraient s’avérer un virage culturel difficile à prendre pour une nouvelle équipe.

Toutefois, les avantages à long terme prévalent nettement sur la courbe d’apprentissage initiale. Le succès de Scrum dans le développement de produits logiciels complexes, quels que soient le secteur et le marché, en fait un framework attrayant à adopter pour votre organisation.

Si vous envisagez de mettre en place la méthode SCRUM, n’hésitez pas à nous contacter. Nos équipes constitués de consultants certifiés SCRUM et Atlassian ont à leurs actifs plusieurs projets mis en place avec succès et seront ravis de partager avec vous leurs retours d’expériences.

L’article Fonctionnent de la méthode Scrum est apparu en premier sur AZARA Consulting.

SAFe définit le cadre pour l’alignement, la collaboration et le delivery entre un grand nombre d’équipes agiles. Il s’articule autour de trois principaux blocs de connaissances : le développement logiciel agile, le développement de produits lean et la pensée systémique.

À mesure que les entreprises grandissent, SAFe apporte une approche structurée pour le scaling agile. Quatre configurations sont proposées en fonction du niveau de scale souhaité : Essential SAFe, Large Solution SAFe, Portfolio SAFe et Full SAFe.

Dean Leffingwell et Drew Jemilo ont lancé SAFe en 2011 pour aider les organisations à concevoir de meilleurs systèmes et logiciels qui répondent mieux aux besoins changeants des clients. À cette époque, les équipes utilisaient des processus de gestion de projet classiques pour livrer des logiciels. Mais à mesure que la nécessité de répondre rapidement aux conditions évolutives du marché augmentait, de nouvelles méthodologies ont émergé pour aider les entreprises à améliorer la livraison de solutions dans leurs entreprises : SAFe a vu le jour. Aujourd’hui, SAFe est l’une des méthodologies agile à l’échelle les plus utilisées, et la communauté mondiale de praticiens de SAFe continue de le faire évoluer.

Les principes et les valeurs fondamentaux

Valeurs fondamentales

Les valeurs fondamentales de SAFe décrivent la culture que le leadership doit favoriser pour réussir la mise en œuvre de la méthodologie.

Alignement

L’une des exigences de SAFe est la mise en place des cadences de planification et de réflexion à tous les niveaux de l’organisation. Une fois en place, tous les collaborateurs ont une idée claire sur l’état actuel de l’entreprise, les objectifs et le rôle de chacun pour atteindre ces objectifs. En synchronisant régulièrement les personnes et les activités, tous les niveaux du portefeuille restent alignés. Les informations circulent à la fois vers le haut et vers le bas en temps opportun, contrairement aux structures traditionnelles top down.

Qualité intégrée

Dans le cadre de la démarche SAFe, l’agilité ne doit jamais se faire au détriment de la qualité. SAFe exige des équipes à tous les niveaux qu’elles définissent ce que « done» signifie pour chaque tâche ou projet et qu’elles intègrent des pratiques de développement de qualité dans chaque contrat de travail. Selon SAFe, il existe cinq dimensions clés de la qualité intégrée : le flux, la qualité de l’architecture et de la conception, la qualité du code, la qualité du système et la qualité des livraisons.

Transparence

SAFe encourage la mise en place d’un climat de confiance et de transparence, notamment en planifiant le travail en petits lots afin que les problèmes puissent être identifiés plus tôt, offrant une visibilité en temps réel sur l’avancement de la backlog à tous les niveaux, ainsi que les rituels d’inspection et d’adaptation.

Exécution du programme

L’exécution du programme est au cœur de SAFe et soutient tous les autres aspects du framework. Les équipes et les programmes doivent pouvoir fournir régulièrement un service de qualité, des logiciels opérationnels et une valeur business.

Direction

SAFe requiert un comportement de leadership Lean/Agile, car seuls les leaders peuvent transformer le système et mettre en place l’environnement nécessaire pour inculquer toutes les valeurs fondamentales.

Principes SAFe

Les principes SAFe sont destinés à améliorer l’entreprise dans son ensemble en éclairant la prise de décision Lean/Agile au-delà des limites fonctionnelles et organisationnelles. Les principes visent à influencer non seulement les décisions des dirigeants et des responsables, mais aussi celles de tous les membres de l’organisation, et à les encourager à passer d’une pensée classique en waterfall à une pensée Lean/Agile, qui applique des pratiques telles que la gestion de portefeuilles Lean.

Principe n° 1 : Adopter une vision économique

D’après les théories sur le flux de développement produit tirées des best-sellers de Donald Reinertsen, chaque intervenant dans la chaîne de décision doit comprendre les implications économiques des retards pour obtenir le délai d’exécution le plus court possible. Il ne suffit pas toujours de livrer tôt et régulièrement. Selon SAFe, classer les tâches pour optimiser les bénéfices, comprendre les échanges économiques et travailler en respectant des budgets serrés sont autant de responsabilités qui doivent être communiquées à l’échelle de l’organisation. De nombreux concepts et outils sont tirés des théories de Donald Reinertsen sur le flux de développement produit.

Principe n° 2 : Appliquer une pensée systémique

SAFe encourage les personnes qui utilisent le framework à appliquer une pensée systémique sur trois axes clés : la solution elle-même, l’entreprise qui développe le système et les flux de valeur. Les solutions peuvent concerner des produits, des services ou des systèmes fournis au client, qu’ils soient internes ou externes à l’entreprise.

Les solutions d’envergure comportent de nombreux composants interconnectés. Les membres de l’équipe doivent avoir une vision d’ensemble pour savoir comment leur élément s’intègre dans la solution.

Les adeptes de SAFe doivent prendre en considération l’ensemble des acteurs de la chaine de réalisation de la solution, du système de management et des processus de réalisation. Ainsi, si une organisation cherche à optimiser les méthodes de travail, elle devra peut-être éliminer les silos, devenir transverse, et conclure de nouveaux accords de coopération avec les fournisseurs et les clients. Finalement, l’entreprise doit clairement expliquer comment la valeur passe du concept au financement dans les flux de valeur de développement de solutions. Les dirigeants et la direction doivent optimiser le flux de valeur au-delà des limites fonctionnelles et organisationnelles.

Principe n° 3 : Supposer la variabilité, conserver les options

Par défaut, la conception de systèmes et de logiciels est un exercice incertain. Ce principe répond à cette incertitude en introduisant le concept de « Set-Based Design » (design basé sur un ensemble), qui implique de garder plusieurs exigences et options de design pendant une période prolongée dans le cycle de développement. Le « Set-Based Design » s’appuie également sur des données empiriques afin de se focaliser sur la dernière option de design dans la suite du processus.

Le « Set-Based Design » aide à prendre des décisions éclairées en période d’incertitude en identifiant les options et les résultats escomptés, sur le même principe qu’un choix stratégique. Le concept visant à intégrer des « étapes importantes d’apprentissage » (qui font référence à la date limite pour prendre des décisions) joue un rôle clé dans le « Set-Based Design ». Plus les équipes apprennent au fil du temps, plus elles peuvent éliminer de choix. Plus elles éliminent de choix, plus il est facile d’identifier la meilleure voie à suivre et de produire le meilleur résultat possible pour les clients.

Principe n° 4 : Se développer de manière itérative à l’aide de cycles d’apprentissage rapides et intégrés

À l’instar du principe n° 3, ce principe aborde le risque et l’incertitude par le biais d’étapes importantes d’apprentissage. Il ne suffit pas que chaque composant du système soit fonctionnel, il faut tenir compte de l’ensemble du système pour évaluer la faisabilité des choix de design actuels. Les points d’intégration doivent être planifiés à intervalles réguliers, afin d’accélérer les cycles d’apprentissage. Ces points d’intégration constituent un parfait exemple du cycle PDCA (plan-do-check-adjust) de Walter A. Shewhart, un framework pour l’amélioration continue de la qualité et un mécanisme pour contrôler la variabilité du développement. Les travaux de Walter Shewart et ceux qu’il a inspirés se concentrent souvent sur SAFe.

Principe n° 5 : Baser les étapes importantes sur une évaluation objective des systèmes de travail

La démonstration d’un véritable système de travail constitue une meilleure base pour la prise de décision qu’un document d’exigences ou toute autre évaluation superficielle de la réussite. Inclure dès le départ les parties prenantes dans ces décisions de faisabilité permet de renforcer la confiance et encourage une pensée systémique.

Principe n° 6 : Visualiser et limiter le travail en cours (Work in Process, WIP), réduire la taille des lots et gérer la longueur des files d’attente

Limiter le travail en cours aide les parties prenantes à évaluer avec précision le déroulement des opérations.

Les trois éléments de ce principe représentent les principaux moyens d’optimiser le débit et d’accélérer la création de valeur ou, en d’autres termes, d’implémenter le « flux ». Comme le dit l’adage « Ne mettons pas la charrue avant les bœufs ».

En appliquant ce principe au développement logiciel, vous limitez le nombre de tâches se chevauchant, la complexité de chaque tâche et le volume total de travail à réaliser à un moment donné. La petite taille des lots permet de vérifier en permanence que le travail est sur la bonne voie. Et que la longueur des files d’attente est correctement gérée…

Ce principe vise à donner des conseils sur l’optimisation de ce processus en vue d’obtenir les meilleurs résultats.

Principe n° 7 : Appliquer la cadence, synchroniser avec la planification transverse

Les équipes Agile appliquent naturellement la cadence par le biais de sprints ou d’itérations. La création d’une cadence pour tous les sujets possibles réduit la complexité, répond à l’incertitude, développe la mémoire musculaire, renforce la qualité et incite à la collaboration. La synchronisation de ces cadences permet aux personnes et aux activités de fonctionner comme des rouages où les informations apprises éclairent les décisions et la planification incrémentielle.

Principe n° 8 : Susciter la motivation intrinsèque des travailleurs du savoir

Inspiré par le conseiller en gestion influent Peter Drucker et l’auteur Daniel Pink, ce principe est l’un de nos préférés ! Il permet de libérer le potentiel des équipes et aide la direction à adopter une approche de commandement et de contrôle pour coacher ses équipes et répondre à leurs besoins.

Principe n° 9 : Décentraliser la prise de décision

Réduire la longueur des files d’attente et adopter une approche économique en décentralisant la prise de décision confèrent aux équipes l’autonomie dont elles ont besoin pour accomplir leur travail. Les dirigeants doivent conserver leur pouvoir de décision pour les sujets stratégiques et permettre aux équipes d’opérer des choix éclairés sur tous les autres sujets.

Comment fonctionne SAFe ?

Les organisations prêtes à implémenter SAFe bénéficient généralement d’un parrainage au niveau de la direction, d’une forte volonté de changement et d’une base Scrum.

Scaled Agile, Inc. fournit une feuille de route pour implémenter SAFA, qui contient des étapes détaillées pour vous lancer et configurer l’organisation en vue de l’adoption générale dans tous les portefeuilles. Voici les 12 étapes de l’implémentation de SAFe :

1. Atteindre le point de bascule
2. Former des agents du changement Lean/Agile
3. Former des directeurs, des responsables et des leaders
4. Créer un centre d’excellence Lean/Agile
5. Identifier des flux de valeur et des Agile Release Trains (ART)
6. Élaborer le plan d’implémentation
7. Préparer le lancement de l’ART
8. Former les équipes et lancer l’ART
9. Préparer le lancement de l’ART
10. Lancer d’autres ART et flux de valeur
11. Étendre au portefeuille
12. Maintenir et améliorer

Comment SAFe se situe-t-il par rapport aux autres frameworks Agile à grande échelle ?

Bien que SAFe® soit largement adopté par les entreprises disposant de grandes équipes de développement, d’autres frameworks Agile à grande échelle ont gagné en popularité au fil du temps. Tous ces frameworks partagent cinq composants principaux : l’inspiration des 12 principes du manifeste Agile, la cadence, la synchronisation, Scrum et les pratiques de développement de qualité. Comprendre les origines des autres frameworks, les différences fondamentales et les conditions pour une application réussie permet aux organisations de sélectionner le framework qui répond le mieux à leurs besoins.

Vous souhaitez en savoir plus sur certains des principaux frameworks Agile à grande échelle ? Consultez la page de présentation Agile à grande échelle sur le coach Agile.

SAFe et Scrum@Scale

Dans Scrum@Scale (S@S), tout le monde fait partie d’une équipe Scrum interchangeable. En fonction de leurs objectifs, les réseaux d’équipes Scrum se rassemblent pour former un écosystème. L’objectif de S@S est de créer un réseau d’équipes Scrum grâce à une architecture « scale-free », ce qui signifie que les rôles et les événements Scrum de base sont mis à l’échelle de façon linéaire, sans introduire de nouvelle dynamique de processus. Par exemple, un Scrum de Scrums (SoS) peut ne pas être suffisant pour un produit très complexe comptant 25 équipes Scrum, donc un Scrum de Scrum de Scrums (SoSoS) avec un Scrum de Scrums Master (SoSM) peut être nécessaire.

Bien que S@S soit généralement moins normatif, il propose une question directrice afin d’aider les organisations à déterminer si elles sont prêtes à évoluer : si vous ajoutez d’autres personnes au système, les performances augmentent-elles de manière exponentielle ou la productivité en souffre-t-elle ?

Tout comme SAFe, S@S propose un contenu de référence en ligne, notamment un guide Scrum@Scale complet dont la popularité ne cesse de croître.

Le framework S@S est le plus approprié dans les cas suivants :

• La stack technique est orientée objet (c’est-à-dire que les user stories verticales peuvent être livrées en deux semaines).
• Les « feature teams » de l’organisation possèdent des compétences en forme de T, adoptent des valeurs axées sur le produit et gèrent un minimum de paperasse.
• Aucun outil Agile ou de gestion du cycle de vie Agile (ALM) n’est requis tant que les pratiques ne sont pas devenues une seconde nature.
• L’équipe de direction est prête à se familiariser avec Scrum et à lever les obstacles pour l’organisation.

SAFe et Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) adopte une approche minimaliste des rôles, de la structure et des artefacts. Alors que SAFe propose quatre configurations pour satisfaire des équipes de plus en plus grandes et offrant des solutions de plus en plus complexes, LeSS en propose deux : LeSS pour deux à huit équipes et LeSS Huge pour plus de huit équipes. LeSS se distingue également par sa position selon laquelle les Product Owners devraient disposer d’un contrôle complet sur le contenu et d’une influence stratégique, alors que SAFe encourage une approche plus démocratique. Et si SAFe s’accompagne de nombreux facteurs qui influencent la stratégie, LeSS met l’accent sur une approche orientée client axée sur les clients payants.

À l’instar de S@S, LeSS évolue depuis les événements, les artefacts et les rôles Scrum. SAFe et LeSS mettent tous deux l’accent sur la pensée systémique, la pensée Lean et d’autres principes directeurs similaires. LeSS, en revanche, met fortement l’accent sur la réduction du gaspillage dans l’ensemble de l’organisation, avec pour objectif une amélioration continue.

Le framework LeSS est le plus approprié dans les cas suivants :

• Les équipes Scrum maîtrisent Scrum.
• La direction cherche à se restructurer et à expérimenter en permanence pour le bien commun.
• Un alignement sur la définition du produit existe.
• Un alignement sur la définition de l’état « Terminé » existe.
• Des coachs externes travaillent avec des groupes d’équipes, organisationnels et techniques.
• Des « feature teams » et des « component teams » possédant des compétences en T sont disponibles.
• L’organisation cherche à se débarrasser entièrement de la gestion de projets.

SAFe et DA

Contrairement aux autres frameworks décrits, Disciplined Agile (DA) est un kit d’outils qui permet aux organisations de décider de la méthode de travail la plus logique pour s’y adapter. Il propose une gouvernance Agile légère, qui s’appuie sur Scrum et Kanban, ainsi que des connaissances en matière de transformation dans des domaines, tels que les RH et les finances, la gouvernance, la méthodologie DevOps ou la gestion de portefeuilles. DA implique l’utilisation de différents niveaux d’évolutivité pour chaque projet et met l’accent sur la capacité de prise de décision pour aider à orienter la direction stratégique.

Le framework DA est le plus approprié dans les cas suivants :

• Les organisations veulent définir leurs propres parcours Agile à grande échelle.
• Les organisations souhaitent rester flexibles au sein de l’entreprise.
• Les organisations entendent préserver les choix de processus et/ou de framework.

SAFe et Spotify

Le « modèle » Spotify est un ensemble de pratiques autonome et axé sur les personnes qui peut être appliqué pour coordonner les équipes Agile. Il n’a jamais été conçu comme un modèle ou un framework, mais certaines entreprises l’ont adopté en tant que tel. Spotify met l’accent sur les équipes auto-organisées, transverses et colocalisées appelées « squads » (l’équivalent d’une équipe Scrum). En comparaison, SAFe n’a pas de disposition de ce type sur la colocation des équipes. Elle est encouragée pour la planification d’incrément de programme.

Les squads sont organisés en unités plus importantes appelées « tribus ». Les dépendances entre les squads sont peu nombreuses et sont traitées par le biais d’un Scrum de Scrums lorsqu’elles se produisent. Le partage des connaissances est possible grâce aux « chapitres » et aux « guildes », et des groupes informels sont organisés en fonction des compétences et des intérêts.

Par rapport à d’autres exemples, où des ressources en ligne, des cours de formation et des certifications sont disponibles, les ressources sur le modèle Spotify se limitent à un blog accessible au public et à d’autres éléments complémentaires développés par ses pionniers et ses fans. Le modèle est de plus en plus populaire, il est donc probable que nous en verrons d’autres à l’avenir.

Le modèle Spotify est le plus approprié dans les cas suivants :

• Application des idées dans votre propre contexte commercial.
• La culture organisationnelle est axée sur l’apprentissage, la tolérance aux erreurs et la prise de risques contrôlés.
• Les équipes et les produits sont « légèrement couplés, étroitement alignés » pour éviter tout conflit de dépendance.

SAFe 5.0

L’un des principes fondamentaux du framework SAFe est qu’il continue à évoluer en collaboration avec sa communauté d’experts dans le monde entier. Récemment, Scaled Agile, Inc. a lancé la version 5.0 de SAFe. Les principaux changements comprennent l’ajout d’un 10e principe, « Organiser autour de la valeur », et le remplacement de l’étape 12, « Maintenir et améliorer », par « Accélérer ». Mais les implications sont bien plus nombreuses.

Conclusion

Les frameworks comme SAFe et ceux qui ont été évoqués ci-dessus constituent une option viable pour aider les entreprises à se développer efficacement au sein de leur organisation et à atteindre leurs objectifs commerciaux. Mais les outils que vous choisissez pour vous aider à amplifier les pratiques existantes et à en tirer pleinement parti sont tout aussi importants. Nos équipes sont à votre disposition pour vous présenter la solution Jira Align d’Atlassian, une plateforme de planification Agile d’entreprise développée pour SAFe. Grâce à Jira Align, vous pouvez améliorer la visibilité, l’alignement stratégique et l’adaptabilité de l’entreprise afin d’accélérer votre transformation digitale.

L’article Le scaled agile framework Safe : ses principes, fonctionnement et comparaison avec les autres frameworks Agile à grand échelle est apparu en premier sur AZARA Consulting.

Utiliser Trello et Confluence ensemble vous permet d’utiliser ces pièces pour illustrer une plus grande user story, d’organiser projet plus grand et de préparer un planning plus vaste. Mais comment les utiliser ensemble ? Utilisez Confluence pour créer et planifier votre vision, puis utilisez Trello pour travailler et agir sur les détails de l’éxécution de cette vision.

Pour en savoir plus sur la meilleure façon d’utiliser les deux applications, lisez la suite.

Ajouter des cartes ou des tableaux Trello aux pages Confluence

Confluence est l’endroit où vous construisez votre vision. Par contre, Trello vous permet de diviser cela en petites tâches est d’organiser leurs réalisations. Faites-les ensemble en intégrant vos cartes et tableaux de projets dans la documentation. 

En faisant ceci, vous obtiendrez :

• Une mise à jour en temps réel. Toutes les modifications apportées par vous, ou quelqu’un d’autre, à partir de l’un des outils de la suite Atlassian, seront immédiatement visibles. 

• Le respect des permissions. Avant de pouvoir voir une carte ou un tableau, on vous demandera de vous connecter à Trello. Tout contenu que vous n’avez pas la permission de voir affichera une note vous indiquant que vous n’avez pas encore l’accès nécessaire pour le voir.

Comment est-ce qu’on peut intégrer Trello à Confluence ?

Pour intégrer un tableau de projet Trello dans une page Confluence, c’est très simple. Copiez et collez l’URL de votre carte sur une page Confluence et regardez le rendu automatique dans une carte dès que la page est publiée.

Vous pouvez voir l’état de chacune de vos tâches, les commenter, vous abonner pour rester à jour sur les changements ou vous inscrire. Si vous avez besoin d’ajouter plus d’informations, il suffit de cliquer sur la carte. Cela vous mènera dans Trello, où vous pouvez modifier la carte comme d’habitude.

Cette possibilité d’intégration fonctionne également avec un tableau de projet. Les carreaux donnent un large aperçu de votre tableau, sans les détails approfondis. Utilisez-les pour garder le lien des documents ou des fichiers sur Confluence. Ensuite, lorsque votre équipe a besoin d’ajouter quelque chose à son tableau, elle peut cliquer sur le carreau pour l’ouvrir dans Trello.

Vous pouvez également ajouter des tableaux entièrement interactifs sur votre page Confluence. Choisissez le bouton “+” Trello Board, et après ajouter l’URL de la carte et la hauteur à laquelle vous voulez que votre carte soit embarquée. Cela affichera une carte de projet entièrement fonctionnelle sur votre page Confluence. De cette façon, vous pourriez déplacer les cartes d’une liste à une autre, ajouter ou modifier des détails et faire tout ce que vous feriez habituellement sur un tableau de projet, à partir de Confluence.

Ajouter des pages de Confluence aux cartes Trello

Évidemment, les intégrations vont dans les deux sens. En utilisant la puissance Confluence pour Trello, vous pouvez :

• Attacher les pages Confluence Cloud aux cartes des tâches et accéder à votre contenu depuis votre tableau en un seul clic
• Créer de nouvelles pages Confluence Cloud directement à partir des cartes.
• Voir toute l’activité sur votre page, qui a créé la page et quand elle a été créée, y compris un extrait et le nombre de commentaires sur la page, à partir de la carte Trello.

Quelques cas pratiques

Voici quelques exemples pratiques sur la façon d’utiliser Trello et Confluence ensemble de la manière la plus efficace :

• Gérer votre travail au sein de plusieurs équipes ou projets – Obtenez un aperçu du travail de vos équipes en intégrant chacune de leurs cartes de tâches sur une seule page Confluence. Idéal lorsque vous avez des équipes agiles et vous avez juste besoin de faire une vérification rapide sur les progrès de vos équipes.

• Faire un Brainstorming et partager des idées – Utilisez Confluence pour détailler un problème et des contraintes, puis utilisez Trello pour réfléchir aux solutions possibles.

• Planifier un projet avec Confluence – Ajoutez votre tableau de projet à la page de planification du projet afin que votre équipe et d’autres intervenants puissent suivre vos progrès.

• Créer de la documentation dans Confluence – Utilisez Trello pour planifier votre architecture d’information, afin de pouvoir déplacer des sous-sujets d’un sujet parent à un autre.

• Travailler sur des tâches – Conservez tous vos documents et fichiers connexes dans Confluence, et intégrez les cartes Trello correspondantes sur chaque page. Ensuite, lorsque vous faites des progrès, il suffit de commenter la carte Trello à partir de Confluence.

L’article Trello et Confluence : comment les utiliser ensemble ? est apparu en premier sur AZARA Consulting.

Un monde de services

Commençons par un exemple que nous pouvons tous comprendre : pensez à votre smartphone dont vous ne vous séparez jamais. Bon nombre de vos applications et services sont très utiles voir indispensables en cette ère numérique actuelle. 

Nous sommes en train de passer de la création de produits à la création de services ! Il suffit de considérer la transition la transition qui s’est oppéré dans le monde de la mobilité : on est passé d’un monde où les gens étaient propriétaires de leurs voitures à un monde où plusieurs services comme Uber ou Heetch rendait possible la mobilité à la demande.

Les nouvelles générations ne voient pas la possession d’une voiture comme un symbole de statut. Au lieu de cela, ils sont à la recherche d’un moyen pratique pour se rendre d’un point A à un point B, et cela a des conséquences de grande portée pour chaque organisation et chaque équipe.

Réfléchissez à ce que ce paysage numérique en rapide évolution signifie pour les entreprises et les équipes informatiques chargées de fournir ces services. Pour réussir, chaque équipe informatique se concentre aujourd’hui sur les applications et les services numériques qu’elle fournit à ses clients.

Nous connaissons tous les histoires de la transformation incroyable des services numériques qui a eu lieu avec des entreprises comme Amazon, Google ou Airbnb.

Mais nous assistons également à une transition majeure pour les entreprises traditionnelles comme Macy’s, Marriott et ING, pour n’en nommer que quelques-unes. Les services numériques sont un aspect essentiel des produits et services historiques qu’ils offrent à leurs clients. Et ils ont dû évoluer très rapidement dans la façon dont ils sont commercialisés au risque de devenir obsolètes. 

Prenons un exemple : Marriott a 600 000 chambres et existe depuis 97 ans, tandis qu’Airbnb a 900 000 chambres et a été lancé il y a 8 ans. Ces changements ont une incidence sur la façon dont les équipes opérationnelles, logicielles et informatiques travaillent ensemble.

Les défis des outils ITSM pour les équipes IT

L’ITSM est l’optimisation de la prestation de services pour fournir de la valeur aux clients sous la forme de services. Les outils traditionnels de ITSM ont tendance à être lourds et rigides, sans possibilité de personnalisation, ce qui les rend difficiles à s’adapter aux besoins de plus en plus spécifiques des équipes IT. 

Il existe également des outils différents pour les divers processus informatiques qui créent des obstacles et un manque général de visibilité entre les équipes, ce qui finit par étouffer l’agilité, la collaboration et l’innovation. 

En outre, nous constatons souvent que le libre-service est déficient ou inexistant parce que les solutions ITSM traditionnelles rendent difficiles le déploiement et la gestion. Sans oublier que les utilisateurs finaux n’aiment pas les utiliser parce qu’elles ne sont pas intuitives.

Enfin, les outils ITSM traditionnels ne sont généralement pas intégrés aux outils de développement de logiciels. Ce qui rend le travail des équipes IT encore plus difficultés à cause d’au moins trois contraintes : 

• Incapacité de coordonner avec les équipes de développement.
• Difficulté de faire le lien entre les anomalies en production et l’avancement des corrections par l’équipe de développement.
• Absence de visibilité après avoir remonté des anomalies.

L’approche d’Atlassian dans l’ITSM

Comme chacun le sait, le processus est important pour les équipes informatiques. C’est pour cela que plusieurs frameworks et bonnes pratiques ont pour objectif d’apporter une « guideline » à l’ensemble des activités des équipes IT. Par exemple, ITIL (Information Technology Infrastructure Library) est considéré comme en est le pionnier.

Cependant, et malgré le fait que les équipes informatiques ont réalisé la valeur significative d’ITIL, ceux-ci trouvent que les outils classiques ITSM sont difficiles à adapter à leurs processus ITIL. Selon Doug Tire de la HDI Industry Insider, les clients qui se sont «sérieusement engagés à améliorer leur maturité en tirant parti de la librairie ITIL pendant une période de deux à trois ans ont vu une réduction de 50 à 75% du travail non planifié pour les services critiques, 10 à 25% de gains de productivité du travail et une amélioration de 20% dans les enquêtes de satisfaction client ». Cependant, le manque de compatibilité de l’ITIL et des outils hérités laisse aux équipes informatiques le sentiment de devoir modifier leur processus de support plutôt que d’avoir une solution informatique qui s’adapte à leurs besoins.

Les clients qui se sont «sérieusement engagés à améliorer leur maturité en tirant parti de la librairie ITIL pendant une période de deux à trois ans ont vu une réduction de 50 à 75% du travail non planifié pour les services critiques, 10 à 25% de gains de productivité du travail et une amélioration de 20% dans les enquêtes de satisfaction client »

Doug Tire de la HDI Industry Insider

L’approche d’Atlassian dans l’ITSM

Lorsque la plupart des organisations pensent à un « outil de centre d’assistance », elles ne font que « capturer » les incidents et les demandes de service de la part des clients. La gestion des problèmes et des changements nécessite généralement des modules distincts (et même des outils distincts), et les intégrations entre ces modules sont généralement loin d’être simples à réaliser. 

Au lieu de cela, Atlassian aborde l’ITSM en partant des besoins du projet et facilite la collaboration des équipes IT en temps réel. Grâce à cette approche axée sur les projets, les organisations disposent d’une solution unique où les équipes se concentrent sur leur cœur de métier tout en gardant leurs propres flux de travail, schémas de données, écrans et rapports, et tout en donnant une visibilité de bout en bout à la gestion des systèmes d’information. 

En plus de cela, Il n’y a pas de courbe d’apprentissage supplémentaire ni d’intégrations supplémentaires entre les modules. Vous pouvez créer des projets qui relient les tickets aux incidents qui y correspondent, et également aux demandes de changement. Un projet dans l’approche Atlassian représente donc une division logique des données et des processus pour aider les équipes IT à acquérir une organisation sans précédent.

Présentation de Jira Service Management

Jira Service Management est au cœur même de l’approche Atlassian de l’ITSM. Propulsé par la plateforme Jira, Jira Service Management est spécialement conçu pour les équipes IT et constitue le service desk le plus collaboratif du marché. Et pour appliquer les bonnes pratiques DevOps, Jira Service Management accorde une grande valeur à la transparence afin que les équipes puissent abandonner l’état d’esprit «silo» et adopter une communication ouverte et effiace entre ses membres. Grâce à cette approche, les équipes IT et celles du développement logiciel collaborent mieux et communique plus souvent pour résoudrre les problèmes plus rapidement. La raison est qu’ils disposent des bonnes pratiques et outils pour relier, suivre et automatiser la gestion des incidents plus facilement. Tout le monde a une visibilité complète sur la file d’attente et les meilleurs experts de chaque domaine peuvent collaborer à chaque fois pour résoudre les problèmes plus rapidement. En conséquence, les développeurs et les équipes d’infrastructure IT ont plus de temps pour se concentrer sur la conception et création de meilleurs logiciels et services.

Pourquoi les clients modernes utilisent Jira Service Management ?

Jira Service Management est également reconnu comme un leader des logiciels de centre de services par G2Crowd, devant les fournisseurs traditionnels tels que BMC et ServiceNow.

Voici les qualités qui expliquent pourquoi les entreprises adorent utiliser Jira Service Management ?

1. Facile à utiliser et à configurer : portail intuitif en libre-service, qui facilite la demande de support, la recherche dans les bases de connaissances et le suivi des progrès sur les anomalies et incidents.
2. S’intègre à Jira Software : associez les tickets Jira Service Management aux problèmes Jira Software et gardez le développement et le service informatique connectés pour une résolution rapide des problèmes.
3. S’adapte à vos besoins : un logiciel flexible qui en charge tous les types de résolutions, de remontées de niveau ou de processus de changement dont vos équipes informatiques pourraient imaginer.

L’article ITSM : Les meilleures pratiques d’Atlassian est apparu en premier sur AZARA Consulting.