Anti-patterns faisant échouer une transformation agile@scale

 

  Je vous partage le support que j'ai présenté lors de la conférence Agilenseine 2021.

Il porte sur les anti-patterns à identifier absolument, afin d'éviter de planter votre transformation agile@scale.

Le support est dispo sur mon slideshare: 

https://fr.slideshare.net/PierreMedina1/202109022-palawan17h15quels-sont-les-elements-qui-vous-font-rater-votre-transformation-agilescale

Etude annuel Agile@Scale (State of Agile Report) 2021

  

Comme tous les ans, je vous fais une consolidation des resultats de l'étude de Digital.ia (ex-versionone) sur l'utilisation des Framework Agile@Scale.

Je vous invite à vous reporter à l'étude 15 afin d'avoir plus d'informations sur le protocole de l'étude. Le présent article s'intéresse aux nombres bruts issus de cette étude.

Evolution 2015 à 2021

Les Frameworks d'agilité à l'échelle s'installent progressivement depuis 2010. Initialement tous ces Framework étaient utilisés indifféremment et avaient des stats d'utilisation équivalente.

Progressivement SAFe s'est imposé dans les entreprises. L'utilisation des principaux concurrents directs s'est "ecroulé" avec les années. 

Par exemple LeSS qui est un très bon concurrent et qui est complémentaire de SAFe (sur certains aspects que je ne développerais pas ici) ,s'est écroulé passant de 10-15% à ses débuts à 3% en 2021. Il est à noter que - même s'il a du mal à prendre au niveau de l'utilisation concrète dans les DSI - ce framework reste un des préférés de beaucoup de coachs agiles.

Depuis 5-6 ans on constate qu'un des Framework s'installe progressivement SAFe.

Tous les autres sans exception ont une utilisation qui tend vers les 2-3%.

Il est à noter que les réponses à cette étude sont assez hétéroclite. A la question: "Quel framework utilisez vous dans votre entreprise pour passer à l'échelle (agile@scale)?  On retrouve en réponse:

• Des méthodes de gestion de projet (Lean Management)
• Des recueils de bonne pratique (Spotify)
• Des outils comme le Scrum of Scrums qui est un des rituels que Scrum conseilles de mettre en place quand plusieurs équipes doivent collaborer, mais qui montre des limites d'utilisation au-delà de 4-5 équipes.
• Des Framework (SAFe , LeSS par exemple)

• etc...

L'avantage d'utiliser les frameworks étant d'avoir une réponse global et unifiée. D'où la complexité (apparente) de SAFe , car une DSI doit répondre à des défis de diverses natures qui ne peuvent pas etre couvertes que par de l'agilité, ou du lean, ou de la démarche produit, etc...  La plupart des items recensés dans la liste ci dessus focalisent sur un de ces problèmes alors que  SAFe par exemple essai - autant que possible-  d'apporter une réponse globale sur tout le processus d'ingénierie et de de création de valeur.

Zoom sur les 2 dernières années

Répartition 2020 (Etude 14)

Répartition 2021 (étude 15)

Evolution 2020 - 2021

Ces deux dernières années nous constatons que les tendances se sont confirmées, SAFe continue à progresser et s'installe en tete. Tous ses concurrents sont de moins en moins utilisés, en un an:

• Le Scrum de Scrum passe de 16% à 9%
• Entreprise Scrum passe de 4% à 6% (vraie augmentation ou simple fluctuation/bruit?)
• LeSS passe de 4% à 3%
• etc...

Mon explication du succès grandissant de SAFe

SAFe  se défini comme un Framework lean-agile. Il y a une soixante d'outils et bonnes pratiques utilisées par ce Framework (je vous avoue que je ne les ai pas comptés).

Ce qui est intéressant c'est qu'ils forment un ensemble homogène ou chacun de ses outils vient couvrir un besoin dans l'écosystème d'un programme ou d'une DSI.

Dans les outils mis à disposition il y a  une multitude de pratiques, Framework, méthodologies qui ont fait leur preuves depuis 20-30 ans dans le monde de l'ingénierie logicielle et de la business agility on trouvera:

• Le Framework Scrum pour l'agilité des équipes
• Lean Management pour l'optimisation des process (Lean Budget, Lean Portfolio Management, Lean User Expérience (Lean UX), Lean-Agile Leadership, etc...)
• Le design thinking pour l'idéation et le process de création de valeur
• Le DevOps pour la culture de responsabilité partagée entre les équipes de développements et les équipes Ops, Sécurité et prod,
• Le PI Planning pour la coordination et l'alignement des équipes
• Le Scrum of Scrums pour que les équipes se synchronisent
• etc...

Travaillant avec ces différents Framework depuis de nombreuses, je pense que SAFe  présente une caractéristique qui est à la fois sa force et sa faiblesse:  sa complétude le rend moins facile à déployer pour les coachs (juniors ou sans vraiment connaissance profonde du métier de ceux qu'ils aident à se transformer) qui seraient trop orientés sur les aspects agilité (Je rappelle que l'agilité est la colonne vertébrale du framework, mais n'est qu'un de ses aspects ).  

Si je peux me permettre un conseil pour conclure cet article (destiné à un DSI ou un manager désirant se lancer dans ce type de transfo): Pour déployer ce Framework -  qui peut être extrêmement efficace - il faut des coachs avec beaucoup de "bouteille" qui comprennent tous les aspects de l'ingénierie logicielle.

Pour l'année prochaine je surveillerai particulièrement Entreprise Scrum qui a fait un bond de +50% en 1 an ( de 4 à 6%)

N'hésitez pas à laisser des commentaires, ce sera un plaisir de répondre à vos questions (ou débattre sur certains aspects).

RDV l'année prochaine ... 

Attaque des Titans: Utilisation du Framework SAFe-like par le Bataillon d'exploration (Vidéo)

 Nous allons parler du manga "L'attaque des Titans" et allons décrypter la préparation et l'exécution par le "bataillon d'exploration" d'une opération utilisant des process quasi identiques à SAFe.

Ce manga est un des plus regardés et est classé systématiquement dans les classements des meilleurs Mangas par exemple ce classement  du site gentside : Manga: les 10 meilleurs manga de tous les temps

Le manga est tellement devenu célèbre que même le chef de l'État, Emmanuel Macron, en lançant le Pass Culture (Une aide de 300 euros pour tout jeune de 18 ans) en mai 2021, le président a utilisé une vidéo TikTok pour dévoiler l'offre destinée aux jeunes adultes.  La phrase d'accroche sur cette vidéo est "300€ pour le bataillon d'exploration". Une référence à ce manga et au bataillon de jeunes gens, qui combattent ensembles pour protéger l'humanité face à un danger qui met en péril son existence.

Le bataillon d'exploration est une unité combattante à laquelle fait partie Eren, le héros du Manga. Nous verrons dans la vidéo que ce bataillon à les dimensions d'un train agile SAFe et se comporte comme le framework SAFe préconise.

Nous allons nous aussi surfer sur la vague de ce manga.

En regardant ce manga avec ma fille de 18 ans, j'ai eu la surprise d'assister à la préparation d'une opération majeure et j'ai eu la surprise d'assister à un déroulé similaire en tout point avec le Framework SAFe (Scaled Agile Framework) utilisé pour agiliser de grands programmes. L'agilité à l'échelle n'est utilisable qu'à partir du moment où on a au moins 50 personnes qui collaborent ensembles.

Dans ce manga, la bataillon est composé de 100hommes et femmes. La trame de l'histoire en quelques mots:

• L'humanité vit depuis 100 ans à l'intérieur de murs pour la protéger
• à l'extérieur de ces murs, des êtres géants attaquent et tuent tout humain
• les humains ne savent pas d'où viennent ces êtres et jour après jour, ils perdent du terrain face à ces "monstres",  ces titans
• dans les extraits que je vais vous montrer, on est à un moment où des informations majeures sont localisées et le bataillon d'exploration monte une opération pour aller récupérer ces informations.

• Vous verrez dans cette vidéo que le bataillon applique scrupuleusement le Framework SAFe, des commentaires que j'ai inséré dans la vidéo vous permettront de bien faire le parallèle et de le comprendre.

En résumé:

•  Tous les membres du bataillon sont réunis pendant un certain temps pour préparer l'opération, ils sont alignés sur l'objectif, on leur transmet la vision de ce qui va être fait. (début du PI Planning)
• une sorte de board programme est exposé à toutes les équipes montrant le positionnement de chaque équipe et leur interaction ( dépendances, milestones)
• les équipes (Squad de moins de 10 individus) en fonction des instructions et de l'alignement, travaillent sur leur plan de déploiement ( Team Breakout au sein du PI Planning)
• l'armée met à disposition des squads des ressources leur permettant de realiser leur mission
• les équipes évaluent les risques se font des convictions et envisagent des actions (PI Planning / ROAMing des risques)
•  On voit que l'opération se déroule par phases similaires à des sprints, chaque sprint ayant un Objectif 
• D'autres squads externes au bataillon (externes au train SAFe) sont en dépendance (externe) et viennent l'assister par exemple pendant la traversée de la vieille ville. C'est l'équivalent d'équipes d'Ops, département technique, RH, Finances ou autres qui assisterait un programme sur différents volets.
• Au niveau des rôles on voit que les officiers se comportent soit comme des PM SAFe (ont la vision globale, la stratégie, pilote le train, décident des releases, prend les décisions orientant le train).  D'autres officiers ont un rôle plus proche du RTE et des Scrum Masters. Ils s'assurent que l'exécution du plan se déroule bien. Ils n'ont pas la décision de changer les orientations, juste de s'assurer que tout le monde reste sur les rails.
•  Les membres des squads sont animés de valeurs similaires à celles promues par Scrum (sur lequel SAFe s'appuie pour l'agilité d'équipe) soit: le courage, le focus sur l'objectif, l'engagement personnel et collectif, le respect de ses coéquipiers et l'ouverture vis à vis des challenges et du travail à realiser.

La vidéo dure un quart heure mais n'est pertinente que si elle est regardée complètement). 

Le reste dans la vidéo ;)

(à voir en plein écran avec le son)

Evolution de l'utilisation des Frameworks de 2015 à 2020

 

Comme tous les ans, VersionOne devrait sortir courant Avril son étude sur les pratiques agiles dans les entreprises à travers le monde.

Je vous propose de faire un zoom sur l'utilisation des Framework d'agilité à l'échelle.

  SAFe s'installe seul en première place et confirme la tendance déjà observée les années précédentes.

  D'autres Framework, pourtant très prometteurs comme LeSS, font le buzz auprès des coachs mais d'années en années ne parviennent pas à décoller.  

  Si le sujet vous intéresse,  sur l'utilisation de SAFe (le framework qui s'installe solidement en 1er place) en France, je vous invite à lire l'état des lieux fait par Michel Levaslot sur un post linkedin:    Etat des lieux du deploiement de SAFe en France en Janvier 2021

  Ces tendances seront elles confirmées en 2021?  Rdv en Avril pour la prochaine édition de l'étude de VersionOne

Source: 14th Annual State of Agile Report 

Inspect and Adapt

     

Overview du Rituel 

Toutes les parties prenantes du train se réunissent pour partager l’avancement du train et les « succès ». Ils réfléchissent sur les axes d’améliorations et identifient des plans d’actions cohérents, avec des porteurs nommés. C’est la rétrospective du PI écoulé.

QUI?

• Animé par le RTE. 
• Les participants sont toutes les parties prenantes ayant une interaction avec le train.

QUAND ?

• 1 fois par PI.

DUREE?

• Jusqu'à une demi journée.
• Le rituel est animé par le RTE.

Déroulé

PRÉ – REQUIS 

Les indicateurs des sprints pertinents que l’on a à disposition (burndown, débit, TTM...), le compte rendu du dernier Inspect & Adapt et des rétrospectives.

ATTENDUS

Le meeting est considéré comme terminé lorsque nous pouvons répondre aux questions suivantes :

• Quelles sont les améliorations que nous avions décidé de réaliser lors du précédent I&A ? 
• Est-ce qu'elles ont été terminées ? 
• Quels ont été leurs effets ?
• Quelles sont les améliorations que nous décidons de réaliser pour le prochain Program Incrément ?

TAKE AWAY

Au début de chaque réunion un responsable de la rédaction du CR est identifié

• Redescendre l’actualité auprès de l’équipe

System Démo

     

Overview du Rituel 

On y présente la dernière livraison cumulée et terminée de toutes les équipes, sur le sprint écoulé.

Elle est indispensable pour permettre aux parties prenantes et aux représentants utilisateurs de valider les nouvelles fonctionnalités du produit.

QUI?

Animée par le PM. Les participants sont tous les « stakeholders », l’équipe et les représentants des utilisateurs finaux.

QUAND ?

• 1 fois par Sprint.
• Le dernier jour de chaque fin de Sprint.

DUREE?

• 1h00.
• Le rituel est animé par le  RTE.

Déroulé

PRÉ – REQUIS 

Un environnement / support à jour avec toutes les Features et les User Stories terminées sur le sprint écoulé.

ATTENDUS

Le meeting est considéré comme terminé lorsque les points suivants ont été parcouru :

• Avancement : ce qui va être démontré et ce qui ne sera pas démontré
• Démo : des nouvelles Features et US terminées
• Discussion : des évènements principaux ayant eu lieu pendant le sprint
• Présentation : des principales US / Features arrivant dans le(s) prochain(s) sprint(s)
• Indicateurs : partage des indicateurs et des grandes tendances de l’équipe

TAKE AWAY

Un CR contenant le journal de décisions sur les validations obtenues.

ART Sync

     

Overview du Rituel 

ART Sync est une fusion du Scrum de Scrum et du PO Sync. Il est convoqué quand l'engagement global n'est plus tenable et d'importants ajustements sont nécessaires. 

Lors de ce rituel, le Program Board est mis à jour selon les engagements planifiés et réalisés. Les acteurs clés du PI se synchronisent.

La matrice des risques ROAM est passée en revue. Si des obstacles sont identifiés comme « bloquants », un plan d’action, avec porteur, est mis en place.

QUI?

• Animé par le RTE. 
• Les participants sont le RTE, les PM, les PO, les SM et l’architecte, management.

QUAND ?

• À la demande.
• 1 fois par semaine quand cela est nécessaire

DUREE?

• Jusqu’à 1h. 
• Le rituel est animé par le RTE.

Déroulé

PRÉ – REQUIS 

L’ART Sync est alimenté par les CR des rituels PO Sync et Scrum de Scrum.

ATTENDUS

Le meeting est considéré comme terminé lorsque nous avons parcouru les points suivants :

• Partage des risques et ROAMing en séance (tous les risques résiduels doivent être adressés)
• Revue de l'avancement et de l'engagement
• Prise de décisions sur les irritants/ alertes/ obstacles permettant d’atteindre l’objectif
• Mise à jour du tableau des adhérences 

TAKE AWAY

Au début de chaque réunion un responsable de la rédaction du CR est identifié

• Redescendre l’actualité auprès de l’équipe

Scrum de Scrum

 

Overview du Rituel 

Le Scrum de Scrums est destiné à synchroniser l’ensemble des acteurs organisationnels sur le déroulement du PI en cours. Les Scrum Masters se réunissent autour du Program Board pour partager l’avancement de leur équipe respective, les points de blocages, et le suivi des risques. Ils confirment ou non si l’engagement planifié est tenable. 

QUI?

• Animé par le RTE.
• Les participants sont les SM de chacune des Team.

QUAND ?

• 1 ou 2 fois par semaine. (selon divers éléments dimensionnant)

DUREE?

• Max 20 minutes (au delà se poser la question de la nécessité de convoquer l'ART Sync)
• Le rituel est timeboxé par le RTE.

Déroulé

PRÉ – REQUIS 

Pour que le rituel se déroule dans les meilleures conditions :

• La synchronisation se fait devant le Program Board
• Les Dailies sont faits régulièrement avec chaque équipe
• Ils ont pris connaissance des actualités de l'équipe
• Ils ont identifié les irritants, alertes

ATTENDUS

Chaque SM doit répondre à 4 questions :

• Qu'a fait l'équipe dont je fais partie depuis la dernière synchronisation ?
• Quelles sont les difficultés rencontrées depuis la dernière synchro (résolues ou en cours) ?
• Qu'est ce que l'équipe doit faire dans les jours qui viennent ?
• Est ce que l'équipe est confiante sur son avancée et le respect de son engagement ? Qu’est ce qui remet en cause ses engagements (risques, obstacles etc.) ?

TAKE AWAY

Au début de chaque réunion un responsable de la rédaction du CR est identifié

• Redescendre l’actualité auprès de l’équipe

PO Sync

    

Overview du Rituel 

Les PO se retrouvent pour se synchroniser sur les priorités produit et partager sur les réalisations. Ils révisent les priorités de développement des produits si besoin est.

QUI?

• Animé par le PM.
• Les participants sont les PM, les PO et le RTE (+ tout acteur pertinent pour l'avancée des sujets abordés)

QUAND ?

• 1 fois par semaine.

DUREE?

• 1h00.
• Le rituel est animé par le PM et RTE.

Déroulé

PRÉ – REQUIS 

Les acteurs présents viennent tous avec la matière alimentant les échanges afin de :

• Synchroniser les acteurs fonctionnels sur le déroulement du PI en cours 
• Partager l’actualité avec le métier
• Aligner tous les PO sur les échanges en cours avec les Epics Owner et Business Owner
• Evaluer l’avancement des backlogs pour les sprints et cadences suivantes

ATTENDUS

Un état des lieux des sujets en cours :

• % d’avancement sur le grooming du sprint suivant
• Une liste d’actions 

TAKE AWAY

Au début de chaque réunion un responsable de la rédaction du CR est identifié

• Redescendre l’actualité auprès de l’équipe

PI Planning

   

Overview du Rituel 

Le PI Planning est l’équivalent d’un Sprint Planning mais à l’échelle d’un train ( ou Programme). 

Il sert à aligner les backlogs des équipes d’un même train autour d’une vision et d’objectifs communs. On communique, explique et planifie les travaux à venir sur le PI.

QUI?

• Animé par le RTE pour l’évènement ; par les PO et SM au niveau des Team.
• Toutes les parties prenantes, de près ou de loin, ayant une relation avec le produit.

QUAND ?

• 1 fois par PI (10 ou 12 semaines selon durée de l'itération).
• Le premier jour de chaque fin Program Increment (PI).

DUREE?

• 2 jours consécutifs.
• Le rituel est animé par le RTE secondé par les SM.

Déroulé

PRÉ – REQUIS 

Un travail préparatoire doit être fait par :

• les Business Owners (BO), Epic Owner et le top management qui préparent et partagent la vision métier, les défis, les nouvelles opportunités en relation avec les prochaines évolutions
• les PM et PO qui préparent et présentent le top 10 des Features
• les Architectes qui préparent et présentent les impacts les prochaines évolutions sur l'architecture
• la System Team et l’architecte préparent et présentent les sujets sur les pratiques d'ingénierie

ATTENDUS

A l'issue des 2 jours les équipes devront avoir stabilisés 3 livrables :

• La planification pour le prochain Program Increment soit les 10 (ou 12) prochaines semaines
• Les objectifs de cadence équipe par équipe validés par le BO
• Les risques irritants résiduels

TAKE AWAY

• Au début de chaque réunion un responsable de la rédaction du CR est identifié. 
• La planification pour le prochain Program Increment soit les 10 (ou 12) prochaines semaines
• Les objectifs de cadence équipe par équipe validés par le BO
• Les risques irritants résiduels

Pour creuser le sujet: https://www.scaledagileframework.com/pi-planning/

(Agile Team) Backlog Grooming/Refinement/Maturation

   

Overview du Rituel 

Le backlog Grooming permet de prendre connaissance, débattre, prioriser, découper, et affiner les Features et les User Stories pour les prochains sprints.

QUI?

• Animé par le PO. 
• Les participants sont l'Agile Team, le PO et le SM.

QUAND ?

• 1 fois par Sprint.
• N'importe quand dans le Sprint

DUREE?

• Jusqu’à 1h30. 
• Le rituel est timeboxé par le SM.

Déroulé

PRÉ – REQUIS 

Une liste d’US analysées en Backlog Grooming sur lesquelles un travail de conception et découpage en tâches par composant a été fait.

ATTENDUS

Le but du Team Backlog Grooming est que les équipes prennent connaissance des US à venir. 

Les US sont intégralement découpées en tâches.

Le meeting est considéré comme terminé lorsque nous avons parcouru les points suivants :

• Est-ce que tous les participants ont compris le but des User Story sélectionnées ?
• Est-ce que les questions nécessaires pour lever les incertitudes éventuelles ont été posées ?
• Quelles sont les préoccupations (techniques, fonctionnelles, politiques, de calendrier…) autour de cette User Story ?
• Quelle est la solution technique à mettre en place pour répondre aux conditions de validation ?
• Quels sont les composants impactés par cette solution ?
• Est-ce que le découpage en tâches est validé par l’équipe ?

TAKE AWAY

• Le journal de décision.

Le petit +

Les Enablers techniques, sont maturés/groomés dans une instance en amont de celle-ci. Ils sont également priorisés.

Sprint / Iteraction Retrospective

  

Overview du Rituel 

La Rétrospective permet à chacun de s’exprimer sur le vécu le sprint. C’est un outil efficace pour solutionner des problèmes au sein de l’équipe qui n’auraient pas été identifiés sans ce temps dédié. 

QUI?

• Animé par le SM. 
• Les participants sont la Agile Team, le PO et le SM.

QUAND ?

• 1 fois par Sprint.
• Le dernier jour de chaque fin de Sprint.

DUREE?

• Jusqu’à 1h30. 
• Le rituel est timeboxé par le SM.

Déroulé

PRÉ – REQUIS 

Les indicateurs des sprints pertinents que l’on a à disposition (Burndown, débit, TTM...), les compte rendu des dernières rétrospectives.

Des modèles de rétros variés existent – n’hésitez pas à solliciter les coachs en fonction des problématiques que vous souhaitez traiter.

ATTENDUS

Le but de la rétrospective est de prendre un peu de temps pour se concentrer non pas sur le "quoi" (ce qu'on va réaliser) mais sur le "comment" (la façon de le réaliser). Ressortir avec une liste concrète d'améliorations possibles est une clef de l’amélioration continue.

Le meeting est considéré comme terminé lorsque nous pouvons répondre aux questions suivantes :

• Quelles sont les améliorations que nous avions décidé de réaliser lors de la précédente Rétro ? 
• Est-ce qu'elles ont été terminées ? 
• Quel a été leurs effets ?
• Quelles sont les améliorations que nous décidons de réaliser pour le prochain sprint ?

TAKE AWAY

• Au début de chaque réunion un responsable de la rédaction du CR est identifié. 

Le petit +

L'équipe vote pour les améliorations qu'elle estime être les plus importantes. 

Il faut se concentrer sur un petit nombre d'améliorations par sprint (1 à 3 max) et faire en sorte qu’elles soient pragmatiques (quelque chose de réalisable en quelques heures). 

Les actions sélectionnées sont assignées à un responsable et sont ajoutées au tableau des risques.

Sprint Review / Demo

 

Overview du Rituel 

La Démo est indispensable pour permettre au Product Owner de valider une nouvelle version du Produit. 

Elle permet à l’équipe de bien s’accorder sur la vision produit/service. 

QUI?

Les participants sont l’équipe soit l'agile Team, le SM, et le PO. Ce rituel et ouvert à tout Stakeholder de l'entreprise ayant interet à suivre vos travaux (Métier, autres PO, Managers, etc...) .

QUAND ?

• 1 fois par Sprint.
• Le Vendredi de chaque fin de Sprint.

DUREE?

• Jusqu’à 1h00. 
• Le rituel est timeboxé par le SM.

Déroulé

PRÉ – REQUIS 

Un environnement / support à jour avec toutes les Features et les User Stories terminées pendant le sprint.

ATTENDUS

Le meeting est considéré comme terminé lorsque les points suivants ont été parcouru :

• Avancement : ce qui va être démontré et ce qui ne sera pas démontré
• Démo : des nouvelles Features et US terminées
• Discussion : des évènements principaux ayant eu lieu pendant le sprint
• Présentation : des principales US / Features arrivant dans le(s) prochain(s) sprint(s)
• Indicateurs : partage des indicateurs et des grandes tendances de l’équipe

TAKE AWAY

• Journal de décisions sur les validations obtenues.
• Lors des discussions avec les clients/métiers, en cas de demnde d'ajustement, recuperer la matiere et s'assurer d'injecter les nouvelles actions dans le backlog du Produit.

Daily Stand Up Meeting

 

Overview du Rituel 

Le Daily StandUp  Meeting ne prend que quelques minutes quotidiennement et permet de réagir au plus vite pour éviter l’effet tunnel au sein du sprint. 

L'equipe se challenge jour aprés jour sur son engagement de sprint. Le moindre evenement mettant en danger l'engagement detecté dot être traité immédiatement.

Pensez à organiser un meet after avec les personnes concernées pour creuser les points de blocage potentiels/existants.

QUI?

Les participants sont l’équipe soit l'Agile Team, le SM, et le PO.

QUAND ?

• 1 fois par jour.
• Idéalement en présentiel, à une heure récurrente.

DUREE?

• Jusqu’à 15min. 
• Le rituel est timeboxé par le SM.

Déroulé

PRÉ – REQUIS 

Chacun vient avec un état des lieux des sujets sur lequel il travaille.

ATTENDUS

Le rituel est considéré comme fini lorsque chaque membre de l’équipe a répondu à ces 3 questions :

• Qu’ai-je fait hier ?
• Est-ce que je rencontre des problèmes pour finaliser mes tâches actuelles ?
• Ais-je besoin d’aide ?
• Qu'ai-je prévu de faire aujourd’hui ? 
• Quel est mon niveau de confiance sur mes engagements en cours ?

TAKE AWAY

Mise à jour du management visuel.

Sprint/Iteration Planning

Overview du Rituel 

Le Sprint Planning est déterminant dans la réussite du sprint à venir, il permet :  

• au PO de partager et clarifier ses attentes auprès de l’équipe
• à l’équipe de bien s’accorder sur la manière de réaliser les actions dans les deux semaines à venir

QUI?

L'organisateur est le PO, il le co-anime avec le SM. Les participants sont la Dev Team, le SM, et le PO

QUAND ?

• 1 fois par Sprint. 
• Par exemple le premier Mardi de chaque Sprint soit deux fois par mois.

DUREE?

• Jusqu’à 1h30. 
• Le rituel est timeboxé par le SM.

Déroulé

PRÉ – REQUIS 

100% des cartes envisagées pour le sprint découpées en tâches. 50% des cartes passées en 3 amigos.

ATTENDUS

Le meeting est considéré comme terminé lorsque nous pouvons répondre aux questions suivantes :

• Si le but de ce sprint était le titre d’un article, quel serait-il ?
• Quelle est la composition et la capacité de l’équipe pour ce sprint ?
• Quels sont les items du backlog avec la plus forte business value ?
• Est ce que ces items répondent bien aux critères INVEST ?
• Planning Poker
• Quelles sont les préoccupations (techniques, fonctionnelles, politiques, de calendrier…) autour de ces items ?
• Quels sont les obstacles que l’on décide de supprimer dans le prochain sprint ?
• Quelles sont les stories, conditions de validation, tâches et estimations qui vont former le sprint backlog ?
• Etant donné tout ce que l’on sait aujourd’hui, quel sprint backlog l’équipe prévoit et s’engage à terminer ?

TAKE AWAY

• Le CR. 
• Au début de chaque réunion un responsable de la rédaction du CR est identifié.

Pour aller plus loin...

Dans un contexte SAFe, ce rituel permet de revenir sur la planification effectuée en PI Planning pour affiner les choix et les estimations.

Rituels d'un train SAFe (Programme et équipes)

 

Il y a 2 niveaux de rituels: équipes et programmes en transverse des équipes.

Les rituels d'équipe sont:

• Sprint / Iteration Planning
• Daily Standup 
• Sprint / Iteration Review
• Sprint / Iteration Rétrospective
• Grooming / Maturation
• 3 amigos

Les rituels transverse/programme

• PI Planning
• PO Sync
• System Demo
• Grooming/Maturation
• Inspect & Adapt

Pour chaque rituel nous décrirons:

• Quel est l’objectif ?
• Qui l’organise ?
• Qui y participe ?
• La durée et la fréquence ?
• Quels sont les prérequis ?
• Quels sont les attendus ou livrables de sortie ?

Business Analyst

 

Description du rôle

Le Business Analyst, véritable « associé » du PO sur la chaine de valeur de la gestion de projet, le Business Analyst est avant tout en charge de prendre le relai du PO afin de décliner les phases de développement en faisant l’interface entre les clients internes et les équipes de développement.

En synthèse le Business Analyst...

• Supporte l'essentiel de l'effort d'élaboration des exigences

• Apporte une bonne compréhension des produits et des systèmes en conseillant sur l’analyse des besoins, le MVP

• Inclue les parties prenantes nécessaires pour comprendre les besoins

• Élabore les critères d’acceptation pour les US

Activités du Business Analyst

En tant que Business Analyst, j’accompagne le PO et l’équipe dans les développements pour satisfaire au mieux les besoins des clients.

• En binôme avec le PO, j’identifie et je priorise des exigences des différents métiers concernés par les créations / évolutions de ces fonctionnalités
• Je participe à la rédaction des User Stories adaptées, voire les traduire, si nécessaire, en spécifications détaillées
• J’intègre les contraintes techniques dans l’élaboration des spécifications
• Je communique fréquemment avec les développeurs afin de réduire les itérations le plus possible
• J’obtiens des Epic Owner et Business Owner la validation des développements réalisés
• Comme un chef d’orchestre, je maintiens un stock suffisant de « User Stories » en amont de la phase de développement pour garantir la continuité dans le rythme des livraisons des fonctionnalités

Testeur / QA

   

Description du rôle

Le Testeur:  en testant plus tôt, plus régulièrement des morceaux de fonctionnalités, il accroît la qualité, la stabilité et facilite le maintien des applications. 

En synthèse le testeur...

• Participe aux cérémonies 

• Contribue à l’automatisation des tests

• Teste les User Stories et les Features 

• Aide à estimer les User Stories 

Activités des testeurs

En tant que testeur, je suis intégré à la Team et j’appartiens à la communauté de test.

• Je participe aux cérémonies et je m’installe à côté de la team
• J’aide à estimer les US en apportant ma vision testing
• Je participe à la définition des tests d’acceptance lors des réunion « 3 Amigos »
• Je travaille à partir des tests d’acceptance : 
• Rédaction en Gherkin
• Préparation des tests dans Xray et des jeux de données
• Exécution
• Reporting dans Jira et Confluence
• Capitalisation dans Xray
• Identification des tests à automatiser
• Je travaille aussi sur les tests d’intégration, les tests de bout en bout
• … sans oublier les tests de non régression
• J’encourage les développeurs à identifier et à automatiser les tests unitaires
• Je pair-test la fonctionnalité avec le développeur

Agile/Dev Team

  

Description du rôle

L'Agile / Dev Team est une équipe pluridisciplinaire et autonome dans son mode de fonctionnement. Elle est en charge de la réalisation du produit/service. Elle est composée de 4 à 9 personnes maximum selon Scrum et entre 7 et 11 selon SAFe. On peut parler de ‘‘Feature team’’ ou de ‘‘pizza team’’.

En synthèse l'équipe...

• Réalise les actions selon l’ordre de  priorité donné par le PO

• Assiste à tous les rituels équipe pour donner de la visibilité au PO et se coordonne lors des Daily Meetings

• Présente les résultats du sprint lors de la démo

Activités des equipiers

En tant qu’équipier j’applique les principes de l’Agilité dans mon travail quotidien dans le but de maximiser la valeur produite et la qualité des applications.

• Je participe activement aux rituels Scrum avec mon équipe
• Les rituels et les pratiques de Scrum sont réalisés même si le Scrum Master est absent
• Je présente mon travail directement au métier au travers des démos
• Je participe à l’écriture des US au travers des Grooming organisés par le PO
• J’ai un bonne compréhension de ce que j’ai à faire, et du contexte dans lequel cela m’est demandé 
• Je remonte le plus rapidement possible les blocages au Scrum Master
• Je tente de résoudre un blocage avant de changer de tâche
• J’automatise mes tests (TU, TI)
• J’évalue et je m’engage sur le contenu des sprints
• Je cherche à améliorer l’organisation et les pratiques de mon équipe
• Lors des PI Planning, je comprends le travail des autres équipes et je propose des solutions pour les aider
• Je participe régulièrement à la “Crafts Academy”

Scrum-Master

 

Description du rôle

Le Scrum Master joue le rôle de facilitateur entre le Product Owner et la Développement Team. 

Le Scrum Master veille au bon fonctionnement de l’équipe et garantit la bonne application de la méthodologie Scrum. 

Il représente l'équipe dans les instances transverses. 

En synthèse le Scrum-Master...

• Garanti la méthode Scrum et sa bonne application
• Encourage l’équipe de développement (faisabilité des objectifs, gestion de la charge, coordination…)
• S’assure que l’équipe comprenne bien les demandes du PO et qu’elle soit bien synchronisée
• Suit les risques et interdépendances avec l’écosystème
• Suit la réalisation et les indicateurs de pilotage

Activités du Scrum Master

En tant que Scrum Master j’accompagne mon équipe dans la transformation et je la représente au sein du train dans le but d’avoir une équipe efficace et synchronisée avec les autres équipes du train

• J’anime les rituels Scrum (Daily, Sprint planning, Rétro)
• Au minimum 1 heure par sprint est consacrée à la rétrospective
• J’incite l’équipe à progresser dans ses pratiques sans lui apporter directement des solutions 
• Je suis les plans d’action établis lors des rétrospectives
• J’accompagne le PO dans sa gestion du flux des User Stories
• Je participe au Scrum de Scrum pour remonter au niveau programme les difficultés de l’équipe
• Je redescends à l’équipe toutes les informations échangées en Scrum de Scrum
• J’échange directement avec le RTE pour  résoudre les blocages de mon équipe
• Les rituels et les pratiques Scrum sont réalisés même si je suis absent
• Les évaluations de complexité sont réalisées par les équipes
• Je suis un acteur majeur de la fluidité du travail de l’équipe
• Je calcule les indicateurs d’équipes (vélocité…)

Le Product-Owner

 

Description du rôle

Le Product Owner (PO) est le garant du produit. 

Il porte la vision du produit et priorise l’ordre de passage des fonctionnalités à développer pour être au plus près des attentes des utilisateurs. 

Il allie métier et technique. 

Il fait évoluer le backlog d’équipe au fil de l’eau pour répondre au mieux aux besoins des utilisateurs.

En synthèse le PO...

• Récolte et consolide les besoins des utilisateurs
• Rédige les User Stories du Backlog produit, dont les règles détaillées et les critères d’acceptation
• Priorise les fonctionnalités à développer
• S’assure en permanence de l’adéquation du produit en cours de développement 
• Valide les réalisations de l’équipe
• Suit la réalisation et répond aux questions fonctionnelles

Activités du PO

En tant que PO, j’accompagne mon équipe dans ses réalisations pour le métier dans le but de donner du sens et de maximiser la valeur produite.

• Je rédige des User Stories claires et réputées “ready” par mon équipe
• Je passe du temps avec les développeurs pour m’assurer qu’ils ont bien compris le besoin du métier et les User Stories
• Je passe du temps avec les Epic et Business Owner pour définir le besoin (découpage, règles de gestion, sens de la demande…)
• Je passe du temps avec les Product Manager pour préparer le PI suivant
• J’ai une connaissance globale de ce qui va être réalisé dans le train
• J’ai compris ce que mon équipe a à faire sur le prochain PI
• Je délègue les évaluations à mon équipe (évaluation de la complexité…)
• Je délègue la conception à mon équipe en y prenant part
• Je tiens à jour un backlog priorisé pour toutes les activités de mon équipe
•  Je collecte, tiens à jour et partage les indicateurs fonctionnels sur le périmètre de l’équipe

Une equipe agile c'est... Autonomie, Responsabilité et Pluri-disciplinarité

 

Des engagements et des échecs collectifs

- Être aligné sur les mêmes objectifs et enjeux du développement de la solution

- Avancer par étape et progressivement pour valider avec les utilisateurs, la valeur ajoutée apportée

La connaissance des compétences et responsabilités de chacun

- Echanger sur les fonctionnalités autour du produit et des technologies

- Demander de l’aide avec le pair-testing, pair-development, pair-scrum master…

- Favoriser la construction d’un réseau et d’un maillage solide  de compétences plutôt que hiérarchique

De l’amélioration continue

- Trouver des solutions créatives pour être orienté problem solving

- Penser prototype, puis MVP, puis V1 pour faire évoluer la solution

- Explorer de nouvelles voies d’efficacité collective

Rôles clés

Rôles équipes agiles

• Product Owner
• Scrum Master
• Agile/Dev Team
• Développeur 
• Testeur / QA
• Business Analyst
• UI

Rituels

Il y a 2 niveaux de rituels: équipes et programmes en transverse des équipes.

Les rituels d'équipe sont:

• Sprint / Iteration Planning
• Daily Standup 
• Sprint / Iteration Review
• Sprint / Iteration Rétrospective
• Grooming / Maturation
• 3 amigos

Les 12 valeurs de l'agilité expliqués.

L'agilité se resume à  4 valeurs, 12 principes et un ensemble de bonnes pratiques.

Vous trouverez le détail sur le site agilemanifesto.org

Dans cet article nous passerons en revue ces principes en les explicitant.

Les 12 principes agiles

01. La satisfaction des utilisateurs

Pour améliorer la satisfaction des utilisateurs, livrez fréquemment un logiciel opérationnel contenant des fonctionnalités à grande valeur ajoutée.

Les équipes IT se plaignent souvent que les métiers ou utilisateurs changent trop souvent leur besoin. Dans mes accompagnements/transformations, je leur rappelle qu'elles ne travaillent pas pour elles mêmes, mais bien au service de clients/métiers/utilisateurs. Si client s'est trompé, a changé d'avis ou à affiné sa réflexion, il faut être en capacité de pouvoir l'accompagnement.

L'équipe doit avoir pour cela la bonne organisation et mindset pour pouvoir accompagner son client.

02. L’adaptation au changement

Dans un contexte complexe, volatile et incertain, accueillez positivement les changements de besoins, même tard dans la réalisation.

03. Les cycles courts

Bénéficiez de feedbacks fréquents pour mieux répondre aux attentes des utilisateurs. Les cycles courts permettent un meilleure gestion des risques et du budget.

Des cycles courts permettent aux équipes d'avoir un nombre important de cycles d'apprentissages lui permettant de s'améliorer régulièrement (cf principe 12)

04. Inclusion et co-construction

Favorisez les interactions entre toutes les parties prenantes dont le métier et la DSI. Rien ne bat une équipe agile : pluridisciplinaire, autoorganisée et autonome ! 

05. Un cadre de travail commun

Un environnement de travail propice à la collaboration, la transparence, et à la responsabilisation pour livrer le meilleur produit aux utilisateurs.

06. L’échange et la proximité

Une présence sur le terrain, la colocalisation et la communication face à face favorisent et fluidifient le dialogue, en stimulant le partage d’idées et de compétences.

07. Un logiciel opérationnel, adapté et bien conçu

Obtenir un logiciel utile, utilisable et désirable est un engagement collectif de tous les acteurs

08. Un rythme soutenable

Le rythme de développement doit être adapté à la capacité à faire des équipes pour être durable dans le respect des personnes et de la qualité de service attendu.

09. La robustesse et l’évolutivité

La qualité est non négociable. Favoriser constamment la qualité au détriment de la rapidité. Seule la qualité vous permettra de faire grandir votre activité commerciale.

10. La simplicité et l’expérimentation

L’art de minimiser la quantité de travail inutile est essentiel. Tout comme le développement itératif et incrémental de MVP qui permet de valider rapidement des hypothèses tout en délivrant de la valeur aux collaborateurs.

11. La confiance

Les équipes sont autonomes, responsables et s’autoorganisent dans un cadre qui favorise l’alignement vers un objectif commun et partagé.

12. L’amélioration continue

L’équipe réfléchit constamment aux moyens de s’améliorer pour atteindre les objectifs fixés et répondre aux mieux aux attentes des utilisateurs.

En résumé...

Pas d'agilité et ses vertus sans une application de ces 12 principes.