Support du meetup du 10 octobre

Vous trouverez les 2 supports du dernier meetup que j'ai animé chez Ingima à Paris.

Présentation générale : https://lnkd.in/gKy5Xvb et Présentation de la nouvelle version 4.6 : https://lnkd.in/gqGMQD8

Lean-Agile Leadership, valeurs, principes et roadmap

Le Servant-Leader 

 La partie de SAFe décrivant la pratique Lean-Agile Leaders explique comment les "managers" doivent accompagnent les équipes au quotidien. La première chose est de faire pivoter le rôle classique de manager vers le rôle de Servant Leader (Je vous invite à creuser le sujet grâce à cet article de Wikipedia sur le Servant_leadership.)

  Les Lean-Agile Leaders conduisent et soutiennent le changement organisationnel en permettant aux individus et aux equipes d'atteindre leur plus haut potentiel.

  Ces Servant Leaders forment continuellement, exposent, enseignent et encadrent le mindset, les valeurs, les principes et les pratiques Lean-Agile de SAFe. (cf Lean-House) 

La maison Lean House

Les concepts SAFe Lean-Agile se basent sur des croyances, des suppositions et des actions des managers et dirigeants + techniciens (au sens large) qui adhérent aux concepts du Manifeste Agile et de la SAFe House of Lean.

Cette maniére de penser est la base intellectuelle du leadership amenant à l'adoption et l'application des principes et pratiques de SAFe.  Un état d'esprit Lean-Agile comporte deux aspects formalisés dans le manifeste Agile et la Maison du Lean.

  L'approche Lean est illustrée par la Maison du Lean:

• Le toit représentent l'objectif de tout projet: la livraison d'une valeur à un client
• Les piliers représentent le respect des personnes, les flux, l'innovation et les améliorations continuelles afin d'atteindre le plus efficacement l'objectif.
• Les lean-agile leaders / Servant Leaders sont le socle sur lequel tout l’édifice est basé.

Les principes agiles sont l'autre fil conducteur: SAFe repose sur sur les valeurs, principes et méthodes agiles incarnés par les équipes agiles organisés en Feature Teams ( équipes inter disciplinaires). LeSS défini d'ailleurs les Features Team plus en profondeur, je vous conseille d'en prendre connaissance si le sujet vous interesse: Less feature-teams Definition

Les 9 principes

Les Lean-Agile Managers doivent s’assurer du bon respect des principes.
Je vous invite à lire cette autre page de mon blog où je fais un zoom sur ces principes: Decryptage des 9 principes Lean-Agile SAFe

Sans le respect des ces principes, vous ne pouvez prétendre tirer partie des bénéfices attendus d'un framework tel que SAFe. En résumé: il faut tout ou ne reprendre. Le non respect d'un de ces principes vous fait penser que vous faites du SAFe mais ce ne sera qu'en apparence.

SAFe Implementation Roadmap

  Cette roadmap permet à une organisation d'avoir un chemin tracé pour implémenter efficacement la transformation de cette dernière vers une Entreprise Lean-Agile. Elle permet d'identifier à quel moment former les Servant Leaders, recruter les bons profils, mettre en place les premiers trains et

Accompagnement par un SPC

La mise en place des projets à l’échelle et la transformation que cela nécessite au sein de l'entreprise sont pilotés par des principes et processus complexes.  Je vous recommande vivement de vous faire accompagner par un bon SAFe Program Consultant (SPC) certifié. Il sera le garant que rien d'essentiel n'est oublié.

Mon retour d’expérience

Un leadership solide et bienveillant est le socle d'une transformation réussie.
Travaillant régulièrement dans des projets à l’échelle et dans des organisations qui essaient de mener des transformations vers l'agilité, je vois souvent des managers qui ne comprennent pas bien les principes et le mindset de l'agilité (pour les petits projets) et du lean-agile pour les grands. Ces personnes pensent que le fait de déployer les process "agile" est suffisant. Ils ne cherchent pas à former convenablement leurs équipes ni a leur inculquer le bon état d'esprit et des principes menant à la qualité et à l'excellence.

On se retrouve souvent dans des cas de figure où les projets sont dotés des bons rituels, les rôles sont bel et bien là, mais la confiance ne règne pas. Les managers demandant de la visibilité quasiment au quotidien et le le daily se transforme en comité de projet/de reporting. Au lieu d'aller vers  l'agilité on se retrouve à faire du cycle en V sous des faux airs d'agilité.
 Les équipes se synchronisant régulièrement dans le cadre de l'agilité à l’échelle ont l'impression d'être "fliqués" au  quotidien accroissant leur stress au lieu de les encourager à prendre des initiatives afin d'honorer leur engagements et la qualité.

Je préconise un bon accompagnement par des RTE expérimentés et surtout un bon SPC qui a l’expérience de ce type de transformations. Surtout n'oubliez pas:  l'informatique nécessite des expertises fortes, il ne suffit pas d'être manager et de se faire former et/ou certifier pour savoir mener à bien de grands projets, il ne suffit pas d'être "coach agile". Sachez bien vous entourer de gens d’expérience ;)

N’hésitez pas à prendre contact avec moi si vous avez des questions sur ce sujet.



 Pour creuser le sujet: jevous invite à lire cette page sur le site de l’éditeur de SAFe: https://www.scaledagileframework.com/lean-agile-leadership/

9 Principes fondamentaux à la base de SAFe

 SAFe repose sur un socle composé d'incontournables sans lesquels le framework ne peut produire les benefices promis.  Ces fondamentaux sont symbolisés dans la big picture par la palette grise en bas.
 Ces incontournables sont :

1.  Les cores values
2. Le Lean-Agile Mindset 
3. Les SAFe Principes
4.  Les Lean-Agile Managers
5. L' implementation roadmap
6. et enfin le SAFe Program Consultant (Coach agile dûment certifié aussi connu par son petit nom : le SPC)

Dans ce billet nous allons faire un zoom sur l'incontournable n°3: Les 0 Principes SAFe enumérés ci dessous.

 Ces 9 principes sont:

1. Adopter une vision économique
2. Appliquer la pensée systémique
3. Assumer la variabilité, préserver les options
4. Construire progressivement avec des cycles d’apprentissage rapides et intégrés
5. Poser des Jalons permettant de tester et aligner régulièrement le système de travail
6. Visualiser et limiter les Work in Progress, réduire les tailles de lots et gérer les longueurs de file d’attente
7. Appliquer une cadence et se synchroniser avec la planification inter-domaine
8. Déverrouiller la motivation intrinsèque des collaborateurs
9. Décentraliser la prise de décision

Quels messages sont portés par ces 9 principes:

• Le principe n°1 utilise les considérations économiques pour prendre toutes les décisions en compte et veille à inclure tous les paramètres pertinents dans le processus de décision: coûts de développement, coûts de production, durée du cycle de livraison, valeur livrée, etc. 
• Le principe n ° 2 confirme que tout le monde comprend et s'engage à respecter les objectifs communs du système et que toutes les décisions optimisent l'ensemble de la solution, et non des composants individuels. Il appelle également notre responsabilité à fournir aux concepteurs de solutions les connaissances et l'alignement appropriés pour prendre de bonnes décisions localisées qui optimisent l'ensemble. 
• Le principe n ° 3 nous dit que l'exploration d'alternatives est un investissement dans la création de connaissances menant à des décisions techniques optimales. De meilleures décisions minimisent les coûts et les retards des inefficacités en aval et des reprises. 
• Le principe 4 nous dit d’utiliser des cycles d’apprentissage basés sur la cadence pour évaluer ces alternatives. Alors que les équipes agiles utilisent des itérations pour créer des produits potentiellement libérables , les grands systèmes utilisent également des incréments pour valider les hypothèses techniques. 
• Le principe 5 utilise l’apprentissage démontrable de chaque cycle comme la seule mesure réelle du progrès. Les modèles séquentiels à porte de phase qui valorisent les documents et les spécifications retardent le risque et la réduction des hypothèses. Au lieu de cela, mesurer les progrès en validant les hypothèses techniques et l'acceptation des utilisateurs via des preuves objectives réduit les risques et fournit de meilleurs résultats. 
• Le principe n ° 6 assure un flux rapide et un retour rapide sur les cycles d'apprentissage. De petites quantités de travail (la plus petite chose qui puisse fonctionner, avec de faibles travaux en cours et de petites files d'attente) garantissent un flux rapide dans le système. 
• Le principe 7 fournit une cadence prévisible et régulière pour valider les décisions et s'adapter aux nouvelles connaissances. Une synchronisation régulière permet d'aligner en permanence tous les générateurs de système et garantit la compréhension et la résolution de toutes les perspectives. 
• Le principe 8 reconnaît que les travailleurs du savoir peuvent avoir des motivations fondamentalement différentes de celles des travailleurs traditionnels et que les responsables de solutions globales sont chargés de créer un environnement dans lequel ils peuvent s'épanouir. 
• Le principe n ° 9 nous dit qu'une partie de cette motivation est l'autonomie. Pour faire en sorte que les décisions soient prises par des équipes et des individus, les lean agiles manager doivent doter tous les "constructeurs de solutions" des connaissances nécessaires pour prendre des décisions productives et décentralisées.

Vous ne pourrez tirer profit du framework SAFe que si vous appliquez scrupuleusement ces principes. D'où la nécessite de respecter un autre fondamental que j'ai décrit plus haut:  se faire accompagner par un ou plusieurs SPC certifiés et ayant déjà une solide expérience en déploiement du Framework.

Si vous mettez en place SAFe dans votre structure et avez besoin d'accompagnement, conseils, de REX ou juste d'echanger des points de vue  n'hesitez pas à me contacter (lien vers ma page linkedin).

Sources: Safe lean agile principles.

Comment justifier le coût (exorbitant) d'un PI Planning?

     En tant que Coach Agile, SPC4 ou RTE nous devons apporter des arguments et éléments aux managers qui souhaitent déployer de l'agilité à l’échelle et plus particulièrement SAFe afin de les convaincre. Une des questions courantes est le coût que représente un PI Planning (Mobiliser de 50 à 125 personnes pendant 2 longues journées).  Comment apporter des arguments factuels afin de démonter que ce coût est légitime et que le retour sur investissement peut être fait rapidement? Dans cet article je vous expose une méthode simple que j'ai développé pour y répondre à mes clients.

   Quel est ce coût?

 Nous allons prendre comme hypothèse que nous travaillons sur un train (ART) composé de 100 personnes et nous partons sur un PI dont la durée est de 5 x 2 semaines. Une telle équipe travaillant en mode Feature Team a une capacité de 100 x 5 jours x 10 semaines = 5000 jours x hommes.

Pourquoi le coût est il un élément marquant?

    Le SPC ou RTE  argumentera sur la nécessité de décloisonner les équipes, les faire communiquer, aligner les équipes sur la connaissance de ce qu'ils vont développer, le vote de confiance, les faire travailler sur les dépendances etc...afin de créer un engagement volontaire et conscient des équipes.  Cet engagement aura pour effet d'augmenter la productivité et par la même diminuer le Time To Market (TTM).  Tous ces arguments sont vrais, si le PI Planning est correctement déroulé par un facilitateur expérimente et qui saura orienter les équipes présentes.  Dans cet article nous n'analyserons pas pas ces éléments dont j'ai déjà parlé dans d'autres articles (cf par exemple ce support de meetup sur mon slideshare), nous nous attacherons à analyser le coût (en jour x hommes) d'une équipe de 100 personnes travaillant sans avoir été synchronisé par un PI Planning, puis avec un ART équivalent ayant déroule le PI Planning sur 2 jours.

Le coût brut du PI Planning

 
    Mobiliser 100 personnes pendant 2 jours aura pour coût 200 jours x hommes. Une moyenne le coût d'un consultant revient environ 500€/jour. Un tjm dans notre exemple revient à environ 100 000€.

    Ci dessous je vous présente 2 tableaux correspondant aux rituels/réunions faits dans le cadre d'une équipe projet nombreuse (100 personnes) qui n'a pas été alignée en début de cadence par un PI Planning. J'ai pu observer que ce type d’équipe ne sait pas avec certitude quelle direction prendre. D'où le besoin de multiplier le nombre de réunions hebdomadaires. Et ce désordre du point de vue rituel s'accompagne souvent d'un manque de définition clair des rôles. On se retrouve à avoir un nombre important de réunions par semaine et comme tout le monde fait un peu de tout, tout le monde a "légitimement" sa place.  Cet entropie a un coût important et une efficacité faible. Cette situation est decrite dans le premier tableau ci-dessous.

   

Tableau 1: Equipe non synchronisée par un PI Planning

    Cette équipe dépense en 10 semaines 643 jours x hommes. On voit qu'il y a un nombre d'intervenant important.  En moyenne l’équipe passe environ 13% de son temps en réunion.

Tableau 2: Equipe ayant fait un PI Planning

    On constate 2 choses:

1. En respectant les rituels SAFe on en a moins. 
2. Moins de personnes participent aux rituels, cela parce que les rôles sont fortement typés et les champs d'intervention bien définis.

    Au final malgré un coût initial important de 200 jh, le coût global des rituels est ici de 665 jh, à peine plus que l’équipe n'ayant pas fait de PI Planning (environ 13%)).

Conclusions

     L’équipe qui n'a pas fait de PI Planning lisse le coût sur 10 semaines et mobilise 13% de son temps à faire des réunions.

L’équipe qui a fait le PI Planning  utilise d'entrée 4% pour une grosse mise au point entre toutes les parties prenantes. Pour le reste de la cadence (PI) elle ne passe plus que 9% de son temps en réunion et a du temps de libéré pour travailler sur les sujets principaux.

     Pour faire ce calcul j'ai fait l’hypothèse d’équipes structurées en Feature Team. Si les équipes travaillent en mode Component Team, dans des cas réels que j'ai pu voir dans mon travail, on se retrouvait à 17% dans le premier cas et après un PI Planning correctement dimensionné nous sommes tombés à 10-11% et le malgré le coût du PI Planning la deuxième configuration coûtait globalement moins que la premier.

  J’espère avoir été clair, si vous souhaitez plus d’éléments n’hésitez pas à me poser des questions.

Scaled Agile Caricature

Cet Article de Steve Adolph présente Scaled Agile avec humour.
La compréhension en est facilitée.


Pour lire le détail : cliquez ici

Etat des lieux du déploiement de SAFe en France

Je vous conseille l'excellent article écrit par Michel Levaslot (Directeur Adjoint chez Pôle-Emploi et fondateur du Club SAFe francophone) . Il y fait l'état des lieux sur le déploiement en France de SAFe.

On y a apprend que:

•  En France il y a au moins 34 sociétés ayant déployé SAFe
• 20% déployé à l'initiative du top management, 80% sous l'impulsion des opérationnels
• Au moins 85 Trains (ART)
• les trains sont déployés dans tous les domaines 
• Les Trains ont une taille moyenne de 110 personnes, 10 équipes,
• Les équipes sont organisées soit en Feature Team, soit Component Team ou un mixte
• Les équipes de dev travaillent majoritairement en Scrum, avec un nombre important d’équipes travaillant aussi Kanban
• Les ART sont quasiment toujours composés d’équipes localisées sur plusieurs lieux distants (aussi bien en France, qu'à l'étranger)
• Quasiment tous les trains déploient les rôles clés (RTE, PM, Archi Syst) ainsi que le System Team
• Durée moyenne d'un Sprint 2,5 semaines
• Etc...

Si le sujet vous intéresse, voici le lien vers l'article: cliquez ici

Etude VersionOne - Etat des lieux du déploiement des Framework Agile@Scale dans le monde en 2018

 Etude VersionOne - Etat des lieux du déploiement des Framework Agile@Scale dans le monde en 2018

         Tous les ans VersionOne sort début Avril son étude sur l’état de l'agilité au niveau mondiale. Nous suivons avec intérêt l’évolution des pratiques autour du sujet de l'agilité à l’échelle (Scaled@Agile). En tant que Coach Agile, Release Agile Train et SPC4 une telle étude nous fourni des arguments pour nous aider dans le coaching des leaders et équipes.

         Nous avons compilé dans le graphe ci-dessous les données concernant l'utilisation des différents frameworks d'agilité à l’échelle.

       

          (source:  VersionOne 12th annual state of agile report)

        On peut constater que SAFe confirme les tendances qui se dessinaient les années précédentes en s'imposant petit à petit comme le framework le plus utilisé et tendant à devenir la référence.

        Ses principaux concurrents comme les pratiques issues de Spotify ou encore le framework LeSS ont vu leur utilisation se marginaliser.

        Cette étude ne fournit pas les détails pays par pays. En France en particulier, je constate une "explosion" de l'utilisation de SAFe dans les grandes entreprise depuis début 2017.  Je vous recommande l'excellent post de Michel LEVASLOT (Directeur-Adjoint à la DSI du Pôle-Emploi) sur linkedin, qui fait un état des lieux du déploiement en France:   Etat des lieux du déploiement de SAFe® en France


        N’hésitez pas à partager en commentaire vos observations sur l'utilisation grandissante de ce Framework.

Article d'IBM: Comparing Scaling Agile Approaches

Article d'IBM: Comparing Scaling Agile Approaches

Je suis tombé sur un article d'IBM qui date de 2014, comparant les framework de Scalabilité Agile.
Depuis 2014, ces framework ont évolués mais leur fondamentaux sont restés les mêmes. Cet article reste à mon sens encore d'actualité.

L'article est dispo ici: Comparing approaches to scaling agile

Présentation et motivation

 
   Je m'appelle Pierre MEDINA, professionnel de l'informatique, je travaille dans l'IT et le monde du  développement depuis  2001. Je suis passé par les différents postes pendant plusieurs années (développement Java, architecte, chef de projet, directeur de projet, auditeur des SI, Coach Agile, Delivery Management Lead, etc...).  

   Ce blog a pour vocation pour moi le partage de mon expérience, de mes opinions. sur les différents sujets que je suis.

  N’hésitez pas à me suivre sur linkedin ou sur twitter @pmedina (deux réseaux sur lesquels je suis très actif.)

L'informatique n'est pas pour moi seulement mon métier, c'est aussi une passion. Je n'ai pas comme ambition de faire de l'agilité quand j'interviens chez un client mais 

  

Plus precisement sur ce blog, il a pour vocation de presenter différents sujets techniques afin de partager mon experience, mes reflexions, mes dernières lectures.  

Les sujets pourront être variés:

• L'Agilité vs Cycles de développement V ou Y
• L'Agilité à l’échelle (SAFe, LeSS, Scrum de Scrums, etc...)
• Les bonnes pratiques de développement
• La mobilité, Digital, Android
• Les différents sujets qui ont le vent en poupe: Big Data, IoT, BitCoins, Ethereum, etc...
• Etc...

Je partagerai aussi mon fil twitter sur lequel je partage les articles suite à ma veille technique.

N'hésitez pas à partager vos points de vu ou questions.

Les configurations de SAFe

Les configurations de SAFe

Le Framework est modulaire: Il existe 4 couches répondant chacune à une problématique donnée.
Les 4 configurations sont accessibles à partir de la page d'accueil site de Scaled Agile. (cf image ci dessous).
A droite de l'image il est possible de selectionner une configuration ce qui a pour effet de mettre àjourl'image.
 

Les 4 configurations sont:

1. Essential SAFe
2. Portfolio SAFe
3. Large Solution SAFe
4. et Full SAFe

Essential SAFe

Configuration la plus basique du Framework, fournit les éléments minimaux nécessaires pour déployer avec SAFe.

Pour une organisation souhaitant déployer son premier train c'est le meilleur point de départ. 

Dans ce mode on a les outils et rôles minimaux pour constituer un train agile (ART)

On a les couches: Team et Program.

cf Scaled Agile pour plus de détail.

Portfolio SAFe

Cette configuration fournit une stratégie de portefeuille et gestion des  financement/investissement. Elle permet de prendre en compte les orientations stratégiques dans le plan d’ exécutions plus rapidement.

On a les couches: Team, Program et Portfolio.

 cf site SAFe pour plus de détail.

Large Solution SAFe

Cette configuration destinée aux entreprises qui construisent des solutions vastes et complexes (plusieurs ART). Cette nouvelle couche permet de synchroniser plusieurs ART.

On a les couches : Team, Program et Large Solution.

cf Scaled Agile pour plus de détail.

Full SAFe

Cette dernière configuration représente la configuration la plus complète.
Elle prend en charge la création de grandes solutions intégrées qui nécessitent
la synchronisation de centaines de personnes ou plus.

On a les couches : Team, Program, Large Solution et Portfolio
cf Scaled Agile pour plus de détail.

Classement influenceurs en AI et IOT

  Trés fier d'apparaitre ces derniers jours dans Ranking d'onalytica (#ai et #iot).

Classement influenceurs AI

Scaled Agile Framework (SAFe): Présentation générale.

D'où vient mon intérêt pour ce sujet

    Dans cet article je vais vous parler de Scaled Agile (SAFe) . C'est un méthodologie qui fait de plus en plus de bruit depuis 2-3 ans.  Mon expérience de professionnel de l'informatique depuis presque 20 ans me rend méfiant envers ces frameworks qui apparaissent en nombre pléthorique et qui disparaissent aussi vite. Mon expérience opérationnelle en développement, architecture logicielle, architecture d'entreprise, de manager d’équipes (CTO, Manager, Directeur de Projet) me poussent à analyser ces nouveaux outils sous un angle pragmatique.  Quand j'ai croisé la big picture de SAfe pour la première fois j'ai eu un a priori négatif.  Tout cela semblait complexe. En regardant dans le détail on s'aperçoit que le framework est structuré en couches et sur chacune de ces couches des rôles et outils sont mis à disposition afin de répondre aux différentes problématiques rencontrées dans l'entreprise selon la couche et la granularité.

    Cette méthodologie offre des réponses aux entreprises qui commencent à avoir des résultats probants des méthodes de développement agiles et qui veulent passer à l’étape d’après. L’étape d’après c'est être en mesure de coordonner et réaliser de nombreux développements logiciels de plateformes entières, des SI entier au niveau des équipes et de devenir Agiles dans la prise de décision au niveau des métiers et surtout au niveau du budget.

Qu'est ce que SAFe?

    Le Scaled Agile Framework  est une marque déposée de Scaled Agile, Inc.
 Il est destiné à guider les entreprises dans la mise à l'échelle des pratiques d'Agilité.
   Avec d'autres Framework tel que Disciplined Agile Delivery (DAD), Large-Scale Scrum (LeSS),  Nexus, etc...  Safe est un des nombreux frameworks qui cherchent à résoudre et outiller les problèmes rencontrés lors de la mise à l'échelle d'un programme ou d'un departement.

   SAFe favorise l'alignement, la collaboration et la diffusion dans un grand nombre d'équipes agiles. Il a été développé par et pour les praticiens, en s'appuyant sur trois principaux savoirs: le développement de logiciels agiles, le développement de produits allégés et la pensée systémique.

   À l'origine, la fonction principale d'un framework agile mis à l'échelle consistait à élaborer une vue d'ensemble de la façon dont le travail découlait de la gestion des produits, par le biais de la gouvernance, des équipes de programme et des équipes de développement jusqu'aux clients. Le cadre a continué à être développé et publié dans le domaine public, également soutenu par une académie et un système de certification pour les consultants tiers. La dernière version, en version 4.5, a été publiée en juin 2017.

  L'ensemble de la documentation SAFe est accessible sur un site dédié:    http://www.scaledagileframework.com

  SAFe est décrit dans la big picture ci dessous. Nous présenterons ces  différentes couches et notions dans la suite de cet article.

                              

Fig.1 Big Picture de SAFe

Simple effet de mode ou vraie opportunité de rendre Agile les grandes organisations?

   Plusieurs études ou sondages fait au niveau mondial montrent que l'utilisation de SAFe s'impose sur  celle des autres Frameworks.
   La figure ci dessous montre des courbes d'utilisation de l’étude annuelle de VersionOne sur l'Etat de l'Agilité dans le monde.
N’hésitez pas à lire mon article presentant ces 2 études: SAFe s'impose parmi les Fwk d'Agilité à l'Echelle

Fig.2 Evolution d'utilisation des Frameworks par année

Cf article SAFe s'impose parmi les Fwk d'Agilité à l'Echelle pour plus de précision.

Valeurs et principes sur lesquelles SAFe se base.

SAFe

Sur le bas de la Big Picture une palette contenant des icônes résume les valeurs, principes et processus importants sur lesquels se base SAFe.

Dans cette section nous zoomerons sur chacune de ces icônes.

                                                Fig.3 Palette présente en bas de la Big Picture

Les principes sous-jacent de SAFe

Les principes de SAFe sont decrits dans l'image ci dessous.

Fig. 4 : Les 9 principes SAFe (source: site scaledagileframework.com)

Je vous ssuggére de consulter les explications directement sur le site de ScaleAgileFramework:  SAFe Principles ou en cliquant sur l'icone sur la premiere page du site web.

(à suivre ...)

SAFe s'impose parmi les Fwk d'Agilité à l'Echelle (Chiffres 2017)

SAFe s'impose parmi les Fwk d'Agilité à l'Echelle

         Depuis les années 2010 il y a un effet de mode autour des Framework à l'Echelle.
Ces frameworks sont listés dans l'image ci dessous.
        Dans la suite nous allons voir que d'année en année SAFe tend à convaincre les grandes entreprises et tend à s'imposer comme un standard.

   NOTA BENE: Spotify est absent de cette liste car inclu dans la rubrique "Internally created methods". Spotify n’étant d'ailleurs pas à proprement parlé un framework d'agilité à l’échelle. C'est plutôt un recueil de bonnes pratiques, un REX fait par l'entreprise après la mise en place de certains pratiques Agiles. Un gros effet de mode a eu lieu autour de ces pratiques (découpage en squad, tribus, etc...).  Cet effet de mode est en train de s'estompé.  SAFe récupère plusieurs bonnes pratiques qui ont fait leur preuve dans cette methodo.

Etude de VersionOne

Tous les ans VersionOne  organise un sondage au niveau mondial. SAFe progresse tous les ans depuis 2012 et s'est imposé comme le Framework de référence.

Ci dessous l'etude publiée en avril 2017.

Source: 11th Annual State of Agile Report

Etude Annuelle de CapGemini,MicroFocus et Sogeti (World Quality Report)

Comme dans l'étude de VersionOne, cette étude montre une forte tendance à l'adoption de SAFe dans les entreprises qui ont repondu à l'étude au niveau mondial. 

Source: Etude - World Quality Report 2017

Courbes d'utilisation des framework  d'agilité à l'echelle

L'image ci dessous a été obtenue en compilant les données des études VersionOne 2015, 2016 et 2017: StateOf Agile Survey

L'intégralité des Frameworks d'Agilité à l'Echelle sont en perte de vitesse à l'exception de SAFe qui est la seule à augmenter. SAFe est passé 1er en 2016 devant Scrum de Scrums.

Indicateurs décrivant une équipe Agile productive et mature.

Quel est la productivité optimale d'une équipe agile? Combien d'user stories peut elle raisonnablement espérer traitement au cours d'un sprint? Sur quels critères se baser pour déterminer si on découpe ou pas une User Story(US) en US plus petites? etc...

 Ce sont des questions que toute équipe agile peut légitimement se poser. L'outil Jira est utilisé en mode cloud par des milliers de sociétés dans le monde. Atlassian qui en est l’éditeur possède les données sur 500 000 projets agiles qui sont hébergés sur ses infrastructure. Après avoir anonymisé les données, Atlassian a fait une étude sur la masse d'informations pour déterminer le profil idéal d'une équipe agile qui fonctionne bien. Après avoir isolé des milliers d'équipes qu'elle a baptisée "Equipe Orientée livraison" ils en ont tiré de grandes tendances qui sont à mon avis riche d'enseignement pour les équipes agiles cherchant à s'améliorer ou aux Servant Leader, pilotant les Sprints par des indicateurs pertinents.
 Par exemple leurs indicateurs montrent que les équipes les plus efficaces ont les caractéristiques suivantes:

• 30 US/tickets traités pendant un sprint en moyenne
• chaque sprint dure environ 2 semaines (10 jours ouvrés)
• 71% des objectifs sont atteints (l’équipe se challenge en programmant plus de tickets qu'elle ne peut réaliser)
• Il y a 1 livraison en moyenne tous les 15 jours
• Le lundi est le jour favori pour programmer des Releases
• etc...

 Ces informations permettront surement d’évaluer la marge de progression d'une équipe et de se fixer des objectifs réalistes. L'image qui suit (provenant de l'article d'Atlassian) synthetise ces indicateurs.

L'article est disponible en suivant le lien suivant:
http://blogs.atlassian.fr/2016/08/17/decomposition-des-user-stories-dans-jira