On veut créer de la valeur

En général quand je dis ça comme ça, ça fait sourire :).

Les informaticiens doivent se dire « oui elle est gentille, elle n’invente rien, tout le monde veut créer de la valeur ».

Sauf que messieurs-dames les informaticiens, je ne sais pas pourquoi vous êtes les seuls à qui il faut expliquer ça. L’informaticien(ne), très poli, peut me demander « bon d’accord mais c’est quoi la valeur pour le client ? ».

La valeur est créée quand les clients sont contents.

Tout « bon » chef de projet vous le dira : le client ne sait pas ce qu’il veut. Et puisque le client ne sait pas ce qu’il veut, on va se protéger de son indécision et en lui faisant valider des spécifications.

D’ailleurs un « bon » chef de projet est celui qui se bat le mieux.

C’est donc une guerre, le développement logiciel.

On entend alors :

  • « monsieur le client, ce que vous demandez n’est pas du tout conforme avec la demande initiale » -> changement
  •  « monsieur le client ce n’est pas ce que nous avions convenu dans les spécifications » -> changement

Et qui dit changement dit facturation supplémentaire, et le chef de projet est content.
L’objectif avoué est donc de faire valider les spécifications et de ne pas produire de bugs en face de ces spécifications. Au passage si on a pu facturer cher les changements c’est super.

Et bien pas du tout.

En agile on dit bienvenue au changement, le changement est une opportunité, une chance d’arriver au bon produit.
La réaction normale au changement devrait être :

  • « super ! ça sera mieux comme ça ! »

 

Rendez vous compte que l’on demande aux clients de valider des spécifications. Le client ne sait pas faire ça ! Le client sait parler de son besoin, pas des spécifications.

Par exemple : prenons mon plombier, lors d’une visite de chantier de ma maison.
Il me demande « Madame, je les mets où les lavabos ? »
Moi je n’en sais rien du tout, et je le lui fais savoir.
Il m’emmène dans la salle de bain et me dit « Vous vivez comment là dedans ? »
Là c’est facile je sais répondre : « On aime bien avoir de la place sous la douche, pour mettre les affaires sèches à proximité. Puis on aime bien être tous devant le miroir pour prendre des photos du brossage de dents c’est rigolo. »
Pendant que je parle il déduit que la table supportant les 2 lavabos doit être à xxx cm du mur 1 et à xxx cm du mur 2.

Nous avons fait une conversation sur mon besoin, et de cette conversation a émergé la spécification.
Mon plombier n’est pas allé me chercher un « plombier spécifieur » pour écrire une spécification qu’il m’aurait faite valider, puis il aurait fait appel à un « plombier développeur» qui aurait réalisé le produit.
Celui qui réalise (le plombier) est le mieux à même de discuter pour savoir comment répondre à mon besoin : nous avons cette conversation ensemble, lui et moi.

 

Les informaticiens sont informaticiens. Les plombiers sont des plombiers. Les plombiers savent que leurs clients ne sont pas plombiers. Pourquoi les informaticiens ne savent ils pas que leurs clients ne sont pas informaticiens ?

J’entends trop souvent « le client ne sait pas ce qu’il veut » : c’est faux. C’est surtout qu’on ne parle pas le même langage, et qu’on ne pose pas les bonnes questions.
Au lieu de « monsieur le client, que voulez vous comme écran ? » , il faut demander « monsieur le client, comment doit on améliorer votre vie ? ».

On doit lui demander quelle valeur métier on doit créer, et avoir une conversation avec lui à ce sujet.

J’ai l’impression que nous autres les informaticiens nous sommes hautains, conscients de notre supériorité face à cet outil, l’informatique, qui est censé être connu de tous et dont nous sommes les experts (les magiciens).

Ou alors on ne se rend pas compte que notre métier dépasse le cadre strict de l’informatique, et que l’on doit chercher à comprendre quelle est la valeur à créer.

 

La question du comment est la question de la spécification.

Bien sûr il y a des spécifications en agile, ne commettez surtout JAMAIS l’erreur de les enlever.
En agile on raconte des histoires pour comprendre le besoin : en tant que xxx je veux xxx afin de xxx.

Afin de : c’est la question de la valeur à créer.

Raconter des histoires, avoir une conversation sur le besoin pour faire émerger la spécification, cela donne du sens aux développeurs. Cela leur permet de comprendre quelle valeur il faut créer et de ne pas se retrouver à la fin à entendre un client pas content dire « non ce n’est pas un changement, c’était implicite ».

L’objectif contractuel de respecter les spécifications doit être remplacé par des objectifs métiers : la valeur doit avoir été créée là, là et là.

 

La question est simplement : quel est votre besoin ? que voulez vous faire ? pourquoi devons nous faire ceci ?

L’objectif est de rendre les gens contents, de réaliser des applications parfaites où les utilisateurs ne passent pas leur temps à chercher la fonction x ou y. Le client doit pouvoir utiliser l’application comme quand j’utilise le lavabo : c’est mon bon produit.

 

On veut changer le monde : le rendre plus heureux pour tous. 

L’objectif est de changer la vie de nos utilisateurs. Avant ils n’avaient pas cette application : pourquoi doit on la faire ? Quelle valeur doit on créer cette fois ci ?

 

L’agile est une démarche disciplinée de création de valeur.

 

 

 

L’agile ce n’est pas du Design To Cost

J’entend parfois « l’agile, c’est du Design To Cost ! »: je ne suis pas d’accord. Il y a une ressemblance peut être mais aussi une grosse différence entre les deux. Je m’explique.

 

Pourquoi fait-on des projets en agile ? Pour rendre les gens contents tout simplement, pour changer le monde à chaque fois qu’on livre un nouveau produit.

Un projet c’est avant tout un budget et une douleur. Sans budget pas de projet (on estime dans ce cas que la douleur n’est pas si importante), sans douleur pas de projet (on a un budget mais on n’est pas assez riche pour lancer des projets dont on n’a pas vraiment besoin).

Donc quand on lance un projet, c’est qu’on a des utilisateurs à rendre contents. Ces utilisateurs, ils faisaient comment avant qu’on se décide à lancer le projet ? Ils étaient embêtés et ils attendaient qu’on les satisfasse.

 

Souvent la question qu’on leur pose est : « Vous avez combien comme budget ? » (question 1)

Une autre question est tout simplement (ou tout bêtement) : « On doit rendre les utilisateurs contents comment ? Ils devront pouvoir faire quoi avec ce nouveau produit ? » (question 2)

 

Je constate souvent la question 1 : c’est du Design To Cost (un produit pour un coût donné, en français Conception à coût objectif).

La question 2 c’est la maximisation de valeur métier : c’est de l’agile.

 

Le mieux est de poser les deux questions ensembles, dans ce cas le budget se traduit par une simple contrainte budgétaire maximale à l’intérieur de laquelle on priorise.

La démarche agile est la suivante :

  1. on priorise par rapport à la valeur
  2. on ne consomme pas tout tout de suite.

 

Si on pense uniquement Design To Cost, on consomme tout ce budget tout de suite, en une fois, on fige donc tout un périmètre pour un budget. Est-ce que c’est agile ça ?

En gros on se dit « j’en voudrais pour 100 € ! », et on remplit pour 100 €.

L’important est de ne pas oublier la progression itérative dans la limite de ce budget maximum.

Entendez bien cette contrainte maximale : ne remplissez pas tout pour ce montant, sinon on aura tout consommé et donc tout figé, ce qui empêchera de prendre du feedback et donc de créer de la valeur.

 

Dans la question 1 on est efficient : on fige tout pour un montant, on essaie d’être le plus productif possible avec un budget donné, et donc on évacue tout ce qui n’est pas directement productif (l’innovation, l’exploration et le risque).

Dans la question 2 on est efficace : on veut découvrir ce qui va plaire à l’utilisateur : était ce bien ce produit qu’il fallait faire ?

 

Par exemple, je vous livre telle quelle une remarque récente de mon fils : « maman j’ai dépensé tout mon argent de poche ! ». Moi j’ai fait la tête, je ne partageais pas son enthousiasme.

Il est allé dans une librairie et a dépensé au mieux ses 35 €. L’exercice a consisté à prioriser les mangas entre celui qu’il veut absolument (catégorie 1), celui qu’il veut parce qu’il suit la série (catégorie 2), celui qu’il veut parce qu’on lui a conseillé (catégorie 3), celui qu’il veut pour tester (catégorie 4). Avec le budget qu’il avait il a sélectionné les mangas. Conclusion : il en a acheté 5 (2 de la catégorie 1, puis 1 de chaque catégorie).

La suite est évidente : 2 mangas ne lui plaisent pas tant que ça et il regrette de les avoir achetés.

Il était tellement content d’avoir dépensé tout son (mon !) argent !

 

Il a appris que si il avait dépensé moins (moins que le budget maximum) il aurait pu continuer à dépenser correctement son (mon !) argent.

En clair : il n’a pas minimisé son encours et il n’a pas livré souvent.

Il aurait dû se satisfaire de quelques mangas (3 ?), les lire et selon son évaluation améliorer ses décisions pour ses prochains achats.

Il y a un lien direct entre la taille de l’encours et la satisfaction utilisateur : si on minimise l’encours, on accélère le débit donc on livre souvent et donc on recueille des retours plus souvent et on améliore plus souvent.

 

Le Design To Cost maximise l’encours puisqu’on remplit tout pour un montant, maximiser la valeur c’est minimiser l’encours.

 

Maximiser la valeur c’est maximiser les chances d’être content grâce aux retours obtenus à chaque livraison.

Arrêtons de croire que l’on est obligé de tout faire ou de tout dépenser, on ne récoltera pas de retours dans ce cas ou on sera déçu.

 

Le budget maximum est un indicateur. Il traduit une sorte de vision du produit, un niveau de satisfaction à atteindre qui doit aider à prioriser.

 

Le Design To Cost n’est pas agile.

Le Design To Cost a une ressemblance avec l’agile car il commence une conversation : pourquoi ce budget maximum ? Il peut traduire la valeur que l’on veut produire et le ROI, c’est une vision qui doit être expliquée.

 

Quand la bienveillance booste la performance de la communication

La communication

La communication est un art que l’on peut qualifier de complexe, pourtant il repose sur des leviers extrêmement simples, de bon sens. Le plus gros effort a fournir est celui de son positionnement, de son attitude dans la conversation car nous aurons toujours les résultats de ce que nous venons consciemment chercher.

« Comment faut-il que je te parle pour que tu comprennes? »
« Euh… déjà, moins fort! »

Savoir exprimer son point de vue

Je vais illustrer mon propos d’une situation vécue récemment.

Dans une entreprise où les projets sont nombreux, les locaux plutôt anciens et au format box pour 1 ou 2 :
Le PO (Product Owner, représentant du client) exprime le souhait de voir le plateau dans de nouveaux locaux plus spacieux, mieux aménagés, plus enclins à recevoir une équipe agile colocalisée.
Le Client exprime son refus, car il est impossible de trouver ou d’aménager les locaux.
Le PO explique toute la gène occasionnée par l’aménagement actuel et les aspects positifs d’un regroupement des personnes dans un même lieu.
Le Client exprime à nouveau et plus fort son refus.

De là, chacun va camper sur ses positions, n’ayant pas le sentiment d’être compris et le ton monte sans aucun progrès.

Je me permets alors de couper cette conversation stérile pour demander au Client :
« Si tu pouvais le faire, serais-tu OK? »
Le Client répond : « Oui bien sûr, je comprends bien que les salles disponibles ne sont pas facilitantes pour la communication. Aujourd’hui, il est très compliqué de se procurer des espaces adaptés et je ne peux garantir d’y arriver, ni même de trouver un interlocuteur pour faire avancer ce sujet. »
Le PO fait signe de comprendre la situation et ouvre la voie à d’autres solutions plus simples et une mise en place moins urgente, l’équipe pourra faire avec tant que la recherche de solution reste active.

Le problème est-il résolu?

Tout dépend de quel problème on parle.

Le problème de salle est toujours présent. Donc Non.

Le problème relationnel empêchant la résolution du problème de salle, Oui, dans la mesure où nos deux interlocuteurs sont convaincus que l’un et l’autre ont pu partager leur point de vue.

Le problème des salles existe toujours. Néanmoins, le process de résolution est enclenché. Ce qui était impossible est maintenant qualifié, conceptualisé et ouvre la voie à des solutions alternatives. En l’occurrence, il est aujourd’hui envisagé d’abattre des cloisons. Toujours complexe, l’impossible est devenu envisageable.

Dans les communications conflictuelles, je constate souvent que le problème va être identifié à la personne qui l’exprime, alors qu’une démarche constructive permettrait aux interlocuteurs de se placer côte à côte face au problème.

Positionner le problème au centre de la communication, reviens à le poser en filtre entre les interlocuteurs

Placer la recherche conjointe de solution au coeur de la discussion permet de positionner le problème comme l’élément observé, chacun peut participer à la construction de la solution

Quels leviers ?

Cette démarche constructive est souvent de simplement permettre l’expression de ses besoins, de son point de vue (les collines est un exercice que je décrirai dans un prochain article) et que l’autre soit en capacité d’entendre.
Dans notre exemple, le Client aurait pu immédiatement valider la compréhension du besoin et partager son manque de confiance dans la réalisation des souhaits dû au contexte. Le PO aurait pu recentrer la conversation sur ce qui l’importait vraiment, la prise en considération de sa problématique.

Conclusion

Chacun est capable de porter ces actions, pour autant que l’objectif soit en conscience d’apporter des réponses au problème ensemble et pas de se décharger d’un problème connu comme complexe ou d’apporter ses propres solutions.

Dans cet esprit, il est plus aisé d’accepter que l’intégralité de la demande ne sera pas traité parce qu’il est plus facile de juger ensemble de la complexité de sa réalisation. Dans un premier temps, partageons l’analyse de la situation comme un socle sur lequel nous pourrons ensuite construire ensemble notre solution.

En partageant la mise en oeuvre, on partage plus facilement la responsabilité du résultat.

 

sources d’images : CC Pixabay, CC by SA François LAUGIER

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 😉

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.

© 2018 Agile by Example

Theme by Anders NorénUp ↑