Depuis 2009, nous montrons aux entreprises comment utiliser les méthodes agiles pour développer leurs projets de manière plus fiable et plus rapide. C'est de cela qu'il a toujours été question, et c'est exactement pourquoi mon premier livre s'intitule : Scrum – Developing Products Reliable and Quickly. 

Qu'il s'agisse de clients du e-commerce, du commerce de détail, de l'ingénierie automobile, du secteur financier, de l'industrie de la publicité, de la technologie médicale ou du secteur des ONG, nous avons vu de nombreux projets et équipes. Nous avons contribué au développement de spectromètres de masse, de vannes à vide, de simulateurs de vol, de centres d'appels d'urgence, de magasins de commerce électronique, de plateformes Web, de produits d'assurance et de systèmes de communication. Les processus administratifs et RH ont été accélérés avec des moyens agiles ainsi que des grandes implémentations SAP. 

Nous avons organisé des ateliers de vision, des activités de team-building, et donné plusieurs centaines de formations. Nous avons également animé environ 10 000 réunions et accompagné des centaines d'équipes de direction. Des milliers de personnes ont découvert les méthodes agiles grâce à nos formations et cours d'introduction. Si nous devions aligner tous les outils de gestion de projet que nous avons développés avec nos équipes au fil des ans, les nombreux tableaux physiques et virtuels feraient des kilomètres de long. 

Nous avons travaillé avec de grandes entreprises cotées au DAX, des entreprises internationales de taille moyenne, des start-ups de technologie médicale au Royaume-Uni et des petites entreprises. Nous avons collaboré avec des équipes en Belgique et à l'étranger, réparties sur quatre niveaux, quatre bâtiments, voire quatre sites internationaux, dans des projets impliquant plus de 250 personnes ainsi que de petites équipes de 3 personnes. Nos clients incluent des membres de conseils d'administration, des enseignants, des scientifiques et, bien sûr, des développeurs de logiciels. 

Pour vous donner une idée des projets sur lesquels nous avons travaillé, voici quelques exemples (présentés de manière anonyme par respect pour la confidentialité de nos clients) : lorsque nous aurons les autorisations nécessaires et que nous aurons rédigé des études de cas, vous trouverez les références correspondantes. 

Défis et exemples de notre engagement 

Un chef de projet d'un grand projet informatique m'a contacté pour savoir si Scrum pouvait être utilisé pour mobiliser 180 développeurs afin de livrer un produit d'une valeur de 100 millions d'euros en 9 mois. Trois mois plus tard, nous avions organisé 180 développeurs en 18 équipes, le logiciel était livré toutes les 4 semaines, le directeur marketing était satisfait et le logiciel a été mis en ligne après 10 sprints de 4 semaines. 

Le responsable de programme d'une équipe de développement, qui travaillait sur l'un des plus grands portails web internationaux, était confronté à un problème de synchronisation des plus de 160 développeurs. La coordination avec le client et au sein de l'équipe était défaillante. Au lieu de livrer de nouvelles fonctionnalités, ils passaient de plus en plus de temps à corriger des bugs. La solution a été l'une des premières grandes séances de planification en salle, que j'ai appelée à l'époque "planification de sprint de masse". Nous avons affiché toutes les user stories sur le mur et j'ai mis en place la synchronisation des équipes pendant la planification des sprints. C'était fou, mais ça a fonctionné, et c'est devenu plus tard le modèle de toutes les grandes implémentations. Nous avons également soutenu cette initiative avec des formations, du coaching sur le tas, l'amélioration des tableaux de tâches et le coaching des ScrumMasters. Le facteur décisif a été qu'après seulement 4 semaines, les développeurs ont recommencé à fournir beaucoup plus de fonctionnalités. 

Un chef de département responsable du service support d'un grand système SAP – gérant toutes les données clients, contrats et services – souhaitait une plus grande transparence, une meilleure qualité, et des livrables plus fiables. Six mois plus tard, 200 développeurs travaillaient en mode Agile, livrant les projets en un tiers du temps avec moins de défauts grâce à des procédures de test automatisées, améliorant ainsi considérablement la qualité. 

Viva Con Agua organise chaque année la galerie Millentor. Bien que leur travail soit excellent, le stress avant le festival était immense, dépendant de quelques personnes clés, nécessitant ensuite une longue pause pour tous. Nous avons soutenu l'équipe de 5 personnes, développé de nouveaux processus de communication, établi une nouvelle culture de gestion et de livraison, et géré l'équipe élargie de 150 personnes pendant le festival avec des processus clairs et un haut niveau de transparence. Même lorsque le directeur général n'a pas pu être présent en raison d'un accident, l'équipe a si bien géré la situation qu'il a pu se concentrer sur sa convalescence.

Dans une usine de production, il est devenu évident que les employés avaient besoin d'un moyen de communiquer les erreurs pendant l'assemblage. Nous avons développé un système de communication de manière itérative avec l'informatique sur place, dans le hall de montage. Le problème a été résolu de manière prototypique en quelques jours, puis prêt pour la production en quelques semaines, un projet qui aurait normalement pris des années.

Un client voulait savoir comment aider les entreprises informatiques à recruter et intégrer des professionnelles étrangères (féminines) provenant d'Afrique, d'Asie et d'Amérique du Sud. Nous avons constitué une équipe interfonctionnelle de jeunes professionnels de nombreux pays, travaillant à distance, et facilité un processus d'innovation. Après 6 semaines, l'équipe avait généré et testé de nombreuses possibilités. Ce processus est décrit en détail dans le livre "« Agile Innovation Sprint »" par notre société sœur sous la direction d'Andrea Kuhfuss
 Plus d'infos sur ce projet ici.

À la Banque de développement KfW, les méthodes de travail conventionnelles avaient atteint leurs limites. En réponse, nous avons développé un nouveau modèle de coopération (ZAM) avec l'équipe de mise en œuvre « Front-to-End » (FRED), reposant sur quatre principes clairement définis. Nous avons mis en œuvre ce modèle avec nos collègues, formé les employés aux méthodes agiles, et apporté un soutien pratique aux équipes. En 9 mois, environ 500 des 800 employés ont participé à au moins une formation, 40 sessions de coaching d'équipe ont été réalisées et environ 10 réunions de « Communautés de pratique » ont été organisées. FRED a également formé une équipe de transformation avec des consultants externes et le nouveau département d'innovation pour identifier les obstacles et orienter la transformation.  Lire la suite

Nous avons travaillé sur la la transition de la Raiffeisen Banking Group Austria vers une structure bancaire numérique et orientée client, basée sur la vision "regional.digital.everywhere". Grâce à un concept d'architecture de microservices et à un coaching intensif, nous avons établi des processus agiles. Cela incluait des observations pour intégrer les connaissances et des événements d'examen réguliers pour les développements de produits orientés client. En un an, nous avons formé 15 équipes Scrum et des coachs Agile internes. La transformation s'est manifestée par le lancement de la solution de banque en ligne "Mein ELBA" en 2017, résultat direct de nos méthodes agiles. Lire la suite

D'avril 2021 à mai 2022, borisgloger a travaillé pour le groupe Webasto, un équipementier automobile international comptant plus de 15 700 employés dans le monde, afin d’implémenter d'un modèle de travail agile pour le développement de produits. L'objectif était d'améliorer la réactivité et l'efficacité des sites de développement. Grâce à nos conseils, Webasto a développé de manière itérative un modèle agile sur mesure et adaptable, le « Webasto AHEAD Framework ». Ce cadre, construit sur une base théorique et optimisée en permanence pendant la phase pilote et à la mise en pratique de ces-dites theories, permet à Webasto d'effectuer des ajustements futurs indépendamment de nous, et de continuer à peaufiner ce modèle en fonction de leurs besoins. Lire la suite

65 développeurs – à l'époque dans l'une des principales start-ups allemandes – n'ont rien livré. Tout le monde travaillait beaucoup, était engagé, mais les fonctionnalités ne faisaient que s'écouler, les sorties étaient imprévisibles et tout le monde était stressé. Le directeur technique de l'époque m'a appelé et m'a demandé ce qui pouvait être fait. Je lui ai demandé : « À quel point êtes-vous courageux ? Voulons-nous tous changer en même temps ?« Personne n'avait fait ça à l'époque. Normalement, ils procédaient délibérément : d'abord une équipe de pilotes, puis la suivante et ainsi de suite. Nous nous sommes mis d'accord sur exactement le contraire : toutes les équipes à la fois. Si nous, en tant qu'équipe de consultants, venions dans 14 jours, l'organisation serait prête et disposerait de l'infrastructure appropriée. C'est comme ça que ça s'est passé : nous avons formé les équipes et toutes les personnes impliquées pendant une journée et nous avons commencé. 3 sprints plus tard – après 6 semaines – tout le monde était convaincu de Scrum , car les testeurs faisaient désormais partie de l'équipe, les experts en marketing étaient heureux, car leurs idées étaient mises en œuvre et le meilleur de tous : les fonctionnalités présentées étaient d'une telle qualité qu'aucune refonte n'était nécessaire. Peu de temps après, cette entreprise a pu continuer sans notre soutien.

Un département de 150 personnes, qui a écrit le logiciel d'une nouvelle infrastructure très critique, entre autres, n'a pas réalisé son projet le plus important. C'était déjà quelques années trop tard. Bien que certaines parties du produit fonctionnaient déjà avec les clients, cela créait encore plus de stress, car les clients qui souhaitaient apporter des modifications au produit étaient maintenant présents. Après quelques ateliers, il est devenu évident que nous devions restructurer complètement le département. Comment nous l'avons fait : Lors d'un atelier de 45 minutes, nous avons demandé aux équipes elles-mêmes de se répartir dans les domaines appropriés tels que la maintenance, les nouveaux produits et le support pour les autres. Après 45 minutes, tout le monde de la région s'était assigné et nous avons pu commencer à nous concentrer. Tout ce que j'avais fait, c'était appliquer le principe de la loi des deux pieds  de la technologie de l'espace ouvert.

Résultat

Ce ne sont là que quelques exemples parmi des centaines de projets et des milliers de problèmes que nous avons pu résoudre en tant que consultants.

Les frameworks agiles nous aident à résoudre les défis de nos clients, mais ils ne résolvent pas les problèmes eux-mêmes. C'est l'art de nos équipes de consultants de les aider à se concentrer, à livrer ce qu'il faut et à résoudre les nombreux problèmes qui les empêchent de faire leur travail efficacement. Nous avons vu beaucoup de choses et nous sommes heureux d'apporter notre expérience à la table, et nous allons au-delà de la simple acquisition de compétences comme l'organisation de réunions.

Nous serions heureux de discuter personnellement des possibilités et de trouver avec vous la solution à votre défi. Il n'y a généralement pas de solution brevetée, mais il y a de merveilleux principes d'action que nous avons appliqués dans les projets mentionnés ci-dessus. 

La réponse succincte des consultants est souvent : cela dépend. Très souvent, le problème se réduit alors au prix des tarifs journaliers. Cela fournit ensuite une première ligne directrice, mais en vérité, cela ne dit rien sur les coûts auxquels une entreprise sera confrontée si elle décide d'avoir une équipe ou un service accompagné de manière agile. 

Le tarif journalier ne dit rien sur le coût final du projet, car il dépend beaucoup de ce qui est réellement nécessaire pour cette mise en œuvre particulière.

Structure des services pour une offre de transformation agile 

Pour donner une évaluation ici, jetons un coup d'œil à la structure des services d'une offre. 

1. Clarification de la mission : pour les projets plus importants, généralement un atelier 

2. Inventaire : un à plusieurs ateliers 

3. Formation de tous les participants à la méthodologie respective : par exemple, une formation ScrumMaster ou une formation d'introduction agile, une formation d'un à deux jours 

4. Encadrement d'une équipe sur une période de 6 semaines 

• Mais ici, cela peut aussi rapidement conduire au fait que 2 ou 3 équipes doivent déjà être encadrées. 
• De nombreux éléments de formation pourraient être ajoutés ici. 
• Ici, il peut également arriver que d'autres compétences doivent être achetées. 

5. Communication des résultats à l'entreprise par le biais d'un rapport ou d'un support de communication continu. 

6. Travailler avec les managers pour apporter des changements ici aussi 

• Formation des managers 
• Ateliers réguliers ou au moins discussions pendant la phase du projet 

7. Rapports/documentation des mesures 

8. Un atelier sur les leçons apprises et une prochaine étape à la fin des 6 premières semaines. 

9. En outre, d'autres discussions et réunions de coordination sont organisées si nécessaire 

Si vous lisez les sujets ci-dessus et que vous estimez brièvement l'effort nécessaire à ce travail et considérez brièvement les compétences dont les personnes qui sont censées faire tout cela ont besoin, vous serez certainement d'accord avec nous - cela nécessite de l'expérience et une formation dans plus que la gestion agile.

Cela nous amène à la réponse à la question de savoir pourquoi une implémentation agile qualitative n'est en fait pas disponible à un prix réduit.

Les consultants qui peuvent faire tout cela ont besoin de:

1. Compétences dans la direction d'équipes et d'organisations de grands projets, 

2. la compétence pour mener des réunions, des formations et des ateliers efficaces, 

3. la capacité à établir une coopération de confiance au sein des équipes et avec le reste de l'organisation, 

4. la connaissance de la manière d'accroître la capacité à fournir et à réduire la dette technique, et 

5. Un haut degré de compétence en résolution de problèmes

À cette fin, nous utilisons des employés que nous avons non seulement envoyés à des formations internes, mais aussi à des formations externes de coaching et d'animation, qui sont non seulement familiers avec les différents formats de gestion agile, mais peuvent également les former et qui utilisent des outils de collaboration pertinents tels que Slack, MS Teams, Zoom, Miro, Jira, Asana et bien d'autres. et savoir préparer visuellement les problèmes pour les équipes.

Par conséquent, afin de maintenir notre standard de qualité, nous devons facturer entre 40 000 et 50 000 euros pour le soutien d'une seule équipe sur une période de 6 semaines. Cela signifie que nous ne sommes pas au sommet de l'échelle des services de conseil pour cette envergure, mais nous n'offrons pas non plus nos services à un prix réduit.

Pour être un peu plus précis

Voyons comment ce chiffre se produit.  Dans la première période de coopération, les 3 premiers sprints (1 sprint de 2 semaines chacun), nous nous appuyons sur l'accompagnement à temps plein de la ou des équipes par un ScrumMaster ou un Coach Agile, soit 4-5 jours sur une période de 6 semaines pour un consultant.

De cette manière, nous assurons l'introduction réussie et à long terme du modèle de travail agile au niveau opérationnel. En parallèle, il y a généralement une coopération avec l'équipe de transformation ou la direction à un niveau stratégique, afin que le cadre de l'organisation puisse être adapté et mis à disposition de manière à ce que le travail agile soit possible en premier lieu. C'est là qu'intervient l'un de nos coachs en transformation, qui travaille avec l'équipe de transformation du client une à deux fois par semaine.

Après cette première phase intensive, nous verrons : Où en est l'équipe ? Pouvons-nous réduire un peu la coopération ? Si c'est le cas, l'accompagnement sera réduit à environ 2 jours/semaine sur les 3 prochains sprints.

Chez l'un de nos clients, nous avons d'abord travaillé avec les 8 managers dans de nombreux ateliers pendant des semaines - afin d'obtenir une ligne uniforme ici, puis nous avons travaillé avec les 150 employés dans d'autres ateliers. Ce processus a traîné pendant plusieurs mois.

Cela vaut-il la peine pour les entreprises?

Nous pensons que oui. Par exemple, dans l'un de nos projets clients, nous avons non seulement économisé 400 jours-personnes par semestre à 3 de nos consultants en seulement 3 mois, mais les délais de traitement d'une organisation de 200 employés ont pu être réduits d'un tiers en moyenne, tout en augmentant la qualité et la fiabilité des livraisons.

Un investissement dans la performance d'une équipe peut être très élevé à première vue – c'est pourquoi il est si important pour nous que nos clients sachent ce qu'ils attendent et que nous calculions l'analyse de rentabilisation du changement. 

Nous ne pouvons répondre à cette question que de notre point de vue, et je m'excuse donc à ce stade que nous ne soyons certainement pas objectifs à cent pour cent ici. 

Des structures rigides à la flexibilité dynamique : le changement de paradigme dans le conseil en management

En tant que personne qui a expérimenté à la fin des années 1990 le fonctionnement des cabinets de conseil classiques et qui s'est rendu compte que le changement réel devait être fait par les personnes conseillées elles-mêmes – de nombreux concepts semblaient bons sur la diapositive PowerPoint, mais manquaient la réalité de la vie des personnes dans les entreprises, je voulais créer un cabinet de conseil avec borisgloger qui non seulement conceptualise,  mais surtout des outils.
 
Nous sommes des acteurs. Pour nous, c'est toujours la différence fondamentale entre le conseil classique et notre compréhension du conseil en management agile. 

Cette différence repose sur l'idée profonde que seuls les systèmes des clients peuvent résoudre leurs propres défis, mais que leurs propres processus, qui viennent d'un autre temps, le paradigme industriel, se dressent sur leur chemin.

En même temps, au cours de nombreuses années de consultation, nous avons remarqué que les systèmes des clients ne changent pas, car ils sont

1. Il n'y a pas d'image claire de la direction que prend le voyage – il y a encore trop peu d'expérience de ce à quoi peut ressembler une organisation moderne, et 
2. Deuxièmement, il y a un manque de savoir-faire pour innover. Il y a tout simplement un manque de savoir-faire pour travailler avec les nouveaux outils (Test Driven Development, Cloud, Microservice Architecture, MS Teams, Miro). Cela peut être très bien observé à nouveau dans la peur de l'IA générale. Ce n'est pas parce qu'ils savent comment fonctionnent Chat GPT et Cie, mais les gens dans les entreprises ne savent tout simplement pas encore comment ce nouvel outil peut être utilisé de manière bénéfique. Une merveilleuse conférence sur la façon dont l'IA devient un collègue peut être trouvée ici

Nous comprenons que le travail d'un cabinet de conseil en gestion agile consiste à combiner exactement ces deux aspects. D'une part, le changement dans l'entreprise doit aider à rendre l'organisation à nouveau fonctionnelle, et d'autre part, il doit éliminer la peur des gens de suivre le changement.

L'approche traditionnelle : un monde de plans et de prévisions 

Le conseil traditionnel a ses racines dans un monde qui valorise la stabilité et la prévisibilité. Ici, les problèmes sont identifiés grâce à une analyse détaillée qui conduit à des solutions globales et à des stratégies à long terme. Ces solutions, souvent documentées dans de gros volumes de rapports, suivent un plan strict conçu pour l'efficacité et le contrôle.

De nombreuses entreprises paient des consultants pour leur donner des connaissances sur la concurrence – tout le monde connaît la fameuse stratégie des cabinets de conseil en management qui expliquent qu'il existe un soi-disant benchmark qu'il faut utiliser comme guide. Ils paient ensuite bien pour ces analyses.

Ensuite, une stratégie est créée pour expliquer exactement comment ce qui doit être réalisé doit être réalisé.

Tout cela suit l'idée classique qu'une organisation est une horloge qui peut être changée en utilisant de nouveaux engrenages et en mobilisant les gens par le biais de nouveaux processus. 

Le processus est hiérarchique et descendant, et après qu'une décision a été prise sur la façon dont l'organisation doit changer, il est alors exigé que les autres travaillent de cette manière. Le succès se mesure au strict respect des budgets et des calendriers, ainsi qu'à l'atteinte d'objectifs spécifiques et prédéfinis.

Cette approche a fonctionné – bien sûr, si toutes les entreprises font fondamentalement la même chose, vous pouvez vous orienter vers la concurrence et essayer de faire un peu mieux ce que font les autres.

Les cabinets de conseil en gestion qui soutiennent cette vision du monde fonctionnent alors en interne tout comme leurs clients : hiérarchiques eux-mêmes et les groupes inférieurs deviennent les exécutants des consultants seniors.

La révolution agile : la flexibilité et l'itération comme clés du succès

En revanche, le conseil agile comprend une organisation comme un système de communication. Dans lequel il n'y a aucune chance d'intervenir simplement comme un mécanicien. Au contraire, le système doit se changer lui-même – cela se fait par une approche itérative et progressive.

Bien sûr, une analyse doit d'abord être effectuée ici aussi – le problème doit être compris. Mais il s'agit d'une vision de ses propres capacités. Nous ne cherchons donc pas à savoir si les autres sont meilleurs, mais si votre propre organisation atteint ce qu'elle a prévu de faire – et à montrer à l'organisation comment elle peut se fixer ces nouveaux objectifs. 
 
Ici  

• d'une part, procéder de manière éprouvée en s'appuyant sur le Design Thinking. Le plus grand nombre de personnes possible est impliqué afin de comprendre le problème (découverte) ainsi que d'impliquer tous ceux qui contribueront plus tard à façonner le changement. 

Cela peut être 

• Être complété ou remplacé par la réalisation d'une enquête sous la forme d'un Business Agility Vital Check. Cette analyse est très rapide et rentable pour les organisations qui souhaitent d'abord se faire une idée des problèmes de l'organisation. Il est structuré de la même manière qu'un test de personnalité.

Après l'analyse, cependant, l'objectif n'est pas d'élaborer des plans complets,  mais de résoudre les problèmes  qui empêchent les objectifs de l'organisation d'être atteints le plus rapidement et le plus efficacement possible. Nous nous appuyons sur des sprints à cycle court, qui permettent à l'organisation de réagir rapidement aux influences extérieures et d'adapter ses stratégies en conséquence. Ici, l'accent n'est pas mis sur le plan global, mais sur la capacité d'adaptation et d'amélioration continue. 

Cela ne peut se faire qu'ensemble – et le changement et la gestion du changement font donc déjà partie du plan.Ceux qui effectuent leur changement de manière itérative et incrémentielle utiliseront également cette capacité pour développer leurs propres produits. 

Nous changeons donc l'organisation en apportant quelque chose de nouveau d'une manière différente.

Si la capacité de l'organisation augmente et que c'est exactement ce qui est fait, l'organisation est différente d'avant et le changement a réussi.

Le rôle des employés : du destinataire des commandes au designer

En d'autres termes, la principale différence dans le conseil réside dans l'implication des employés. Alors que les projets de conseil classiques ont souvent une séparation claire entre les consultants et l'équipe client, le conseil agile favorise une culture collaborative pendant le processus de changement. Ici, toutes les personnes impliquées sont activement impliquées dans le processus de prise de décision, ce qui augmente non seulement l'acceptation des changements, mais améliore également la qualité des résultats.

Les équipes sont habilitées à agir de manière auto-organisée et à participer directement au développement des solutions. Le principe derrière cela n'est pas la persuasion théorique, mais  l'action active afin d'acquérir de nouvelles connaissances. Seuls ceux qui ont fait l'expérience de la rapidité avec laquelle les projets peuvent être livrés lorsque vous en faites moins en même temps et que vous finissez par livrer plus dans l'ensemble, même si vous travaillez moins, le comprendront. Nonaka a appelé cela l'apprentissage implicite – l'idée que de nouvelles connaissances sont créées en faisant au lieu de penser et de planifier. Nous l'avons appelé un jour : « Faire comme façon de penser » et c'est exactement ce que nous défendons avec notre slogan : Want.Do.Be capables de le faire.
 

Faire face au changement : une question de perspective 

Une autre différence fondamentale est la façon dont nous gérons le changement. Dans le conseil traditionnel, les changements sont souvent considérés comme un risque qui doit être minimisé. Ici, de nombreux managers aiment tomber sous le charme des belles photos (les plans bleus) des consultants en management classiques. On nous demande souvent à quoi ressemble notre modèle standard, et lorsque nous répondons : « Il n'y a pas de modèle standard car chaque entreprise est différente », beaucoup de nos clients ne sont pas satisfaits de la réponse. Oui, il nous est en effet difficile de livrer un plan.

C'est pourquoi nos consultants ont pris la peine de montrer avec leur livre « Agile Transformations – Off the Happy Path » que les entreprises qui veulent changer de manière agile doivent être préparées à certaines turbulences. 

Et nous avons développé notre propre modèle de mise à l'échelle – un modèle qui n'en est pas un du tout, mais qui montre seulement où une organisation pourrait et devrait peut-être changer quelque chose.

Cependant, ces turbulences sont l'opportunité. Après tout, les changements sans regarder et travailler ensemble pour atteindre l'objectif d'apporter une véritable intégration de la nouveauté dans l'entreprise passent à côté de l'essentiel. Le conseil agile – y compris le nôtre – en revanche, voit le changement comme une opportunité. La nature itérative du processus agile signifie que nous attendons le changement, voire l'acceptons, et que nous le considérons comme faisant partie du flux naturel des projets. La résistance ici est toujours l'information que quelque chose n'est pas encore fait dans l'organisation pour être conseillé.
 
La résistance est donc toujours une information – pour montrer la nature du système : « Attention – il y a quelque chose à considérer ici." Cette approche vous permet ensuite de concevoir ensemble les prochaines étapes. Voir aussi ce texte de notre collègue   

Expériences personnelles et art du conseil agile 

De par mon expérience personnelle, je constate que l'art du conseil agile va bien au-delà de la simple application de méthodes. Oui – bien sûr, de nouvelles connaissances doivent être acquises et consolidées par la pratique. Mais le but est d'établir une organisation en apprentissage continu. Observer le développement d'une culture de réussite, d'ouverture, d'apprentissage continu et de responsabilité partagée est merveilleux. Il est merveilleux de voir comment chaque individu de l'entreprise ne fait pas seulement partie du processus, mais participe activement à la construction de l'avenir et assure ainsi la viabilité future de sa propre profession.

Finalement

La décision entre le conseil classique et le conseil agile ne doit pas être prise à la légère. Il se peut que d'une part, le changement vers de nouvelles méthodes de travail doive être effectué par le conseil agile – comme le nôtre – mais les compétences substantielles pour travailler d'une nouvelle manière (z.B. 3D l'impression ou les nouvelles technologies) peuvent être des conseils professionnels d'un type très classique.

Mais nous savons maintenant que chaque changement technologique dans les entreprises a toujours une composante sociale. Les nouvelles technologies ne deviennent efficaces que lorsque les anciennes méthodes de travail ou de comportement sont également modifiées. Mais c'est exactement ce qui ne peut arriver qu'aux gens, pas contre eux ou pour eux.

Lors d'entretiens personnels avec nos clients, nous explorons toujours quelle approche est la plus appropriée pour relever les défis spécifiques. Il n'y a pas de solution unique, mais il existe des principes éprouvés et une base d'expérience approfondie que nous utilisons pour travailler avec vous non seulement pour résoudre les problèmes, mais aussi pour ouvrir de nouvelles opportunités. 

"Qu'est-ce que cela nous apporte ?» – C'est non seulement une question justifiée, mais surtout vraiment importante avant qu'une entreprise ne se lance dans un projet agile. Parce qu'une chose est évidente lorsque vous faites appel à un consultant comme nous pour vous aider à adapter un projet ou une unité commerciale à l'aide de cadres de gestion agiles et de nouvelles méthodes de travail, car nos services de conseil coûtent de l'argent. 

Formations et ateliers pour les employés, mises à jour de l'infrastructure technique pour qu'ils puissent travailler ensemble de manière plus efficace et plus fluide, modularisation de l'architecture du produit – tout cela coûte du temps et de l'argent – et si ce service de conseil et la conversion de l'infrastructure, l'expansion des compétences des employés étaient rentabilisés très rapidement ? Dans certains cas, en quelques semaines, parfois même en 90 minutes. 

Augmentez l'efficacité et réduisez les coûts grâce à la transformation agile 

On nous avait demandé de travailler avec l'équipe sur un cas réel ouvert lors d'un atelier de formation agile. Un projet qui dure depuis 3 ! années. Le rapport final manquait ; il lui restait encore un million d'euros d'impayé. 

Après la matinée, où nous avons expliqué les méthodes de travail agiles de base, nous avons utilisé 90 minutes pour aborder ce projet à l'aide du travail flash. 90 minutes plus tard, l'équipe était non seulement claire sur ce qui devait être fait, mais elle l'avait fait. L'argent est revenu. Investissement rentable – nous le pensons.  

Mais les coûts peuvent également être réduits. L'objectif de toute méthode de travail agile est de concevoir la collaboration au sein et entre les équipes d'une organisation de manière à ce que le lest inutile des processus – les « déchets » – puisse être éliminé. Cette étape à elle seule a un impact sur les coûts. Les temps d'attente sont réduits et l'entreposage est réduit car il n'y a pas de temps d'arrêt. 

Tout cela peut être mesuré, et voici le point crucial de tout projet d'implémentation agile : 

Quel problème dois-je améliorer ? 

Le problème avec StudiVZ était que le logiciel n'était plus livrable. Au lieu d'offrir constamment aux utilisateurs de nouvelles fonctionnalités et de rester ainsi attractifs tout comme Facebook, les développeurs ont moins livré des problèmes bien connus du développement logiciel. Après seulement 6 semaines, ce problème a été éliminé. 

En 2005, Salesforce.com connu exactement le même problème. De plus en plus de développeurs livrent dans des délais de plus en plus longs. En 2006, l'une des premières transformations agiles a eu lieu – le résultat : la capacité à livrer a augmenté de manière exponentielle – l'une des plus rapides du secteur. Voir ce diaporama 

Les deux entreprises ont pu  exprimer leur problème en chiffres : quelques jours avant la prochaine version ; ceux-ci ont augmenté sans travail agile et ont chuté rapidement avec le travail agile. 

Nous recommandons toujours à nos clients de voir leurs KPI existants sous forme de courbe de fibre. Qu'est-ce qui est important en ce moment ? Ventes, rentabilité, time-to-market, satisfaction client : ces KPI doivent être améliorés par la mise en place de méthodes de travail agiles. 

Comment trouver ces KPI pertinents ? 

Avec les experts du système client, nous passons en revue une série de questions visant à la fois l'efficience et l'efficacité. Ces questions sont délibérément simples : l'objectif n'est pas de calculer des montants précis au centime près, mais de développer un sens des implications financières. 

Un jour, nous avons demandé à un directeur général combien d'argent il perdrait si le produit que nous développions ici en tant qu'équipe était au salon un seul mois plus tard, car nous avons maintenant besoin d'un mois pour décider de dépenser 100 000 ou 140 000 euros – et donc l'équipe n'arrive à rien. Il déclare : Chaque mois plus tard, nous perdons au moins un client pour une durée de 10 ans, soit environ 10 millions d'euros de ventes perdues. 

Cette évaluation suffit souvent à justifier la prise de mesures dans l'entreprise. 

Des questions similaires à celles de l'exemple sont les suivantes 

• Quels effets pouvons-nous obtenir si les collègues du département peuvent se concentrer et travailler sur une seule chose dans une équipe ? 
• Quels coûts supplémentaires peuvent être évités si des développements malavisés sont détectés plus tôt ? Combien d'efforts faut-il en moins pour accomplir des tâches si la transversalité dans l'équipe est augmentée pour un échange rapide et fluide ? 
• Quelle accélération serait possible si les obstacles actuels étaient systématiquement levés et donc démantelés ? 
• Combien de temps peut-on gagner dans la gestion si les efforts de reporting sont considérablement réduits ou supprimés ? 
• À quel point une équipe peut-elle être plus rapide si elle prend elle-même des décisions ? 
• Combien de revenus supplémentaires l'entreprise pourrait-elle générer si elle pouvait mettre ses produits et services sur le marché plus tôt ? 
• De combien la satisfaction client peut-elle augmenter si les produits et services sont plus en adéquation avec les attentes et les besoins des clients et des utilisateurs ? 

Si vous comparez les résultats de ces estimations d'économies avec les coûts possibles de la mise en œuvre agile, vous pouvez au moins voir un premier indicateur de la rentabilité des investissements. 

Attention : Peu d'indicateurs clés de performance – concentrez-vous ici aussi 

Notre recommandation est la suivante : Concentrez-vous sur un maximum de quatre sujets que vous souhaitez rendre à la mesure de vos améliorations. Pour ce faire, trouvez une à un maximum de 2 valeurs que vous souhaitez mesurer – et il doit s'agir de valeurs mesurées que vous pouvez mesurer très facilement, de préférence automatiquement. 

Exemple 1 : Projet à grande échelle - plus d'efficacité en réduisant les pertes de temps 

Situation de départ 

Dans un grand projet de plus de 1 000 employés, un effort de planification considérable a été déployé : la coordination a été effectuée, la coordination et la replanification ont dû être effectuées en permanence. Une gigantesque perte de temps. « Nous ne pouvons plus travailler » sont des citations qui reviennent dans de tels projets. 

Solution 

Nous avons maintenant convenu d'un intervalle de planification de 3 mois qui rassemble toutes les fonctions de direction et de coordination (> 100) sur site sur 2 jours pour planifier les prochains mois. Cela réduit considérablement l'effort de planification. Il est difficile de planifier à l'avance, car les efforts de planification ne sont presque jamais suivis. Ici, il est difficile de mesurer si « Nous ne nous mettons plus au travail ! » se transforme en « Maintenant, nous travaillons plus efficacement et de manière plus ciblée ». 

Exemple 2 : Entreprises informatiques – développement  
 
 de produits plus rapide 

La situation de la commande est délicate car, d'une part, le client veut voir le produit rapidement et est très incertain en raison des retards initiaux quant à savoir si l'équipe de développement sera en mesure de livrer ce qu'il a promis. 

Solution 

Nous avons supprimé 2 équipes de développement de l'organisation de R&D existante (environ 70 personnes), les avons équipées de propriétaires de produits et de ScrumMasters , puis nous avons commencé par itérations. Notre objectif était de mettre en place un premier incrément produit exécutable en 8 itérations (16 semaines) et ainsi regagner la confiance du client. 

Tout le monde a été étonné qu'il ait été livré si rapidement. En plus d'introduire Scrum, de générer une concentration et une attention totale de la direction, un facteur de succès important a été que nous avons pu économiser le travail de conception d'une architecture finale, mais que nous avons plutôt fait des hypothèses approximatives, les avons essayées et les avons ensuite développées de manière itérative. Cela a permis de gagner des semaines par rapport à la procédure classique. 

Exemple 3 : Deutsche Bahn - Efficacité dans la génération des subventions

Situation initiale 

Le Rhin-Ruhr Express (RRX) est l'un des plus importants projets d'infrastructure ferroviaire de la Deutsche Bahn. Des capacités supplémentaires seront créées sur la ligne Cologne-Düsseldorf-Duisburg-Dortmund, ce qui nécessitait une meilleure connexion de 6 « branches extérieures » – les voies d'accès à la ligne principale – d'ici la fin de l'année 2019. Pour la conversion de 52 gares, la division régionale ouest de DB Station & Service AG a dû demander un financement. Des procédures claires doivent être suivies ici afin de recevoir les avis de délivrance. En interne comme en externe, de nombreuses interfaces doivent être surmontées. Les changements doivent être notifiés à l'organisme subventionnaire et les demandes originales doivent être révisées. Le processus recommence donc jusqu'à ce que l'avis de délivrance mis à jour soit émis ; ou il y a des questions qui impliquent plusieurs départements pour y répondre. Sans visualisation et coordination claire, de telles situations de projet sont prédestinées à l'inefficacité. 

 
Solution 

Afin de garder une vue d'ensemble des 52 sous-projets et d'accélérer le processus, l'équipe responsable a visualisé le processus de demande sur un tableau de projet de 4 mètres sur 2, regroupé selon les six branches extérieures. Le matin de chaque jour ouvrable, l'état d'avancement de tous les projets a été discuté dans un délai de 15 minutes ciblées. Pour les sujets qui ont dû être résolus par plusieurs experts, la conversion des réunions en réunions de travail interfonctionnelles, à l'issue desquelles de la fumée blanche s'élève, c'est-à-dire qu'un résultat doit être atteint, a fait ses preuves. Cela signifie que toutes les personnes nécessaires à un sujet travaillent ensemble dans une même pièce jusqu'à ce que toutes les questions soient résolues. S'il y a des points ouverts, les parties concernées s'engagent sur-le-champ à un autre rendez-vous. 

Le résultat a été impressionnant : 

• Le nombre d'avis reçus est passé de 3 en 2017 à 35 en 2018.  
• La vue d'ensemble de tous les projets a également facilité la réaffectation des capacités. 
• La satisfaction au travail a considérablement augmenté car la répartition des tâches est plus claire et les progrès sont visibles sur le tableau. 
• Le fait que les co-créateurs et les idées contribuent a attiré de nombreux jeunes candidats. 
• Le travail agile a également été étendu à d'autres programmes, par exemple à la preuve d'utilisation finale pour l'organisme de financement (c'était l'exemple ci-dessus : 1 million en 90 minutes).  

Exemple 4 : Webasto - propre modèle de travail pour le développement de produits

Situation initiale 

Depuis des décennies, le fabricant d'équipements d'origine Webasto produit avec succès des solutions pour l'industrie automobile. Compte tenu de la dynamique croissante et des nouvelles tendances du marché automobile, le groupe d'entreprises a commencé sa transformation agile sur mesure avec l'objectif de s'éloigner de l'organisation de projet et de s'orienter vers une organisation de produits orientée client. Un modèle de collaboration efficace pour les sites de développement devait être identifié afin  de mobiliser plus fortement l'expertise interne de Webasto et ainsi réagir plus rapidement à la dynamique du marché.  
 

Solution 

Les chefs de produit ont reçu suffisamment de conseils pour constituer des équipes appropriées et les équipes de produit ont bénéficié de la plus grande liberté de conception possible pour pouvoir travailler efficacement. 4 aspects cibles importants pour Webasto ont été identifiés. Le cadre doit  aligner l'orientation de toutes les activités sur la création de valeur,  soutenir la réactivité de l'organisation, permettre une collaboration autoresponsable et auto-organisée  sur un pied d'égalité et  se concentrer sur les solutions plutôt que sur les processus.  

Résultat 

• Les premiers succès ont été évidents dans la coopération : la nouvelle composition de l'équipe permet aux membres de l'équipe de travailler de manière plus ciblée et de mieux contribuer. 
• Être capable de rester concentré signifie économiser des coûts de transaction car les membres de l'équipe n'ont plus à passer constamment d'un contexte à l'autre. 
• Le reporting nécessite moins de temps de préparation et les questions de compatibilité sont clarifiées si tôt dans le développement qu'il n'y a pratiquement aucun obstacle à l'intégration.  
• Dans l'ensemble, la collaboration interfonctionnelle a considérablement réduit les temps d'attente, car les questions peuvent être clarifiées plus rapidement et les tâches traitées plus rapidement. 

Lire la suite 

Exemple 5 : Festival de Millentor – organisation d'événements avec une petite équipe et un grand impact 
 

Viva Con Agua Arts accueille chaque année le Festival Millentor. Art et musique dans le stade. Cinq employés le font là-bas et avec plusieurs centaines de bénévoles. Chaque année, cette équipe devait prendre quelques semaines de congé après ce tour de force. C'est très stressant à chaque fois. 

Solution 

Nous avons offert notre soutien à cette cause caritative pro bono. Notre équipe de consultants a aidé l'équipe quelques heures par semaine. Le résultat a été un événement complètement détendu du festival et même l'omission de personnes clés importantes avant l'événement n'est pas un véritable défi. 

Les 10 principales améliorations 

Avec un article de blog comme celui-ci, où l'on tente réellement de présenter la rentabilité de l'adoption de méthodes de travail agiles, il y a le problème que les clients n'aiment pas publier ces choses. Les deux exemples ci-dessus sont une véritable exception. 

Mais d'après notre expérience, il y a 10 aspects qui reviennent sans cesse - que ce soit dans le développement de matériel, le développement de logiciels, l'organisation de festivals ou le travail avec les étudiants : 

1. Une communication efficace entre les départements et cela signifie souvent une accélération drastique des processus. 
2. Le traitement des erreurs et les retouches sont considérablement réduits. 
3. Les projets sont traités beaucoup plus rapidement. 
4. Niveaux de stock. Dans le secteur de la quincaillerie et de la production, les stocks diminuent considérablement. 
5.  La satisfaction des clients augmente. 
6.  La satisfaction des employés augmente considérablement. 
7. Le débit des projets dans les entreprises augmente à pas de géant 
8. Les employés acceptent le leadership de manière solidaire  et reconnaissent à quel point il peut être efficace. 
9. Les produits sont construits beaucoup plus près de l'avantage du client. Les fonctionnalités développées répondent au besoin 
10. La fiabilité  est perçue positivement et la confiance mutuelle augmente. 

Dans l'ensemble, les entreprises économisent des coûts élevés et atteignent une productivité beaucoup plus élevée en introduisant des méthodes de travail agiles - comme nous avons pu le constater à maintes reprises.  

La réponse à la question : « Quel est l'intérêt ?» C'est donc toujours lié à la contre-question : Qu'est-ce qu'il est censé accomplir ? Comment mesurer cela ? Et puis nous commençons et après un court laps de temps, nous mesurons si nous avons atteint notre objectif ? 

Les évangélistes agiles de la première heure, dont je faisais partie, avaient l'avantage et l'inconvénient de ne pas pouvoir acheter de consultants externes qui nous auraient montré comment fonctionne le travail agile. J'ai fait venir Ken Schwaber à Vienne en 2004 dans ma première  équipe Scrum et je l'ai laissé parler à mes 5 développeurs, mais ce n'était pas du conseil au sens où il existe aujourd'hui. 

Puis, quelques mois plus tard, le département de développement logiciel de l'ancien Web.de m'a appelé : Andreas Schliep, alors chef d'équipe du développement logiciel et aujourd'hui cofondateur de la société de conseil « Das Scrum Team ». Il m'a demandé de les aider à  essayer Scrum  ; ils avaient déjà commencé comme moi à l'époque et ensemble nous avons commencé à apprendre à travailler de manière agile.   

Aujourd'hui encore, les membres de leur organisation commencent  à expérimenter eux-mêmes Scrum et d'autres cadres de gestion, et certains ont même la chance d'avoir déjà pu acquérir une expérience approfondie dans d'autres entreprises. Je viens de parler à une sorte de responsable de l'innovation dans une grande entreprise, qui agit lui-même en tant que consultant et modérateur en interne pour apporter les principes agiles dans l'organisation.  Alors oui, il est possible de commencer la transformation agile par vous-même. 

Et – cette approche est plus lente 

Souvent, il n'y a pas de décision consciente de la part de la direction de préconiser un changement dans la façon de travailler. Cela signifie que de nombreuses activités se déroulent en secret ou tolérées. 

Une grande entreprise avait 50 projets dans lesquels des procédures agiles étaient testées sans que les chefs de service ne le sachent. Ce n'est que lorsque nous avons conçu les ateliers de leadership avec eux de manière à ce que ces projets y apparaissent que nous avons commencé à comprendre pourquoi ces sujets avaient du succès. 

De notre point de vue, les avantages évidents de contacter un consultant sont : 

• Il y a déjà une volonté de changement lorsque des consultants externes sont embauchés. Cependant, souvent uniquement avec la personne qui passe la commande. Ici, la compétence des consultants est souvent requise pour motiver les équipes et les managers à essayer une nouvelle approche afin de pouvoir déterminer par eux-mêmes l'utilité de cette nouvelle façon de travailler. Dans le cas de – aujourd'hui on dirait transformation – de l'informatique dans une entreprise énergétique, il était également clair dès le départ qu'il y avait des attentes et donc aussi l'attention de la direction pour cette action. Cette décision a également été utile pour parler aux fournisseurs de services externes. Il est apparu clairement que le travail devait désormais être effectué dans des conditions différentes. 
• À mon avis, le deuxième facteur essentiel est le savoir-faire et l'expérience que les clients achètent par le biais de conseils externes. Web.de'avais adhéré à cause de mon expérience. C'est toujours le cas aujourd'hui – nous sommes convaincus par notre expérience désormais très étendue. Nos conseillers ont vu beaucoup, beaucoup. Différents secteurs, différents défis, différentes cultures et de nombreuses équipes, projets logiciels et matériels différents. L'un de nos consultants apporte même le savoir-faire des ONG et peut montrer comment faire de l'Agile dans les arts. Oui – il peut y avoir un coup de chance qu'une organisation ait embauché quelqu'un qui a également vu tout cela (et, par exemple, embauché un ancien employé de borisgloger), mais ce n'est généralement pas le cas. Nous faisons toujours l'expérience qu'il y a simplement un manque de savoir-faire – la certification ne fait pas un bon coach ou consultant. 
• Le troisième point : le hub agile s'achète également. Il est souhaitable de mettre en place un hub agile, c'est-à-dire un cabinet de conseil interne composé de 5 à 10 consultants, qui s'occuperont tous ensuite des équipes au sein de l'organisation, mais cela prend du temps. Il faut beaucoup de temps et d'énergie pour que cette équipe puisse se lancer. (Certaines de nos missions de conseil consistaient à constituer ces mêmes équipes, ce qui a ensuite ralenti la transformation dans d'autres domaines). Mais - bien sûr, c'est la bonne voie à long terme. Mais si vous voulez saisir l'opportunité, vous avez besoin de la rapidité de membres d'équipe expérimentés et bien coordonnés qui n'ont qu'un seul objectif : satisfaire les clients et qui n'ont pas à réfléchir dans leurs propres rangs à qui sera mieux reçu par le patron afin de promouvoir leur propre carrière. Vient ensuite le fait que même une grande équipe de projet que nous pouvons fournir n'a pas encore tout vu, mais les autres consultants de borisgloger peuvent vous aider à tout moment. Que ce soit assez banal dans le cas des remplacements de vacances, les équipes clients ne sont alors pas laissées seules, mais continuent d'être gérées efficacement ou par chance que nos collègues peuvent compter sur le soutien (en termes de contenu et de morale) de nos collègues à tout moment. 

C'est peut-être l'inconvénient décisif d'essayer de faire le changement en interne. 

Le changement est un travail difficile, souvent commencé avec beaucoup de passion, mais il arrive que la frustration surgisse inévitablement. Si vous essayez en vain de convaincre une équipe ou un manager, ou peut-être avez-vous même eu une discussion houleuse avec votre propre manager, où va cette personne ? À un collègue ? Cela empoisonne encore plus l'atmosphère, au prochain manager - un tabou dans de nombreuses organisations. Le sentiment d'impuissance est vite accablant et le consultant interne quitte l'entreprise frustré (j'ai vu cela très souvent). 

• La quatrième raison de travailler avec des consultants externes est l'objectivité et l'affirmation de soi. L'une des raisons pour lesquelles j'ai fondé borisgloger était que je voulais offrir un refuge sûr à nos consultants. Ils doivent pouvoir exprimer leurs opinions ouvertement et honnêtement aux clients. Ils devraient être en mesure de souligner ce qui est le cas et de présenter les faits – sans avoir à craindre que ces résultats objectivés puissent nuire à leur carrière. Un consultant externe voit toujours les choses telles qu'elles sont. La célèbre histoire des « Habits neufs de l'empereur » l'illustre : un consultant est naïf, politiquement libre et suffisamment ouvert pour pouvoir aborder les parafonctionnalités d'une organisation. Il ne sait pas que c'est comme ça que ça se passe ici, parce que c'est toujours fait comme ça. Il ne sait pas non plus ce qui ne fonctionne pas et le fait simplement – et souvent cela montre aux collègues internes ce qui pourrait fonctionner.  Par exemple, un collègue a dévissé une vitrine murale parce qu'il avait besoin d'espace pour un tableau blanc et un tableau de tâches. Il ne savait pas qu'il fallait obtenir l'autorisation de la direction des installations, ce qu'il n'aurait jamais obtenu. Lorsque cela a été connu, il y a déjà eu un tollé, mais au fur et à mesure que l'équipe est devenue plus efficace, ce cri s'est arrêté et l'organisation a pu vivre avec le fait que ce meuble n'était pas nécessaire. 

Mais comme mentionné plus haut, en 2024, il y a souvent déjà des personnes dans les organisations qui travaillent avec des méthodes agiles, ou du moins en ont entendu parler pendant leurs études. 

Le véritable art du consultant externe réside dans le fait de bien travailler avec d'autres consultants externes, mais surtout avec des consultants internes et des employés. 

Il ne s'agit pas seulement d'apprendre les uns des autres. Les employés internes peuvent parfois prendre plus de temps ou ils peuvent étayer le changement avec d'autres arguments. Par exemple, le développement organisationnel interne d'une banque a commencé à travailler avec des méthodes agiles ; Déclenché par les expériences de nos collègues et c'est exactement cet exemple qui a ensuite créé un précédent et convaincu à nouveau d'autres équipes. 

Et parfois, comme c'est le cas dans une grande entreprise, il arrive que les consultants externes soient autorisés à dire des choses qui sont ensuite entendues – et les consultants internes sont surpris. Parce que l'extérieur disait plus ou moins exactement la même chose que les internes auparavant. La transformation agile, l'accompagnement agile des projets, l'introduction du design thinking dans un département de développement produit n'est possible qu'avec nos clients.  

Les bons consultants ne sont pas seulement des guides, mais aussi des sherpas, ils montrent comment les bons tuteurs à domicile ou les entraîneurs personnels non seulement font le travail, mais soutiennent également la fabrication. Parce qu'il ne s'agit pas de savoir comment le faire, mais de le faire – et de transférer cette action dans les compétences de nos organisations clientes. 

Les conseillers - comme nous - ont souvent emprunté cette voie 

et connaître les pièges et les nids-de-poule possibles sur le chemin du changement. Christoph Schmiedinger et Carsten Rasche les ont compilés pour nos clients dans leur livre Agile Transformations off the Happy Path, et je montre moi-même dans Scrum Think BIG  ce que vous devez tous prendre en compte si vous voulez agiliser plus d'une petite équipe de projet.   

Pour plus d'informations sur ce que l'on peut attendre des implémentations agiles, je vous recommande les nombreuses études de cas et livres blancs  – disponibles gratuitement sur notre site Web. 

Clarification du mandat et définition des objectifs 

La question la plus importante que nous posons à nos clients au début est pourquoi ? À quoi sert le changement ? L'agilité n'est pas une fin en soi. En règle générale, les clients ont un besoin très particulier. 
 
Il peut s'agir : 

1. Les projets doivent être achevés plus rapidement et livrés dans le respect du budget – Par exemple, l'un de nos clients avait des délais de plus de 2 ans pour les projets informatiques. Nous avons pu réduire cela à quelques semaines. 

2. Les cycles de production doivent être plus courts. Par exemple, il y a eu un client qui a pu réduire son temps de production de l'idée à la vente à la caisse de 18 mois à 6 mois avec nous. 

3. La coopération des équipes entre elles mais aussi entre elles ne fonctionne pas de manière optimale. L'un de nos consultants a réussi à faire livrer une équipe querelleuse en quelques jours seulement. 

4. Les clients sont impliqués dans trop de projets en même temps et leur concentration est perdue. Grâce à une gestion de portefeuille agile, un grand équipementier automobile a réussi à augmenter sa rentabilité. Plus d'informations à ce sujet dans notre étude de cas. 

5. Les stratégies restent dans un tiroir, mais ne peuvent pas être mises en œuvre. Grâce à notre vision des OKR, la direction de l'organisation a pu clarifier les prochaines étapes et motiver les employés. 

Il serait trop long de compléter cette liste. Mais il devient clair qu'il s'agit toujours d'un problème commercial qui doit être résolu par le changement - c'est-à-dire une transformation. 

Cette clarification du mandat est complétée par la définition des objectifs. Comment mesurer finalement si nous avons atteint l'objectif avec le client ? Comment le client sait-il si la transformation a été réussie ? Il s'agit de faits concrets : nous voulons réduire le temps de traitement, avoir moins d'erreurs dans le système ou augmenter la satisfaction des employés. Pour en savoir plus, consultez notre étude de cas ! 

 
Inventaire 

Une fois que cela a été réduit, un inventaire est généralement effectué. Pour les projets plus importants, nous prenons 3 à 5 jours : Aujourd'hui, il arrive souvent que les concepts agiles soient déjà utilisés dans les entreprises. Souvent, il n'y a pas seulement une expérience initiale, mais même une expertise avérée. 

Il s'agit maintenant d'élaborer une image commune de l'endroit où les améliorations devraient avoir lieu. Par exemple, si l'on ne parle « que » d'une équipe dans laquelle le travail agile est en passe de devenir la norme, l'état des lieux peut également être réalisé au bout de 4 à 6 heures. Après l'atelier, tout le monde sait ce qu'il faut faire dans les 6 prochaines semaines pour que cette équipe travaille plus efficacement. 

Nous aimons travailler avec notre modèle des 6 dimensions du changement dans cette analyse. 
 
Nous distinguons si les mesures doivent contribuer à : 

1. Management de l'entreprise et du leadership, alias comportement de leadership : mot-clé leadership agile et développement de stratégie agile 

2. Gérer des projets, des processus de production ou organiser une équipe ou un service : les cadres de management agiles 

3. Comment transformer les idées de produits en produits : Comment le produit, le service, peut-il être construit de manière à ce qu'il soit au bénéfice du client ? 

4. Y a-t-il des sujets de savoir-faire : Mot-clé – où l'organisation du client a-t-elle besoin d'un nouveau savoir-faire dans la manière dont l'état de l'art est travaillé, qui peut également varier considérablement. Par exemple, il y a souvent un manque de connaissances sur la façon de travailler avec les outils de développement modernes. Le sujet actuel est l'IA et le DevOps. 

5. Le thème de l'infrastructure : avons-nous la bonne technologie ? Notre communication et notre infrastructure sont-elles capables de fournir rapidement et à moindre coût ? 

6. Comment notre organisation est-elle positionnée, dans quelle mesure notre structure organisationnelle répond-elle aux exigences des clients et quelles implications cela a-t-il pour nos clients.
‍ 

Actions : le backlog de transition 

Après cet inventaire, nous discutons avec nos clients des recommandations d'action qui en résultent et créons une sorte de feuille de route de changement, que nous appelons le backlog de transition. Nous convenons ensuite avec le client de laquelle de ces mesures doit être effectuée dans quel ordre. Seuls les clients peuvent déterminer ce chemin, eux seuls savent ce qui est concevable et gérable pour l'organisation avec le changement. 

Si les changements affectent plus d'une équipe ou d'un projet, une équipe dite de transformation est introduite pour ces projets de changement désormais plus importants et nous soutenons ensuite cette équipe dans les mesures. 

Mais il se peut aussi que la prochaine étape consiste à constituer exactement une équipe pilote, et c'est là que nous aidons l'équipe à mener à bien le projet. Ici, notre service consiste souvent soit à diriger nous-mêmes l'équipe de projet existante en fournissant le responsable du projet, soit à permettre au responsable du système client de mener ce projet à la réussite en utilisant des méthodes agiles. 

Vous trouverez de plus amples informations sur la manière dont un changement peut avoir lieu jusqu'à la transformation et sur les défis qui peuvent survenir dans le livre « Agile Transformation » de Christoph Schmiedinger et Carsten Rasche. 

Les clients nous demandent souvent : Qu'est-ce qui rend nos conseils spéciaux ? Pourquoi sommes-nous peut-être mieux adaptés à vous qu'à nos collègues d'autres cabinets de conseil ? Et comment savez-vous que nous ne sommes pas faits pour vous ? 

Tout d'abord, nous ne sommes pas un cabinet de conseil en management classique, et nous ne venons pas d'une gestion de projet classique. Nous ne sommes pas un cabinet de conseil en organisation classique ou des coachs systémiques.

Et pourtant, nous les conseillons sur l'élaboration et la mise en œuvre de nouvelles stratégies. Nous accompagnons vos projets en augmentant la fiabilité de vos livraisons et en améliorant la qualité délivrée. Nous pouvons modifier votre organisation pour mieux aligner vos processus sur les besoins des clients. Tout cela avec vous, c'est-à-dire que nous marchons sur le chemin avec vous au lieu de simplement vous dire ce que vous devez faire. C'est exactement là que réside notre force. Il ne suffit pas que nous trouvions le diagnostic et que nous délivrions l'ordonnance, nous sommes à vos côtés à chaque étape du processus.

Cela n'est possible que parce qu'en plus de solides connaissances théoriques, nous savons non seulement comment mettre en œuvre le changement, mais nous avons également formé les compétences en communication de nos consultants afin qu'ils puissent vous aider à mener à bien vos initiatives. Nous utilisons toutes nos connaissances pour aider les personnes dans les organisations à réussir avec les méthodes agiles.

Mais surtout, nous vivons le principe de « Mangez votre propre nourriture pour chien ». Nous utilisons nous-mêmes toutes les méthodes de management agiles, toutes les techniques de coaching et de communication pour maîtriser notre propre conseil. 

Nous ne sommes donc pas un cabinet de conseil en management qui vend un état d'esprit agile au monde extérieur, mais qui est hiérarchique en soi, ou qui a déjà conseillé une gestion de projet classique et qui saute ensuite dans le train agile.

Nous vivons ce que nous conseillons 

Contrairement à de nombreux autres cabinets de conseil en gestion, nous ne considérons pas le travail agile comme un complément, mais vivons les principes agiles comme une attitude essentielle. Nous ne vendons pas Scrum ou d'autres cadres de gestion agile comme méthode, mais nos consultants pensent, oui, nous vivons de manière agile dans notre propre organisation. Nous constituons nos équipes de manière diversifiée, nous utilisons nous-mêmes les OKR et Scrum . Nous effectuons des rétrospectives , travaillons nous-mêmes avec des tableaux de tâches et avons construit notre organisation aussi près de l'idéal organisationnel que nous avons pu le faire jusqu'à présent. Cela peut être encore mieux, c'est sûr.

Nous assumons la responsabilité du succès 

La deuxième différence cruciale : bien que nous voyions le monde de nos clients à travers des lunettes agiles, nous voulons l'utiliser pour résoudre les problèmes de nos clients. Nous nous engageons à assurer la réussite de nos clients. Nous ne sommes pas intéressés par l'introduction de Scrum, SAFe ou OKR pour vivre ces méthodes.

Avec ces cadres de gestion, nous voulons rendre la collaboration des employés plus efficace et donner à leurs managers des outils pour faire leur travail plus rapidement et plus efficacement. S'engager, notre engagement, ne signifie pas que nous atteignons les objectifs du client – nous avons également échoué, heureusement ce n'est que très rarement que nous ne réussissons pas à obtenir l'effet promis.

Nous avons construit notre organisation nous-mêmes de manière agile 

Et vous dire honnêtement notre opinion. Nos consultants décident eux-mêmes avec qui ils veulent travailler. Nous avons rendu nos finances transparentes pour tout le monde. Nous vivons la proximité et nous vivons d'égal à égal. C'est pourquoi même les consultants qui semblent très jeunes à première vue peuvent honnêtement dire à leurs clients après seulement quelques semaines qu'ils comprennent le fonctionnement du nouveau travail parce qu'ils l'ont vécu. Leurs compétences en matière de conseil ne sont pas lues, mais ils ressentent et comprennent à quel point les méthodes de travail agiles sont plus productives. 

Il existe d'autres cabinets de conseil qui, à première vue, fournissent également le ScrumMaster , mais nous constatons souvent que ces collègues n'ont malheureusement jamais expérimenté (en esprit) ce que signifie le vrai respect et ne défendent donc souvent pas leurs équipes. Dans leur détresse, ils restent du bon côté, car ils ne sont pas autorisés à dire honnêtement aux clients ce qui est nécessaire maintenant à cause de leurs patrons.   

À l'inverse, nous encourageons nos conseillers à le faire : nous mettons les faits sur la table, même au risque que nos clients nous donnent le feu vert. Heureusement, cela n'arrive pas souvent, même si nous sommes également épuisants pour nos clients. 

Parce que oui, nous faisons aussi des erreurs 

Qui n'ont rien à voir avec le fait de s'attaquer ouvertement aux dysfonctionnements. Nous avons un client merveilleux dont la culture interne nous était si étrangère que nous sommes tombés dans tous les faux pas imaginables au début. À leurs yeux, nous devions nous comporter comme l'éléphant proverbial dans un magasin de porcelaine. 

Nous étions en fait gênés et ce n'est que lorsque nous avons cherché une conversation ouverte et que nous avons réussi à aborder nos différences culturelles et à admettre ouvertement que nous avons avoué notre manque de compréhension – c'est exactement là que notre collaboration a commencé. Nous pourrions voir la diversité comme une source de changement. Le client le savait mieux que nous, car c'est exactement pourquoi il nous a choisis. Cette démarche a pris plusieurs mois – et nous ne pouvons que remercier le client de nous avoir supportés. 

Aussi difficile que ce chemin ait été et aussi reconnaissant que nous le soyons encore pour la compréhension du client, l'organisation du client n'aurait pas pu nous résister si nous n'avions pas fourni de valeur ajoutée dès le début. En même temps, malgré nos erreurs, nous avons reçu de merveilleux commentaires car nous avons pu soutenir les équipes du client dans leur travail de manière productive et professionnelle. 

Nous visualisons - constamment 

Tous ceux qui ont utilisé les services de conseil de borisgloger jusqu'à présent ont été étonnés au début que nous dessinions et peignions constamment des images. Cela fonctionnait très bien avant tout le travail à distance si vous aviez des tableaux de conférence dans la pièce. Aujourd'hui, nous devons recourir au croquis avec l'iPad. Oui, nous croyons fermement qu'il est essentiel de montrer les choses au lieu de les expliquer. 

Nous vivons le management visuel et montrons des faits avec des traits parfois pas si jolis que des cases simples et parfois avec de beaux graphismes. Non, nous n'avons pas les ressources nécessaires pour faire appel à un graphiste du jour au lendemain comme les grands cabinets de conseil en gestion. Nos consultants s'inspirent à la volée de ce qu'ils pensent afin de clarifier les faits ad hoc aux équipes et aux managers. 

Nous ne laissons pas nos consultants seuls 

Quiconque fait appel à l'un de nos consultants dans son entreprise reçoit la charge concentrée de borisgloger. Nous vivons selon un principe connu du mouvement open source : si quelqu'un ne sait pas quelque chose, il consulte toute l'entreprise et obtient généralement le soutien dont il a besoin en quelques minutes. Cela profite à nos clients, qui bénéficient ainsi de la créativité de beaucoup. 

Contenu et communauté 

En plus de tout ce qu'ils peuvent attendre de nos conseillers, nos clients bénéficient de notre volonté de les soutenir encore et encore avec différents contenus.
 
Nous proposons des webinaires à nos clients, nous rédigeons  des études de cas et des livres blancs , et nous amenons nos clients à échanger avec d'autres entreprises qui se sont lancées dans le voyage agile.   

Pouvons-nous faire mieux ? Sûr. Sommes-nous souvent une contrainte pour les organisations clientes avec notre dynamisme et notre motivation ? Oui! Mais nous sommes à l'écoute de nos clients et à vivre contre vents et marées avec eux. 

On nous demande souvent si les entreprises doivent former tous les employés aux méthodes agiles ? Notre réponse est toujours : oui, tout le monde. De préférence du conseil d'administration aux employés de service. Sécurité – les formations doivent être adaptées aux domaines de travail et aux postes respectifs de l'entreprise. Mais tout le monde devrait savoir ce que sont le travail agile, le nouveau travail et le management visuel.
 

La résistance est fonction de l'incapacité ? 

Nous sommes d'avis que la résistance à un nouveau comportement, à une nouvelle forme de travail, est presque toujours liée au fait que les gens ne savent pas à quoi s'attendre. Ils ne sont pas familiers avec la nouveauté. Ils ne savent pas ce qu'on attend d'eux et ils se sentent mal à l'aise parce qu'ils ne peuvent pas encore le mettre en œuvre eux-mêmes. Et ne nous leurrons pas : les entreprises ne sont pas des espaces protégés où vous pouvez simplement essayer quelque chose en tant qu'employé ou admettre que vous n'avez pas encore la confiance nécessaire pour mettre en œuvre le nouveau. 

Et de facto, la plupart des gens n'ont pas une connaissance approfondie du fonctionnement du travail agile. Nous avons presque tous été socialisés de manière classique, tout comme nos modèles. 

Presque personne n'a appris ce qu'est le management agile à l'école, à la maternelle ou en formation. Ce n'est que maintenant que des consultants travaillent avec quelques élèves du primaire et leur apprennent à apprendre de manière auto-organisée en tant qu'élève avec des tableaux de tâches. Voir Scrum4Schools.  

La plupart des gens dans les entreprises n'ont jamais entendu parler de Scrum et Kanban, SAFe et OKR. De plus, si l'un ou l'autre a déjà appris quelque chose à ce sujet de ses collègues et amis, il existe une grande variété d'idées – tout le monde comprend actuellement le New Work et la pensée agile différemment. Il ne vous reste plus qu'à faire une petite recherche sur Linked:in.  

À quoi doivent ressembler les formations pour tous les employés ? 

Comment puis-je m'y retrouver dans la jungle des offres de formation ? Est-ce que je fais une formation agile ou une certification Scrum Master ? Dois-je suivre une formation Product Owner ou SAFe ? Quelles formations pour managers ou équipes dois-je acheter pour mon entreprise ?  

La réponse n'est pas aussi simple aujourd'hui qu'il y a 20 ans, car il y a tellement de domaines d'application et de spécialisation différents. 

Tout d'abord, jetons un coup d'œil aux différentes questions que je veux résoudre avec une formation. 

1. Informations générales – Chaque employé doit savoir ce qu'est la gestion agile et quelles sont les différences. ‍ 
2. Une équipe ou un service souhaite travailler avec des méthodes agiles. 
3. Une équipe de projet doit travailler de manière agile. 
4. Un grand, très grand projet est censé fonctionner de manière agile. 
5. Les gestionnaires de l'organisation doivent comprendre ce que signifie la gestion agile et, si nécessaire, le leadership agile. 

Informations générales 

Il vaut la peine d'envoyer chaque employé à une formation agile info. Ces formats de formation sont généralement appelés Agile 101 ou Agile Intro Workshops. Ils durent souvent entre 3 heures et 6 heures. Ils fournissent des informations sur les rôles et le modèle de processus et montrent souvent des idées importantes telles que le tableau des tâches ou la rétrospective.  

Les formations ScrumMaster : une équipe veut travailler avec Scrum 

Ces formats étaient destinés aux personnes qui souhaitaient  introduire Scrum dans l'entreprise. Pour les chefs d'équipe et les chefs de projet qui  souhaitent désormais mener à bien leur projet avec Scrum . En deux jours, cette personne aura une image complète de ce que fait réellement Scrum et comment le mettre en œuvre. Comment résoudre des problèmes en équipe et comment comprendre  les formats et  les termes des réunions individuelles.Le but de cette formation est de pouvoir utiliser Scrum et de pouvoir l'expliquer à votre propre équipe. 

La même variante de la formation est disponible pour tous les cadres de gestion courants, c'est-à-dire OKR, Kanban, Design Thinking et Scrum. 

Il existe une variante de cette formation pour les propriétaires de produits, où il est expliqué en détail comment  fonctionne le rôle du propriétaire de produit , quels outils ils peuvent utiliser pour gérer les parties prenantes et comment, par exemple, ils développent une vision pour l'équipe. 

Quand toute une équipe de projet doit travailler avec Scrum 

La direction de cette équipe doit avoir une formation ScrumMaster et soit former l'équipe elle-même pendant un ou deux jours, soit acheter cette formation d'équipe auprès d'un prestataire de services. Après 1 à 2 jours, tous les membres de l'équipe doivent être en mesure de comprendre pourquoi ils devraient travailler de cette façon maintenant. Une bonne didactique aide, et cet investissement est également nécessaire – que le personnel soit externe ou interne est secondaire. 

Le grand, très grand projet est de travailler de manière agile 

Encore une fois, tous les managers et chefs d'équipe devraient avoir formé le cadre qu'ils utilisent là-bas. Qu'il s'agisse de MyScaled Agile, LeSS, SAFe ou d'un autre framework de mise à l'échelle. Les personnes qui ont exposé les rôles devraient toutes avoir la même compréhension.  

Dans ce cas, nous proposons la formation My Scaled Agile ou la formation SAFe correspondante.  

Ensuite, le reste de l'équipe de projet doit également être formé à l'ensemble du modèle pendant 1 à 2 jours. 

Les dirigeants de l'organisation, en particulier le conseil d'administration ou la direction, ont également besoin de formation 

Il existe une grande variété de formats ici : 

1. Cela commence souvent par une présentation et les managers ont un premier aperçu 
2. Il est plus efficace de confronter intensivement les managers aux techniques de leadership agile pendant 1 à 2 jours. Il peut s'agir d'une formation au leadership agile , d'  une formation Scrum Master ou d'un Product Owner . 
3. Mais ces formations doivent être perfectionnées par 2 formations supplémentaires : 

• La formation sous forme d'auto-organisation développée par nos soins nécessite une formation au leadership. En d'autres termes, l'examen intensif de moi-même et des nouvelles possibilités de leadership à partir d'une attitude agile. 
• Une formation qui prend le temps d'expliquer les éléments du lean management. Flux, limites de travail en cours et outils similaires. Cela est nécessaire car les managers doivent comprendre qu'il est entre leurs mains de savoir si leur organisation devient plus productive ou non. 

En plus de ces formations aux méthodes classiques, il est ensuite nécessaire d'acquérir des compétences en leadership, coaching d'équipe, facilitation et conduite du changement. 

Ici aussi, je recommande de faire appel à des prestataires issus de l'environnement de conseil agile. Les compétences de leadership agile et la gestion du changement agile, par exemple, sont différentes des approches traditionnelles en termes d'attitude de base. Ce n'est peut-être qu'une nuance parfois, mais en fin de compte, c'est décisif pour l'application et le succès. 

Si vous vous rendez à une conférence comme Agile 2025 aux États-Unis, Manage Agile à Berlin ou tout autre événement aujourd'hui pour savoir quels cabinets de conseil en gestion agile devraient l'aider à introduire des cadres de gestion agile tels que Scrum, Kanban, Design Thinking ou la mise à l'échelle agile avec SAFe, My Scaled Agile ou LeSS est presque submergé par le nombre de fournisseurs. Le marché devient encore plus déroutant car il existe également d'innombrables micro-entreprises avec peu d'employés, souvent même des entreprises unipersonnelles qui agissent avec des collègues de leur réseau.   

À ce stade, il ne nous est pas possible de donner un aperçu complet du marché dans l'espace germanophone, mais nous allons essayer de montrer les six entreprises les plus compétentes de notre point de vue et de les présenter brièvement. 

Vous ne trouverez pas sur cette liste les grands cabinets de conseil en gestion qui proposent également des cabinets de conseil en transformation agile. Cap Gemini, Accenture, PWC, Bearing Point et McKinsey, Bain, Boston Consulting Group - ils offrent tous des services de conseil dans ce domaine, bien sûr. 

1. L'équipe Scrum 

Commençons par une petite consultation très spécialisée. L'équipe Scrum. Fondée par Andreas Schliep et Peter Beck. Ce serait ma première recommandation lorsqu'il s'agit d'acheter des cours de formation pour devenir un ScrumMaster certifié, un Product Owner certifié ou les autres formations de certification  proposées par la Scrum Alliance . 

Ils font partie des  formateurs Scrum les plus expérimentés depuis le tout début. Vous êtes bien intégré dans le réseau de la scène agile et de la Scrum Alliance et connaissez de nombreux problèmes dans les entreprises. Leurs cours sont très modernes et leurs clients se trouvent en Allemagne et en Suisse. 

2. Wibas 

Le n ° 2 sur la liste serait Wibashttps://www.wibas.com/de. Wibas, fondée il y a un quart de siècle par Claudia Raak, Jörg Battenfeld et Malte Foegen, se considère comme un cabinet de conseil en gestion agile. Contrairement à la Scrum Team, elle n'est pas spécialisée dans Scrum, mais méthodiquement dans SAFe  – mais utilise cette formation pour proposer des transformations agiles. Il y a aussi un livre d'eux sur le sujet.   

Ils offrent également une très bonne formation Scrum, mais ces dernières années, ils se sont davantage spécialisés dans la mise à l'échelle des frameworks, en particulier SAFe. Ils proposent également les autres cadres de gestion agiles. Ils ont un emplacement merveilleux à Darmstadt où ils donnent leurs sessions de formation. Ses consultations autour de SAFe et des transformations agiles sont certainement parmi les meilleures que le marché allemand a à offrir. 

3. Agilité informatique 

Si vous recherchez une formation agile sur Scrum, Kanban ou SAFe dans le nord de l'Allemagne, vous ne pouvez pas  passer à côté d'IT Agile de Hambourg . Ils ne sont qu'à la troisième place car leur offre est devenue confuse à mon goût. 

Si vous voulez en savoir plus sur UNFIX ou sur votre propre offre de leadership agile, vous le trouverez tout autant que quelqu'un qui trouve la certification de la Scrum Alliance ou de la Scrum.org . Mais c'est leur force - parce qu'ils sont sur le marché agile depuis plus de 2 décennies, ils font partie des consultants les plus expérimentés lorsqu'il s'agit de conseiller les équipes et les organisations en matière de gestion et d'état d'esprit agiles.  
 

4. Kegon AG 

Kegon AG à Wiesbaden a été l'un des premiers bureaux de conseil en Allemagne à se spécialiser dans le Scaled Agile Framework. Ils offrent des formations et des conseils autour du cadre SAFe. Si vous souhaitez en savoir plus sur cette variante de la mise à l'échelle des processus métier, vous êtes certainement bien avisé de vous arrêter chez KEGON. KEGON a un très grand réseau, car ils se considéraient comme une organisation en réseau depuis le début. 

5. Improuve 

Un autre cabinet de conseil en gestion agile depuis le tout début est Improuve à Munich. En plus des formations Scrum certifiées telles que Certified ScrumMaster, ils proposent également les formations Scrum professionnelles de la Scrum.org et la formation au niveau du vol de la Flight Level Academy ainsi que des formations Kanban et SAFe. Ils se considèrent comme des consultants d'égal à égal et font certainement partie des cabinets de conseil en gestion les plus discrets du marché, mais vous pouvez les rencontrer lors de nombreuses conférences. 

6. Héros agiles 

Le dernier mais non le moindre sur cette liste sont les héros agiles de Francfort. Ils ont de loin le meilleur site Web et la meilleure présence sur les médias sociaux. Leurs points forts sont les formations professionnelles Scrum de l'Scrum.org, mais aussi le prince agile ou encore Scrum en formation. 

Mais leur objectif absolu est la formation en ligne, qu'ils proposent de manière beaucoup plus agressive que celles mentionnées ci-dessus – qui ont toutes également des offres en ligne. Leur deuxième pilier est le conseil, des transformations agiles au conseil en stratégie agile, vous pouvez également obtenir l'ensemble du portefeuille auprès d'eux.   

À suivre 

Cette liste ne peut pas vous décharger du travail de trouver la bonne entreprise pour vous. Et comme je l'ai dit, c'est loin d'être complet. Pour rendre les choses passionnantes... Cette liste continue.  Dans un autre article, nous présenterons brièvement les pionniers des RH et d'autres comme les Emendare. Faites-nous savoir qui doit absolument être mentionné. 

Pour répondre à cette question, je dois aller un peu plus loin. Ma première tentative d'écrire un livre sur la mise à l'échelle de Scrum a été un désastre. Je me suis inscrit dans un blocage de l'écrivain. Cela n'a pas fonctionné ! Pendant des mois, j'ai essayé différentes approches du sujet, j'ai écrit des grandes lignes, j'ai écrit mes premières lignes et je suis resté bloqué. Puis je m'en suis souvenu à nouveau. C'était presque comme si un film jouait en moi : Recife, 2008.  Une grande salle. Une conférence sur le développement de logiciels. Jan Bosch prend la parole sur scène. Une star de la scène de l'architecture logicielle. Sa thèse : Les grands projets ne passent pas par le processus, mais seulement par l'architecture. Toute tentative de garder un grand projet sous contrôle à l'aide de processus doit échouer en fin de compte parce que l'effort de coordination devient trop important, a-t-il poursuivi. Cela correspondait à mon expérience. À ce moment-là, j'étais déjà passé plusieurs fois à Scrum pour de grands projets de développement avec 60, 180 et 250 personnes. Oui, c'était possible, mais c'était tellement épuisant. Il y avait beaucoup de réunions de coordination et les tableaux de tâches devenaient de plus en plus longs, le plus long mesurait 7 mètres de long.

Et Bosch ne nous a expliqué que ce qui se passait dans la Silicon Valley chez Amazon et Intuit à Sacheng. C'est à cette époque que l'idée d'architecture de microservices a non seulement été inventée, mais mise en œuvre. Son approche promettait la solution, car je l'avais moi-même expérimentée – il était possible d'avoir 180 développeurs travaillant sur un projet en même temps et de gérer les nombreuses dépendances à l'aide de Taskboard. La planification des sprints pouvait également être conçue de manière à ce que les 180 développeurs sachent réellement ce qu'ils voulaient développer à la fin de la journée. J'ai eu l'idée de Bas Voode, prendre une grande pièce et y mettre les 180 personnes, mise en œuvre et rendue exécutable (aujourd'hui, cela s'appelle Big Room Planning). Mais c'était tellement fastidieux, bruyant et chaotique. Mais à long terme, ce n'était pas une solution. Cela a coûté une somme d'argent folle. 180 développeurs à un tarif journalier de 800 euros... Je disais toujours : « Et une autre Porsche 911 vient d'être brûlée. » Il faut d'abord pouvoir se permettre ces frais généraux gigantesques et beaucoup trop chers.

Je suis toujours du même avis : les clients engagent nos consultants pour organiser ces grandes réunions, mais ce n'est pas efficace. Nous pouvons rendre la réunion dans une grande salle efficace, mais cette approche est fondamentalement mauvaise. 

Pourquoi? Il y a deux raisons à cela : 

1. La première est l'idée, qui est toujours répandue par l'ancienne image de Ken Schwaber avec le backlog à gauche, les deux cercles au milieu et l'incrément de produit à droite. L'idée que les équipes de développement travaillent sur les exigences d'un propriétaire de produit ou du client.  Les grandes organisations de développement qui font du développement sous contrat utilisent SAFe parce qu'elles se sont mises en place de cette manière – pour servir exactement cette idée. Les trains de libération sont discutés lors de ces réunions – afin qu'ils puissent ensuite être mis en service. Ici, la critique justifiée de la communauté Lean selon laquelle Scrum et SAFe fonctionnent par lots au lieu de livrer dans un flux continu est complètement ignorée. Si vous planifiez 3 mois à l'avance, vous n'êtes plus en mesure de réagir ad hoc aux besoins des clients.   
2. La deuxième erreur est de ne pas développer l'architecture du produit de manière à ce que les équipes puissent livrer End2End. 

Mais je me perds dans les détails. Le changement d'architecture était donc la solution au problème de mise à l'échelle. Chaque équipe est responsable d'un ou plusieurs services. Cependant, un service appartient toujours à une seule équipe. Cela a conduit à la création d'une organisation d'équipes indépendantes et les premières images ont ensuite été expliquées par Spotify et le modèle Spotify a été créé. 

En même temps, un autre problème doit être résolu. Si différents services doivent interagir ensemble, qui sont tous coupés d'eux-mêmes, mais se connaissent, alors ces services doivent communiquer entre eux. Une infrastructure est nécessaire pour permettre cette communication. Nos ordinateurs portables ont tous un système d'exploitation qui fait abstraction de l'infrastructure matérielle (boîtier, écran, clavier, alimentation, puces) de manière à ce que les applications et les services puissent fonctionner dessus. Le système mis à l'échelle de dizaines de milliers de services (Word, Excel, Safari, PowerPoint lui-même se compose de 1000 services) fonctionne parce que des unités indépendantes sont activées par le système d'exploitation pour communiquer entre elles.  L'architecture n'était donc qu'une condition, le deuxième prérequis était également nécessaire, un nouveau type d'infrastructure. Appliqué au développement de produits, cela signifie que nous ne devons pas seulement penser en termes de microservices pour les grands projets, nous avons également besoin des outils et des processus – le système d'exploitation, sous forme d'infrastructure, pour que les équipes puissent livrer ensemble.   

Idéalement, la plupart des étapes du processus sont également automatisées par le système d'exploitation. Ici, le déploiement continu et les tests automatisés ne sont initialement que le ticket. Beaucoup plus peut être automatisé si vous le connaissez. (D'ailleurs, il s'agit bien sûr du premier cas d'utilisation décisif de GEN-AI ; chaque travailleur du savoir est en mesure d'automatiser son travail au moins en partie.   

Quiconque accepte ces faits ci-dessus et change ainsi ses prémisses ne peut plus croire que les modèles de mise à l'échelle sont la solution aux problèmes des grands projets. Qu'il s'agisse de Nexus, SAFe, LeSS ou des autres frameworks de mise à l'échelle, ils 1. avaient toujours le mauvais scénario de départ et 2. mal évalué le fait que la mise à l'échelle via des processus est beaucoup trop coûteuse.   

La troisième étape était alors une conséquence d'une observation. La plupart des organisations n'ont pas pu échouer avec l'idée d'architecture émergente, de microservices, de développement piloté par les tests ou d'automatisation, ni parce que les outils collaboratifs tels que Miro ou MS Teams ne sont pas utilisés à leur pleine mesure – il y a un manque de compétences. Il ne sert à rien de savoir ce qui précède si l'organisation, c'est-à-dire les personnes dans les organisations, ne peut pas le penser parce qu'elles n'ont pas les compétences. 

Ainsi, un modèle qui veut expliquer comment construire un très gros produit devait prendre en compte le facteur compétence. D'ailleurs, ce fait n'est pas non plus abordé dans les cadres bien connus tels que SAFe – et je ne parle pas des compétences agiles. Il s'agit de la capacité à faire son travail différemment que dans un contexte classique. L'exemple de l'automatisation ou de l'IA aujourd'hui montre à lui seul ce que cela signifie ici. 

Pour ne pas faire exploser cet article ici : Il y avait trois autres aspects : 

1. Si vous voulez inventer un produit, vous devez le faire de manière centrée sur l'utilisateur avec des méthodes agiles, c'est-à-dire utiliser le Design Thinking comme méthode de développement de produit agile, 
2. a besoin d'un cadre de management agile pour diriger les équipes et les organisations Scrum 3.0 et les OKR et il 
3. a besoin d'une compréhension agile du leadership afin de mettre en œuvre une culture du succès. (Si vous voulez comprendre ces 6 étapes plus en détail, faites-moi savoir mon Livre Scrum Think B ! G, notre cadre agile MyScaled et notre évaluation 6D.)   

Nous avons présenté ces 6 niveaux ici. 

Voilà pour la genèse des considérations sur la raison pour laquelle la mise à l'échelle elle-même est quelque chose de complètement différent de ce qui est expliqué dans les cadres de mise à l'échelle. Ce n'est que lorsque tous ces facteurs sont pris en compte ensemble qu'une organisation peut réellement fournir une approche agile, c'est-à-dire centrée sur l'utilisateur et très efficace. Tout le reste conduit à la bureaucratie et à des coûts gigantesques. 

Si vous voulez absolument faire du SAFe, vous devez avoir une grande organisation et être capable de dépenser beaucoup d'argent. L'effort nécessaire pour gérer uniquement SAFe, car tout est question de processus, est très élevé – et vous devez également payer une licence pour l'utiliser si vous voulez l'utiliser. Absurde – après tout, dans mon livre Scrum Think B ! G a décrit comment la mise à l'échelle est gérée de manière processuelle. 

Mais il ne s'agit pas de dénigrer SAFe, mais de montrer qu'il existe un autre moyen. Nous avons nous-mêmes réfléchi à la manière dont nous pouvons soutenir les organisations lorsqu'elles ne sont pas encore idéalement positionnées. S'ils n'ont pas encore d'équipes capables de fournir End2End, si l'architecture ne convient pas encore, s'il n'y a pas encore assez d'automatisation et si l'utilisateur n'est pas suffisamment consulté, notre solution pour nos clients est l'approche MyScaled Agile.   

Sur la base des six points ci-dessus et de l'évaluation 6D correspondante  , nous développons un parcours de mise en œuvre stratégique avec nos clients. Oui, nous avons également notre plan directeur à l'esprit, mais cela peut être réduit à quatre principes :  

1. Rendre possible la prise en charge de Teams End2End – Couplage lâche de Teams et de Microservices ! 
2. Automatisez autant que possible – par exemple, les automatisations DevOps ! 
3. Pensez toujours du point de vue du client – l'orientation utilisateur ! 
4. Mettez en place l'organisation en tant que réseau et façonnez le leadership en conséquence ! 

 
Pour y parvenir, il arrive souvent que les organisations aient besoin d'étapes intermédiaires et doivent d'abord entrer dans l'un ou l'autre précurseur d'une structure de type réseau. C'est très bien, tant qu'il est possible d'aligner systématiquement l'organisation sur le client et de la maintenir ainsi en forme pour l'avenir. Si vous voulez en savoir plus à ce sujet, jetez un coup d'œil ici : Mise à l'échelle agile 

Alors, faisons-nous SAFe ? – Nous ne recommanderions pas la mise en œuvre de SAFe nous-mêmes, mais si les clients ont besoin de notre expertise dans leur projet SAFe pour mettre en œuvre SAFe, nous ne les laissons pas tranquilles. L'espoir demeure qu'avec notre expertise dans le contexte SAFe, nous serons finalement en mesure de rendre les principes sous-jacents à l'agilité utilisables pour nos clients. 

‍