AuthorFlorian Labadens

L’art de prendre une décision au bon moment.

Derrière ce titre provocateur, il y a ce que toute personne réalisant des projets a déjà constaté. Présenté sous forme de lapalissade, ça pourrait donner :

plus nous avançons dans le projet, plus nous avons de certitudes sur ce qu’il va se passer.

Ceci étant dit, on est donc tous d’accord, le début d’un projet c’est le moment où nous en connaissons le moins, et pourtant c’est le moment où nous nous engageons le plus !

Pourquoi fait-on cela ? Parce que le client le demande, parce que les gouvernances des entreprises le demandent … et puis surtout si on ne s’engage pas, il n’y aura pas de suite …

et pour tenir ces engagements, pas de surprise, des marges, chaque partie prenante prend son lot de 20-40% de marge, et nous commençons un projet avec un environnement qui n’est pas basé sur la confiance et la transparence.

C’est véritablement là où les approches traditionnelles et l’agilité diffèrent … D’un côté, on prend des marges, d’un autre, on assume et on itère, le plus souvent possible, afin de générer un maximum d’apprentissage

Le cône d’incertitude

Vous trouverez ci-dessous la représentation de ce constat tel que Steve Mc Connell, dans le passé chez Microsoft l’a représenté,  « le cône d’incertitude ».

Cone d'incertitude
Le Cône d’incertitude est donc ce terme utilisé en Gestion de Projet pour décrire le degré d’incertitude existant aux différents stades d’un projet.

Qui peut contredire ces observations ?

Et pourtant de nombreuses approches ont renforcé l’idée que les équipes projet doivent prendre des engagements toujours de plus en plus tôt, sur des spécifications fonctionnelles, des choix architecturaux, des estimations de budget, bref … prendre des décisions structurantes pour le projet.

Cette déclinaison pour les estimations émane de nombreuses études réalisées par Mc Connell et la conclusion est simple.

Les organisations sabotent par « inadvertance » leurs propres projets en prenant des engagements trop tôt dans un contexte où l’incertitude est trop grande. Mc Connell dit aussi que : « Si une organisation s’engage au moment du concept initial ou de la définition de produit, elle a un facteur de 2x à 4x d’erreur dans ses estimations. » Décliné sur un projet de 1000 jours.homme, cela signifie que la marge d’erreur du x0,25 à x4, nous amène entre 250 et 4000j.h. Soit un facteur de 16 !

Alors concrètement, ce sont les marges qui gèrent cette incertitude et souvent de très grosses marges. Mais si le fournisseur doit raboter les engagements dans la négociation, que fait-il quand ils ne sont pas réalistes ? il ne le dit pas car sinon il ne gagne pas le contrat. Dès qu’il gagne le projet il dit « désolé cher client, l’engagement doit être revu, ce n’est pas tenable ». Le fournisseur est tenu par la nécessité d’avoir le contrat. Sans contrat il ne gère rien, avec un contrat, il gère les problèmes (et c’est mieux que rien !) 

Les engagements pris trop tôt dans un projet compromettent la prédictibilité, augmentent les risques, augmentent l’inefficacité du projet, nuisent à la capacité de gérer un projet pour réussir et empêchent tout simplement de réaliser le bon produit.

Ok mais comment réduire ce cône d’incertitude ?

Nous nous trompons, nous avons toujours pensé que c’est en « creusant » ou autrement dit en cherchant du détail et en cherchant la complétude sur le besoin mais aussi toute l’architecture que l’incertitude se réduirait. N’entendez-vous pas régulièrement :

  • Plus le projet est spécifié dans le détail, plus le chiffrage réalisé sera proche de la réalité
  • Plus on a réussi à anticiper et planifier le travail, plus on aura un bon plan.
  • Il faudra limiter et contraindre le changement parce que le client n’est pas mature
  • Figer les choix structurants tôt, on aura donc une architecture figée et on aura réduit les risques.

Et si la réalité se trouvait à l’opposé ?

Concernant les estimations budgétaires, d’autres ont pensé que l’expérience de projets passés assurerait une meilleure gestion de l’incertitude … sur le papier excellente idée – l’empirisme. Mais c’était oublier que les projets de développement logiciel sont beaucoup plus proches des projets de recherche et développement que des projets industriels basés sur la répétition de tâches identiques. On utiliserait les performances passées sur des projets similaires, pour tenter d’évaluer les performances futures mutatis mutandis.

Nous nous trompons parce qu’il n’y a pas 2 projets avec :

  • Les mêmes exigences.
  • Les mêmes personnes.
  • Le même contexte commercial.
  • La même technologie.
  • Les mêmes priorités et contraintes.
  • La même équipe

Chaque projet est unique. La grosse majorité des lignes de code sont fabriquées à la main. Et notre construction du bon produit implique des développeurs créatifs et intelligents et ca ne se prête pas à « l’estimation avec précision ».

Alors oui, quand on réalise ce type d’estimations, chaque intermédiaire prend des marges, 30% peut-être, selon le risque, ça peut representer beaucoup plus. Et au global, vis à vis du coût global du projet ?

Cône d’incertitude et agilité

La question est donc « Quand réalise-t-on que nous avons suffisamment appris pour considérer que l’incertitude diminue réellement? ».

Incertitude et waterfall

Sûrement pas en faisant valider un cahier des charges, une liste d’exigences, un dossier d’architecture – le tout sur papier –  qui finalement nous génère plus de faux-positifs que de réels apprentissages et qui confrontés à la réalité du terrain voleront en éclats.

L’agilité considère qu’en livrant régulièrement et fréquemment un produit qui fonctionne puis en le montrant et en le mettant dans les mains des utilisateurs, ne pouvons réduire l’incertitude et le risque.

Cone d'incertitude et agilité

C’est en effet au travers des nombreux feedbacks utilisateurs mais aussi grâce aux tentatives d’intégration et de déploiement que l’on gagne en certitude. C’est donc en se basant sur ces retours concrets que l’équipe peut désormais prendre les bonnes décisions au bon moment. 

« Build the right product and the product right »

C’est aussi pour cela qu’on parle beaucoup de « Juste à temps » quand on parle d’agilité. Savoir attendre le bon moment – celui où on aura récupérer suffisamment de retours, d’expérience et de résultats d’expérimentation – pour prendre la décision. Il y a donc un réel enjeu économique à premièrement assumer l’incertitude ambiante mais surtout différer certains choix au moment où on aura suffisamment d’apprentissage.

Alors, utiliser le MVP ! (un article ici). C’est le minimum à réaliser pour générer suffisamment d’impact pour nous permettre de recueillir du feedback. Ca veut dire qu’il faut identifier dans votre prochain sprint les histoires utilisateurs qui vous permettront de générer des retours et donc des apprentissages nécessaire à votre prise de décision.

L’agilité permet donc d’apprendre au fil du temps sur le bon produit à réaliser, de réduire plus rapidement le cône incertitude et de prendre les décisions au bon moment.

Plus votre cycle d’apprentissage est court, plus vous apprenez. Ne décidez pas tout au tout début, décidez au bon moment 😉

Coach Lean/Agile. Passionné d’humain, j’ai d’abord été développeur agile et Scrum Master, puis j’ai ci-crée une startup du web. J’interviens maintenant pour plusieurs grands comptes pour remettre de l’humain au centre des organisations : depuis la découverte de l’agilité jusqu’à la transformation d’organisations complexes et de leurs cultures.
Mots-clés : Lean, Scrum, Kanban, SAFe.
Citation : « You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete. » R. Buckminster Fuller

Pourquoi SAFe marche ?

Souvent décrié mais pour autant de plus en plus utilisé, il nous semble intéressant d’expliquer nos convictions sur les éléments qui font que SAFe® est une approche pertinente pour adresser l’agilité à grande échelle dans des organisations complexes.

Avant de commencer, si vous cherchez dans cette article du SAFe Bashing ou des réponses toutes faites à  « Est-ce que SAFe est agile ou non », ni même l’apologie de SAFe en tant que solution « One size fits all » … ce n’est pas vraiment ici que vous le trouverez.

Par contre, nous allons discuter des axes qui au travers de plusieurs expériences nous permettent de dire que SAFe, ça marche !

SAFe, c’est des poupées russes

Tel le concept de fractale ou des poupées russes, SAFe s’appuie sur ce qui marche bien au niveau équipe agile et le réplique aux niveaux d’abstraction plus élevés (tels que le programme et le portefeuille).

SAFe - cadence et synchronisation

Cadence et Synchronisation

Autrement dit, l’équipe Scrum ne pense plus à son projet seulement, mais elle appartient à un système qui s’appelle l’Agile Release Train et qui a son macro backlog. Connecté à l’entreprise et ses objectifs stratégiques, cette équipe agile d’équipes agiles délivre tel un flux continu de la valeur à ses clients. Ces équipes planifient ensemble (PI planning au niveau du train SAFe), identifient leur dépendances, leurs risques et leurs objectifs, puis collaborent et se synchronisent au fur et à mesure (Scrum of Scrum), et enfin démontrent ensemble leur incrément (System Demo) puis réalisent leur inspection et adaptation (Inspect & Adapt). Ce n’est donc plus seulement une équipe qui sprinte mais un système dans son ensemble en utilisant les mêmes cérémonies que Scrum avec les mêmes objectifs mais à une échelle différente.

On retrouve aussi une illustration des poupées russes quand on regarde les personnes impliquées, 3 « rôles » au niveau équipe Scrum que vous connaissez bien, que l’on retrouve au niveau du train – RTE en tant que Super Scrum Master, Product Manager en tant que Super PO, System Architect en tant que connaissance technique du système – mais aussi au niveau de la value stream – VSE en tant que Super Super Scrum Master, Solution Manager en tant que Super Super PO, Solution Architect en tant que coordination technique de l’ensemble. En d’autres termes, aucune relation hiérarchique mais des réseaux de personnes qui ont les mêmes activités avec des granularités différentes.

Les Agile Release Trains sont donc des équipes d’équipes Agiles s’appuyant sur les mêmes caractéristiques que les équipes agiles à savoir : pluridisciplinaire, auto-organisée, 3 rôles, des rituels pour cadencer et synchroniser… seule la taille changement passant d’une équipe de 7 à une équipe d’équipes allant de 50 à 125. Les ARTs ont l’ensemble des compétences pour définir et délivrer des incréments de produit toutes les deux semaines.

Principes Lean / Agile

Difficile de ne pas parler de SAFe et du manifeste agile qui au travers de ses valeurs et principes sous-jacent restent la base fondamentale. Mais quand on parle d’agilité à l’échelle, ces 12 principes sont ils tous toujours applicables ? La grande majorité, oui.
– « Un logiciel opérationnel est la principale mesure d’avancement. » -> Pour ne citer que celui-ci reste totalement vrai et appliqué à l’échelle.
– « Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées. » -> Dans une organisation complexe et un SI complexe, sans orientation et vue d’ensemble, les meilleures équipes auto-organisées peuvent rencontrer des difficultés.

En mixant agile pour l’essentiel et lean pour le passage à l’échelle, SAFe en propose une déclinaison sous forme de 9 principes – fondamentaux à prendre en compte à l’échelle.

  1. Avoir une vue économique : L’ensemble des acteurs ont la responsabilité de s’assurer que l’investissement dans de nouvelles solutions fournira des avantages économiques. Il est donc important de comprendre les raisons économiques de délivrer au plus tôt et souvent la plus haute valeur. Il est aussi question de comprendre les paramètres permettant de prendre des décisions économiquement viables et cela à tout niveau de l’organisation
  2. Appliquer une pensée systémique : voir chaque groupe de personnes ou d’activités comme un système afin d’avoir une vue globale des problèmes et challenges. « le composant le plus lent décide de la vitesse de l’ensemble » Moore.
  3. Assumer la variabilité et se préserver des options : les approches traditionnelles visent à s’engager le plus tôt possible sur une unique solution technico-fonctionnelle, ici, on parle plutôt d’essayer d’avoir les données issues d’expérimentations pour faire le meilleur choix au meilleur moment.
  4. Construire progressivement avec des cycles d’apprentissage rapides et intégrés : Chaque itération aboutit à un incrément intégré du produit regroupant l’ensemble des équipes du train. Ces incréments donnent l’opportunité de d’avoir un maximum de retours des utlisateurs, permettant de pivoter régulièrement et faire décroitre le risque.
  5. Avoir des jalons basés sur l’évaluation objectif du système fonctionnel : Chaque point d’intégration de l’incrément offre l’occasion d’évaluer la solution, fréquemment et tout au long du cycle de vie du développement. Mais c’est aussi un moyen d’assurer qu’un investissement apporte suffisamment de bénéfice.
  6. Visualiser et limiter WIP, réduire les tailles des lots et gérer les longueurs de file d’attente : Les organisation s’efforcent d’atteindre un état de flux continu de livraison de valeur. Trois clés principalement issu du Lean existent pour la mise en œuvre d’un flux : 1. Visualiser et limiter la quantité de travail en cours afin de contraindre la demande à la capacité réelle, 2. Réduire la taille des lots pour faciliter un flux le plus unitaire possible dans le système et 3. Gérer les longueurs de file d’attente afin de réduire les temps d’attente pour les nouvelles fonctionnalités.
  7. Appliquer cadence et synchronisation : La notion de cadence transforme les événements imprévisibles en prévisibles et fournit un rythme de développement. La synchronisation permet de comprendre, de résoudre et d’intégrer simultanément de plusieurs équipes.
  8. Débloquer la motivation intrinsèque des équipiers : l’idéation, l’innovation et l’engagement des équipiers ne passent pas par une motivation basé sur des objectifs individuels et des récompenses associées. En travaillant sur la motivation intrinsèque, on essaye d’assurer l’autonomie, de travailler pour atteindre un but important, et de minimiser les contraintes, afin d’améliorer le bien être des équipe et aboutir à de meilleurs résultats
  9. Décentraliser la prise de décision : l’organisation nécessaire à une livraison rapide nécessite une prise de décision elle aussi rapide et décentralisée, car toute décision peut introduire un délai. La prise de décision décentralisée réduit les retards, améliore le flux de développement du produit, permet des feedbacks plus rapide et des solutions plus innovantes. Cependant, pour être réaliste certaines décisions sont stratégiques, de nature globale et ont des économies d’échelle suffisantes pour justifier la centralisation de la prise de décision.

SAFe nous propose grâce à ces principes un prisme d’analyse à base de pensée systémique, lean product development et bien sûr d’agile development pour développer l’agilité à l’échelle. 3 grands axes passionnants mais qui déjà nous donne un avant-goût de la conduite du changement qu’il va falloir réaliser pour faire admettre ces basiques.

Alors oui, ca marche !

SAFe et les agile release trains, oui, ca fonctionne ! Et la raison majeure, c’est cette capacité fractale à réutiliser les concepts qui ont fait le succès de l’agilité à l’échelle d’une équipe Scrum. Gardez bien à l’esprit qu’aucun framework qu’il soit à l’échelle ou non vous rendront Agile. Qui plus est en tant qu’Agiliste, nous devons particulièrement reconnaitre que le cadre n’est qu’un outil qui sans leadership, sans transformation organique et expérimentale et sans agent du changement sera inutile. Les points débattus ci-dessus sont des outils de cette transition que vos équipes devront prendre le temps de découvrir et expérimenter dans leur contexte.

Coach Lean/Agile. Passionné d’humain, j’ai d’abord été développeur agile et Scrum Master, puis j’ai ci-crée une startup du web. J’interviens maintenant pour plusieurs grands comptes pour remettre de l’humain au centre des organisations : depuis la découverte de l’agilité jusqu’à la transformation d’organisations complexes et de leurs cultures.
Mots-clés : Lean, Scrum, Kanban, SAFe.
Citation : « You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete. » R. Buckminster Fuller

Bienvenue chez nous !

Bonjour à tous,

Que vous soyez un agiliste convaincu, en cours de découverte ou simple curieux, nous vous souhaitons la bienvenue sur notre blog. N’hésitez pas à interagir avec nous au travers des commentaires.

Nous sommes plusieurs coaches Agile de la société SQLI Toulouse et nous souhaitons au travers de ce blog autant partager nos convictions, nos découvertes et nos REX qu’apprendre.

Nous pensons que l’agilité c’est l’évidence, qu’elle est en train de changer le monde et que l’élément clé pour la faire fonctionner est l’envie de travailler différemment.

Ici nous allons parler d’Agilité bien sûr mais plus précisément :

  • de Culture et de conduite du changement
  • de Scrum,
  • de Kanban,
  • d’agilité à l’échelle avec SAFe, LeSS et d’autres,
  • d’ateliers que nous avons utilisés,
  • de livres que nous avons lu

A très vite !

Coach Lean/Agile. Passionné d’humain, j’ai d’abord été développeur agile et Scrum Master, puis j’ai ci-crée une startup du web. J’interviens maintenant pour plusieurs grands comptes pour remettre de l’humain au centre des organisations : depuis la découverte de l’agilité jusqu’à la transformation d’organisations complexes et de leurs cultures.
Mots-clés : Lean, Scrum, Kanban, SAFe.
Citation : « You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete. » R. Buckminster Fuller

© 2019 Agile by Example

Theme by Anders NorénUp ↑