Pourquoi l’Agilité échoue dans les grandes entreprises

Posted on Author Gaëtan Komguem

Le développement logiciel agile s’est avéré être un avantage majeur pour différentes équipes, mais il peut affecter différemment les entreprises en fonction de leur taille et de la façon dont elles intègrent la méthodologie dans leurs opérations. Bien que l’agilité puisse apporter des avantages significatifs, le voyage n’est pas toujours facile. En fait, dans un sondage réalisé par le Dr. Dobb’s Journal, 68,6% étaient impliqués dans un projet dont ils savaient qu’il échouerait dès le départ. Cependant, les projets agiles ont enregistré un taux de réussite de 71,5%, contre seulement 62,8% des méthodes traditionnelles. Il est important de comprendre la cause profonde de ces problèmes afin de mieux préparer votre propre organisation aux projets agiles. Dans cet article, nous explorons quelques domaines communs qui ont un impact sur l’adoption du processus de développement agile dans les grandes entreprises 

 

1. Manque de clarté 

Les grandes entreprises comprennent souvent de grandes équipes composées de membres distants. Dans le cadre de stratégies agiles, il est important que toutes les personnes impliquées dans le projet collaborent, donc si les travailleurs distants ne peuvent pas communiquer facilement, il sera difficile de contribuer. Dans une interview accordée à StickyMinds, le PDG de Leading Agile, Mike Cottmeyer, a noté que l’un des défis les plus courants consistait à former des équipes de projet agiles et interfonctionnelles et à s’assurer que ces groupes sont en mesure d’éliminer l’arriéré. 

«À grande échelle dans les grandes organisations, il est incroyablement difficile de trouver un modèle qui permet aux équipes de se réunir et de rester ensemble et d’être tenus responsables et d’établir une vitesse stable et tout ce genre de choses», a écrit Cottmeyer. « Nous recherchons des endroits pour aligner les processus métier, la technologie et les équipes dans ces unités qui peuvent finalement devenir des équipes agiles et devenir plus lâchement couplées au reste de l’organisation. » 

Les équipes peuvent être rassemblées grâce à la clarté du partage de l’information. Quels que soient les outils choisis, ils doivent renforcer cet atout important. Ces types de ressources permettront de mieux soutenir les efforts de développement agiles. Il est également important de sélectionner un outil de gestion de projet Agile qui clarifie l’ensemble de l’équipe (surtout lorsqu’il s’agit d’une équipe distribuée) et les responsables qui ont besoin d’informations sur les progrès. Bien sûr, c’est un plus si cet outil peut être intégré à l’outil de gestion de test agile. 

 

2. Recours continu aux méthodes héritées 

Lorsque vous passez à l’agilité, il faut un changement important dans la culture. Cependant, certaines équipes utilisent encore la cascade et d’autres stratégies héritées pour certaines opérations, ce qui peut entraîner une défaillance agile. Selon le neuvième sondage annuel de StateOne sur l’état de l’agilité, 42% des participants ont indiqué que leur culture d’entreprise était en contradiction avec les valeurs agiles de base et que 37% se sentaient obligés de suivre les processus traditionnels. Pour aggraver les choses, les participants ont mentionné le manque de soutien de la part de la direction et le manque de volonté de l’équipe à suivre l’agilité comme raisons de l’échec de leurs projets agiles. Puisque l’agilité entraîne des changements considérables, comme des cycles de libération plus rapides et un développement continu, disposer de ressources et de soutien est essentiel à son succès. Cependant, comme l’a révélé l’enquête, 44% des répondants ont cité cette capacité à changer la culture organisationnelle comme le plus grand obstacle à une adoption agile plus poussée, tandis que 32% croyaient que les cadres rigides / cascade préexistants étaient à blâmer. «Nous savons que l’agilité est d’abord« comment vous pensez »et ensuite« ce que vous faites », a écrit Agile Alliance en réponse à l’enquête VersionOne. «Si la culture de votre organisation est ignorante ou totalement hostile aux principes et aux valeurs agiles, les perspectives de réussite au-delà des poches isolées d’équipes agiles sont minces. Comment comprendre que l’agilité impacte les valeurs organisationnelles et facilite cette transformation est la première étape d’agilité, et plus de succès avec agile comme un moyen de livraison réussie.  » 

 

3. Expérience inadéquate avec agile  

Peut-être la principale raison pour laquelle les projets agiles échouent dans les grandes entreprises est le fait que les gens n’ont tout simplement pas d’expérience avec la méthodologie ou comment l’intégrer. En fait, selon l’enquête VersionOne, il s’agissait de la principale cause d’échec du projet agile, cité par 44% des participants. Pour cette raison, les organisations devraient créer un plan de match et fournir de l’expérience grâce à des programmes pilotes et à du coaching. Dans son interview, Cottmeyer a noté que les entreprises essaient souvent de prendre de petits projets dans un contexte plus large ou de transformer de grands projets en initiatives agiles. Cependant, sans les connaissances adéquates, les chances d’échec dans ces cas sont beaucoup plus élevés. C’est un point vraiment important qui est souvent sous-estimé dans de nombreuses transformations Agiles. Comment les rôles changent-ils dans cette nouvelle approche de développement de logiciel? Qu’est-ce que cela signifie de travailler en itérations? En formant les nombreux rôles qui entrent dans la formation des équipes interfonctionnelles, ils seront plus à même de tirer parti des méthodologies de test agiles et de s’assurer que leurs projets réussissent dans le cadre de la nouvelle approche. Les gestionnaires devraient également être inclus dans la formation parce que leurs rôles et responsabilités changeront radicalement en utilisant Agile. Ils doivent comprendre comment fonctionne l’auto-organisation et comment créer un environnement où l’auto-organisation peut prospérer. Ils doivent également comprendre les nouvelles mesures qu’ils devraient envisager et comment les obtenir. 

 

4. Manque de collaboration dans les équipes composées par différentes entreprises  

Un autre problème, lié au premier problème décrit, est le manque de collaboration au sein des équipes composées de membres représentant différentes organisations sous-traitées. Dans ce contexte, l’équipe n’est pas vraiment une équipe partageant les mêmes objectifs et le même plan. Il n’y a pas un seul jeu coopératif mais de nombreux jeux et les différents jeux ont des objectifs différents. Les membres de l’équipe doivent répondre aux objectifs du projet ainsi qu’à ceux mis de l’avant par leur propre organisation. Cependant, ce dernier peut ne pas être aligné avec les objectifs d’autres sous-traitants travaillant sur le même projet. Pour aggraver les choses, dans de nombreuses occasions, une entreprise est sous-traitée pour remplir tous les postes dans un domaine d’expertise (par exemple en sous-traitant une entreprise pour faire le test). Comme nous le savons tous, la qualité est la responsabilité de toute l’équipe, mais lorsqu’il y a des désaccords, c’est entre les domaines d’expertise et les entreprises. Bien sûr, ce n’est pas un problème d’Agile en soi, mais dans les environnements Agiles où de courtes itérations pendant lesquelles tous les membres doivent interagir et collaborer activement peuvent devenir un problème majeur. Dans ce contexte, constituer une équipe partageant les mêmes objectifs et où les membres collaborent réellement est un d éfi majeur, et nous savons qu’une collaboration efficace est importante pour la réussite du projet. 

 

5. Absence de stratégie de test  

L’un des domaines les plus mal compris dans les transformations Agile est la façon dont les tests sont effectués. Le rôle du testeur change et les compétences requises pour remplir ce rôle changent également. Les tests doivent être effectués itérativement sur des fonctionnalités qui, en les regardant avec un esprit ancien, ne sont pas complètement terminées. De plus, des tests de régression sont nécessaires pour s’assurer que les fonctionnalités déjà construites continuent de fonctionner. Il est clair que cela implique des changements profonds pour les équipes d’assurance qualité. Ne pas comprendre cela est une cause majeure de déception dans de nombreuses tentatives de transformation agile. Comme indiqué précédemment, une formation adéquate pour le personnel d’assurance qualité et la sélection d’un bon outil de gestion des tests agile est d’une importance capitale.  

 

6. Manque d’alignement dans d’autres domaines de l’entreprise  

Il est très commun dans les grandes entreprises que, tandis que certaines zones fonctionnent avec des méthodologies Agile, d’autres ne le font pas. Le problème se pose lorsque ces zones doivent interagir. Lorsqu’une équipe Agile a besoin de quelque chose d’un autre groupe au cours d’une itération, et que cet autre groupe fonctionne différemment, a un horaire différent et ne comprend pas qu’en ne fournissant pas ce qui est nécessaire, l’équipe Agile ne sera pas en mesure de compléter le travail pour lequel il s’est engagé, il y a un problème. C’est une erreur courante dans les grandes entreprises de penser que cette interaction sera possible et fonctionnera sans heurt. Dans de nombreuses occasions, ce n’est pas le cas. Modifier la structure des équipes devrait être l’objectif à long terme. Comme le dit Mike Cottmeyer sur le front mentionné dans le document « True Agility est sur le point de briser les dépendances à travers l’ensemble de l’organisation ». Dans l’intervalle, viser à aligner les unités opérationnelles et veiller à ce que les gestionnaires des domaines qui ne travaillent pas avec Agile comprennent les implications de l’interaction avec des équipes qui fonctionnent de la nouvelle façon. 

 

7. Des équipes plus grandes et de grandes structures pyramidales 

Il est clair que les équipes doivent être à peu près de la même taille, quelle que soit la taille de l’entreprise, le nombre idéal étant de sept membres de l’équipe. Cependant, il arrive souvent que le nombre d’équipes travaillant ensemble soit supérieur à ce qui est réellement nécessaire pour le projet. Cela peut se produire à cause de la restructuration des équipes, parce que les structures pyramidales tendent à entraîner la création d’équipes plus importantes, à cause de la culture ou simplement parce que les grandes entreprises ont beaucoup d’employés. Le problème s’aggrave encore lorsque les membres de l’équipe sont partiellement affectés au projet car l’engagement n’est pas le même. Ajouté à cela, il y a le problème des cadres intermédiaires qui participent au projet d’un point de vue encore plus externe. Le prix à payer pour les équipes surchargées est d’avoir plus de complexité, de plus grandes réunions et une productivité réduite. Une autre situation à laquelle les équipes des grandes entreprises doivent faire face est d’avoir de nombreux patrons dans l’équipe. Alors que Scrum encourage l’équipe à s’auto-organiser et que chaque membre de l’équipe soit courageux et décide de la meilleure tâche avec laquelle collaborer, avoir un boss au sein de l’équipe (par exemple son chef de technologie ou architecte) la décourage. Les équipes innovantes ont des structures plates et le plus souvent, ce n’est pas le cas dans les grandes entreprises. Beaucoup de grandes entreprises, dont la plus importante est Amazon, sont organisées en équipes autonomes ne dépassant pas 10 membres. Amazon a appelé cette règle « l’équipe de deux pizzas » car l’équipe idéale devrait être assez petite pour que ses membres puissent être nourris avec deux pizzas.  

 

8. Ne pas changer les objectifs 

Un des points que Jim Highsmith fait dans son livre Agile Project Management est «Si le changement, l’adaptation et la flexibilité sont les marques de fabrique de projets agiles et conformes aux plans est la marque de fabrique des projets traditionnels, pourquoi mesurons-nous encore le succès des projets agiles? les cadres traditionnels?  » La modification radicale de l’approche de développement devrait englober la modification des objectifs de gestion de la performance de l’organisation s’ils ne sont pas alignés. Dans le cas contraire, l’équipe de développement travaillerait contre un ensemble d’objectifs tandis que l’équipe de gestion contre un autre. En outre, considérez l’impact des mesures de performance individuelles sur le travail d’équipe pour mesurer l’équipe sur les résultats globaux, et non sur l’activité individuelle. 

Conclusion 

Les grandes entreprises traitent souvent de problèmes plus grands et plus complexes que les petites. Ils ont plus d’employés, des entreprises sous-traitantes, des unités d’affaires différentes, plus de processus et une culture forte qui définit comment les choses sont faites. Dans le même temps, ils doivent être en mesure de fournir des résultats dans un environnement commercial en constante évolution. Ils doivent être agiles. Les grandes entreprises qui font une transformation agile devraient apprendre des nombreuses autres entreprises qui ont déjà suivi cette voie. Agile peut prendre du temps pour bien faire les choses, mais en comprenant les défis auxquels les autres organisations sont confrontées, ils peuvent prendre ces leçons en compte pour leurs propres stratégies. Cela aidera les entreprises à mieux planifier leur transition vers des opérations agiles et à augmenter leurs chances de succès. 

Kanbanisez vos projets

Posted on Author Gaëtan Komguem

Votre entreprise est un écosystème de services interdépendants avec un système adaptatif complexe. 

 

Un tas de compagnies ont commencé leur voyage d’augmenter leur agilité avec Scrum. Cela n’a pas résolu tous leurs problèmes. Le Kanban permet aux organisations de faire évoluer leurs systèmes de prestation de services vers une agilité commerciale mature. 

Comme indiqué dans How Kanban Saved Agile, le Scrum pur est extrêmement rare. Scrumbut (étiquette dénigrante qui a été engendrée par de nombreuses organisations rapportant qu’ils font du Scrum, sans pour autant respecter les normes …) d’autre part, est extrêmement commun.

Pour ne pas être qualifié de Scrumbut, votre entreprise a besoin de :

+ Equipe de développement interfonctionnel de 7 +/- 2 personnes – TOUTES les compétences requises pour livrer des projets sont présentes dans l’équipe – il n’y a pas de dépendance externe à l’équipe;  

+ Une source de demande sans contraintes de capacité: le Product Owner est le client ET membre à temps plein de l’équipe;

+ Les sprints durent un mois ou moins, commencent par le démarrage d’une nouvelle demande du propriétaire du produit et se terminent par la livraison d’augmentations de produit potentiellement livrables, suivies d’une rétrospective sur la façon de faire le meilleur sprint suivant;

+ «Potentiellement livrable» signifie que la décision de savoir si la livraison  est réellement une décision des affaires. Tout le travail technique est fait;  

+ Si tout le travail technique requis pour livrer n’est pas fait, alors le Sprint est un Sprint échoué;

+ Le Scrum Master est un leader serviteur et un éducateur Scrum pour toute l’organisation. 
 

Combien d’organisations connaissez-vous avec les équipes Scrum qui répondent à toutes les exigences ci-dessus? Je n’en connais pas. 
 
Alors, quelle est la solution? Abandonner le Scrum? Sommes-nous toujours en train d’obtenir des avantages du Scrumbut? Reconnaissons ce qui se passe vraiment avec de vraies équipes dans le monde réel et appelons cela Scrum. Reportons-nous à la check-list ci-dessus comme « Scrum idéal ». 

 
Voici quelques raisons expliquant pourquoi ajouter des couches de dimensionnement Agile autour des équipes :

+ Les équipes ne sont pas entièrement inter fonctionnelles;
 
+ Les équipes ont des dépendances externes et opaques;  

+ Un grand nombre de ces dépendances sont des services partagés avec de multiples sources de demande et des capacités limitées – souvent surchargées;  

+ Les dépendances externes peuvent être d’autres équipes-la demande des autres équipes apparaît dans leur carnet de commandes, priorisé par leurs propres propriétaires de produits;

+ De nombreuses dépendances ne jouent pas du tout les mêmes règles: certaines résident dans une autre partie de l’organisation, avec des structures et des forces politiques différentes;  

+ Les Product owner représentent un éventail de multiples sources de demande, avec des attentes de niveau de service, des origines stratégiques, un degré de clarté, une urgence et des forces politiques différents qui les poussent vers l’organisation de livraison;  

+ Les backlogs produits sont principalement constitués de solutions définies par les parties prenantes et traduites par les pseudo-Product Owner en pseudo-user stories – comment ils y arrivent est opaque, le «floue front end» – et quelque part ici un engagement de livraison floue était déjà fabriqué;  

+ Le travail d’un sprint comprend tout le travail que peuvent accomplir les équipes non inter fonctionnelles – alors que toutes les équipes sont «exécutées», elles sont livrées à un groupe d’équipes ou à des étapes de processus assez bien défini au niveau organisationnel mais en dehors de l’influence des équipes);  

+ Les décisions de livraison sont prises en fonction des contraintes imposées par la technologie, les systèmes et leurs porteurs (pour des raisons historiquement bonnes);  

+ Les équipes sont «faites» à la fin de chaque Sprint, mais beaucoup de travail reste à faire avant que leur travail «fait» soit potentiellement livrable;  

+ Les Scrum Master sont tenus collectivement responsables des livrables collectifs des équipes et de leur capacité à coordonner et à intégrer l’équipe – la responsabilisation par le comité se traduit par le fait que personne n’est réellement responsable. Les cadres intermédiaires se démènent pour ramasser les pièces parce qu’ils sont réellement responsables des résultats livrés. 

De manière générale, les méthodes de dimensionnement Agile visent à appliquer des enveloppes Agiles plus grandes autour de grappes d’équipes Agiles afin de rétablir une certaine structure hiérarchique nécessaire pour gérer les interdépendances décrites ci-dessus. Qu’il s’agisse d’un train de lancement ou d’un Nexus, ou autre chose, l’idée est qu’il existe une «équipe d’équipes agile» qui gère les interdépendances de plusieurs équipes plus petites. Tant que le nombre total de personnes ne dépasse pas le nombre de Dunbar (~ 150), le groupe de Dunbar est dédié et inter fonctionnel, il y a une équipe gérant les interdépendances dans le groupe de Dunbar, il n’y a pas de dépendances en dehors du groupe et il y a une certaine cadence (1-3 mois) de livraison intégrée – c’est toujours « Agile ». Tout cela jusqu’à ce qu’un groupe Dunbar (et seulement jusqu’à présent) permette à l’entreprise de rester «Agile» – Agile dimensionné. Tout cela est censé être plus réaliste que le Scrum idéal (avec peut-être une superposition de Scrum de Scrums et Scrum de Scrum de Scrums). Ça ne l’est pas. Combien d’organisations connaissez-vous qui peuvent se permettre d’avoir ~ 150 personnes 100% dédiées à un seul produit?  

Comment le Kanban règle-t-il ce problème? Votre entreprise est un système adaptatif complexe. Vous y introduisez un système Kanban tel qu’il est probable que le système adaptatif complexe soit stimulé pour s’améliorer. L’approche de la pensée systémique pour introduire le Kanban est pourrait avoir du succès: 

  1. Comprenez le but du système – identifiez explicitement les services que vous fournissez, à qui vous les fournissez et pourquoi; 
  2. Comprendre les choses au sujet de la prestation de service dont les gens ne sont pas satisfaits aujourd’hui – à la fois ceux dont les besoins sont traités par le service et ceux qui font le travail de prestation de service; 
  3. Définir les sources de la demande – ce dont vos clients se soucient et pourquoi; 
  4. Décrivez la capacité de votre système à satisfaire ces exigences; 
  5. Cartographier le flux de travail des éléments de valeur reconnaissable par le client, en commençant par un besoin connu du client et en terminant par le besoin de franchir les étapes de la découverte des connaissances primaires (équipes Scrum quelque part au milieu, vers la fin) , ne pas boucler les flux de valeurs; 
  6. Découvrez les classes de service – il existe des schémas sur la façon dont les différents types de travail circulent dans votre système (ils ne sont pas arbitrairement décidés par les pseudo-Product Owners), quels sont-ils? Regroupez-les, ce sont des classes de services et leur connaissance permet une gestion des risques puissante; 
  7. Avec tout ce qui précède en tant qu’entrée, concevez le système Kanban pour le service; 
  8. Apprenez à faire les étapes 2 à 7 et commencez à l’appliquer directement à votre propre contexte dans une classe Kanban System Design; 
  9. Socialiser et déployer (apprendre en participant à une masterclass de coaching professionnel Kanban); 

    10. < li>Mettre en place des cadences de rétroaction en boucle pour une évolution continue: apprenez les 7 cadences kanban et commencez à appliquer à votre propre contexte dans une classe de professionnels de la gestion Kanban; 

  10. Répétez l’opération avec tous les services interdépendants de votre organisation.  

Certains outils informatiques existent pour matérialiser les tableaux de Kanban. C’est le cas par exemple de JIRA un produit Atlassian. 

Pour savoir comment kanbaniser son projet avec JIRA vous pouvez consulter l’article suivant … 

 

Pour les Agilistes qui ont lu jusqu’ici et ne comprennent toujours pas, vous pouvez lire: 
 
14 choses que tout agiliste devrait savoir sur Kanban de Travis Birch : 

 

  1. La méthode Kanban ne concerne pas la transformation. Du moins pas la marque radicale et profonde de transformation Satir J-Curve qui a été tentée dans de nombreuses organisations. Trop souvent avec l’approche radicale, il y a suffisamment de résistance au changement et suffisamment de chaos pour que les dirigeants de l’organisation perdent patience face à l’initiative de changement avant que le système ait une chance de se rétablir.  
  2. En outre (et dangereusement), beaucoup de soi-disant champions du changement ne sont pas conscients que Satir était un psychothérapeute et que sa méthode J-Curve a été employée pour changer l’identité de ses clients, les briser et les reconstruire. Ce qui est important ici, c’est que Satir était un professionnel de la psychologie travaillant avec des clients volontaires pour les aider à se transformer en les gens qu’ils voulaient être. Ce n’est pas le cas de la plupart des professionnels du savoir. Les travailleurs du savoir ont tendance à ne pas rechercher ce type de service auprès des gestionnaires et des entraîneurs. Une version plus brutale de cette technique a été employée pour transformer les adolescents en soldats mortels.  
  3. Au lieu de la transformation profonde de la courbe J, la méthode Kanban propose de petites expériences rapides en courbe J. Cette approche du changement provoque moins de résistance, évite les périodes prolongées de raclée dans le chaos et les tests sévères de la patience du leadership. Les petites expériences en J-Curve bien conçues produisent juste assez de stress organisationnel pour stimuler le changement sans tomber dans le chaos profond et le désespoir et forcer la régression d’une organisation à des niveaux inférieurs de confiance et de maturité.  
  4. La méthode Kanban est un système de gestion pour la conception et l’évolution des services interdépendants d’une organisation. Ces services sont souvent composés de plusieurs équipes Scrum, de services partagés, de gestionnaires, de cadres supérieurs et de spécialistes et sont souvent eux-mêmes desservis par d’autres services. Chaque service est livré via un système d’étapes de découverte des connaissances (plutôt que de transfert). Voyez plus ici.  
  5. La conception d’un système détermine l’aptitude à l’emploi, le flux de valeur et la qualité du service (comme le démontre l’expérience Red Bead de Deming). Il ne s’agit pas d’équipes performantes. Il s’agit de la performance du système.  
  6. La transparence du système permet aux travailleurs du savoir de s’auto-organiser autour du travail parce qu’ils comprennent le système et ont la certitude de savoir quoi faire pour fournir le service. 
  7. Les gestionnaires Kanban sont des gestionnaires de systèmes, pas des gestionnaires de personnes et non des coachs. 
     
  8. Le Kanban au niveau de l’équipe est en fait une forme de kanban proto-kanban encore, mais à l’état immature, un rendu incomplet d’un système de prestation de services. 
     
  9. Un système Kanban est un système de traction. La capacité du système est calibrée pour un débit optimal. De nouveaux travaux entrent dans le système lorsqu’il y a une capacité suffisante pour absorber le nouveau travail sans surcharger le système et perturber le flux. La demande est équilibrée par rapport à la capacité. 
     
  10. Toute demande est potentiellement réfutable. Lorsqu’il y a une capacité dans le système à commencer de nouveaux travaux, les sources de la demande collaborent pour déterminer quel est le travail le plus important à commencer et le système est réapprovisionné. 
  11.  
    Décider de la marche à suivre est basé sur une évaluation des risques économique et transparente. 
     
  12. Une fois que le système est réapprovisionné et qu’il existe un engagement à fournir le travail nouvellement commencé, les risques sont gérés avec des politiques explicites telles que les classes de service, les limites de work-in-process, les critères de pull-readiness, les boucles de rétroaction et les métriques pertinentes vitesse d’équipe). 
     
  13. Le délai moyen d’exécution du projet ou de la fonction jusqu’à l’achèvement est une mesure de base. L’amélioration du système entraîne une réduction à la fois du délai et de la variabilité du délai. Les prévisions de livraison sont basées sur des données de délais historiques. Les délais sont également gérés avec des données de délai (c’est-à-dire décider quand commencer quelque chose). 
     
  14. Tout ce qui précède est la responsabilité de la direction. Cela devrait laisser peu de capacité de gestion pour surveiller la performance individuelle et la vitesse du point de l’histoire des équipes (nombre de billes blanches). Un signe d’un système kanban mûr est que les gestionnaires ont amélioré leur comportement et sont axés sur l’amélioration du système et que les travailleurs du savoir sont libres de s’organiser autour du travail en tant que professionnels adultes qualifiés.