Pourquoi les équipes agiles d'entreprise échouent

Source: https://unsplash.com/@rawpixel

La semaine dernière, j'étais dans une salle de conférence d'une entreprise de 20 milliards de dollars, animant un atelier sur Agile. Le groupe présent était composé des directeurs et des responsables hiérarchiques de chaque fonction dans une seule ligne de produits au sein de cette société géante. Ces dizaines de dirigeants, choisis parmi UX, Engineering et Product Management, représentaient une équipe plus large d'environ 150 personnes travaillant sur cette gamme de produits. En tant qu’unité, ils se sont récemment lancés dans un voyage pour devenir «agile».

Ce n'est pas une situation de transformation d'entreprise. Ils ne bénéficient ni du soutien explicite ni du découragement des cadres supérieurs. L’attitude officielle des entreprises vis-à-vis de l’agilité dans cette entreprise est décrite comme une indifférence bénigne. Alors, ils sont plus ou moins seuls pour l'essayer et réussir ou échouer.

La seule raison pour laquelle j'étais là, comme c'est assez typique pour moi, c'est que ça n'allait pas bien jusqu'à présent. Mon rôle était de les aider à comprendre pourquoi et à les décontenancer. En l'occurrence, ils échouent pour les mêmes raisons que toutes les autres équipes que j'ai rencontrées au cours des 5 dernières années.

Voici ces raisons. Pour des raisons de simplicité, celles-ci sont écrites sous forme d’énoncés francs et factuels. Tous ne s'appliqueront pas à votre situation.

1. Il n'y a pas de vision claire pour le produit.

Si vous arrêtez un membre de l'équipe dans le couloir et demandez «Quelle est la vision à long terme de notre produit», pourraient-ils l'exprimer en une ou deux phrases? Bien sûr que non. Ils peuvent en savoir un peu plus sur le client cible. Ils peuvent certainement pontifier en connaissance de cause sur les caractéristiques de la solution. Mais peuvent-ils vraiment dire quel problème le client a-t-il à résoudre? Je suppose que non.

L'idée a été transmise par un haut dirigeant basé sur une épiphanie lors d'une retraite du leadership. Cela a été jeté dans une session de planification budgétaire semblable au Thunderdome, et cet exécutif particulier a gagné la bataille d'influence et son projet de familier a été financé pour 12 mois. La nouvelle vous a été livrée comme une présentation Power Point de fait accompli avec toutes les ressources, fonctionnalités et calendriers planifiés à l'avance. On vous a dit de manière efficace simplement «allez-y, construisez-le». Maintenant, vous essayez de vous acquitter de cette tâche impossible et espérez qu'Agile vous aidera.

Solution: Passez un peu de temps à formuler un énoncé de vision clair pour le produit. Utilisez un modèle d'entreprise ou une zone de travail maigre pour capturer vos hypothèses. Invitez tous les membres de l'équipe à participer. Remettez ces hypothèses à la haute direction (si elle refuse de se présenter) et assurez-vous que vous êtes sur la même page.

PS: S'ils vous mordent la tête, appelez-moi.

2. Les métriques commerciales sont obscurcies.

L’équipe ne pense pas aux coûts et aux revenus quotidiennement. En fait, l’équipe ne sait probablement pas combien il en coûte à la compagnie de les garder toutes au travail. Ils ne savent pas combien de clients ils ont besoin, payant combien par période, afin de faire leurs frais sur cette idée folle. En gros, ils ne pensent pas beaucoup à la provenance de leurs salaires.

Si vous posez la question à la plupart des startups, celles-ci auront une bien meilleure idée de leur taux de combustion global et de leurs performances commerciales, car les revenus et la rentabilité sont toujours une priorité. C’est rarement le cas dans les entreprises.

Ce n’est pas si difficile à calculer dans tous les cas. En fait, les responsables hiérarchiques peuvent généralement fournir un chiffre précis du taux de combustion de leur équipe technique en quelques minutes. Lorsque nous comparons ensuite ce chiffre (ce que nous coûtons réellement) à nos chiffres de vente actuels (quels revenus nous générons réellement en tant qu’équipe), c’est un tout nouveau jeu de base-ball.

Solution: Calculez les revenus et les coûts de votre équipe nécessaires au succès de votre produit et assurez-vous que tout le monde le sait. Cela peut être très révélateur. Vous devriez l'essayer avec votre équipe lors de la prochaine réunion de planification.

3. Vous continuez d'interférer.

À quand remonte la dernière fois que vous avez interrompu le flux de travail normal à cause d’un changement urgent de direction? Il peut s’agir d’une plainte ou d’une demande récente d’un client, ou d’un courrier électronique fort du PDG sur le schéma de couleurs utilisé lors de la démonstration du produit la semaine dernière.

Dans tous les cas, si vous interrompez le flux de manière régulière, vous causez un énorme stress à l’équipe. Ce stress se traduit par un débit plus lent, un moral plus bas, un roulement plus élevé, des retards d’expédition, une fabrication médiocre et un ralentissement général des performances de l’équipe.

Alors, découpe-le. Vous ne bénéficiez pas de privilèges spéciaux dans le schéma de hiérarchisation simplement parce que vous êtes plus important dans l'organigramme.

Solution: Allouez chaque semaine une certaine capacité au travail non planifié, par exemple 20% de votre capacité totale. Cela signifie que ne programmez que 80% du temps de votre équipe et laissez le reste non programmé. Cette capacité peut être déployée en cas d '"urgence" sans impacter le planning. Utilisez-le pour rembourser une dette technique chaque fois qu'il reste non réclamé. Vous pouvez alterner les membres de l'équipe pour faire cela.

4. Vos équipes ne sont pas dédiées.

C'est un gros problème pour moi. Toutes les grandes entreprises avec lesquelles je travaille ont ce problème. La plupart des personnes d'un projet sont affectées à plusieurs autres projets. Lorsque je demande qui fait partie de l’équipe, j’obtiens des réponses telles que l’ingénieur Un tel et tel est attribué à 50%, et l’ingénieur Quel est son nom est avec nous 20% de son temps. Plus de la moitié des participants au projet consacrent plus de la moitié de leur temps à d’autres projets. Pas étonnant que ce soit une épave de train!

Ce. N'est-ce pas? Travail.

Les équipes agiles doivent être dédiées. À votre connaissance, combien d'équipes de démarrage comptent 50% de la moitié des ingénieurs travaillant dans un autre démarrage? Je vais répondre pour vous. AUCUN!

Le développement de produits est un sport d'équipe. Cela nécessite une concentration extrême ainsi que beaucoup de communication et de coordination entre les membres de l'équipe. Chaque personne de votre équipe, qui est également affectée à un autre projet pendant une partie de leur temps, ajoute un retard important à la date d'expédition, mesuré probablement en semaines ou en mois.

Et puisque les chefs d’entreprise me repoussent plus que tout autre sur ce point, je vais vous donner un exemple concret:

Vous demandez: «Avons-nous vraiment besoin d'une personne UX dédiée dans l'équipe? Et si ils sont inactifs la moitié du temps? Ne perdons-nous pas de l'argent? »Admettez-le, vous l'avez déjà dit.

Voyons cela à fond.

Vous avez dix ingénieurs et un concepteur d’interaction (vous ne devriez pas avoir ce rapport 1/10, mais vous l’aurez probablement, alors nous allons simplement l’utiliser). Le concepteur construit les structures filaires que les ingénieurs peuvent implémenter, disons 100. Vous avez maintenant 10 ingénieurs qui démarrent et le concepteur revient à ses autres projets.
Presque immédiatement, un ingénieur a besoin de clarification. Ils ont envoyé une demande au concepteur, mais celui-ci est lié et l'ingénieur doit attendre (délai). Peut-être que l’ingénieur ouvre une autre tâche et commence à travailler. Lorsque la conception sera remise en ligne, l'ingénieur devra définir cette seconde tâche pour rouvrir la première (délai).
Maintenant, un deuxième ingénieur a besoin d'aide. Et éventuellement un tiers. Ils attendent tous les deux aussi (délai). Le concepteur redevient disponible et commence à travailler avec le premier ingénieur, tandis que les deux autres font la queue (délai). Les tâches des deux autres sont inachevées (délai). Les trois ingénieurs ont perdu une partie du contexte dans lequel ils travaillaient (délai).
En travaillant avec le premier ingénieur, le concepteur découvre une erreur dans la conception et doit mettre à jour les 100 structures filaires (gros délais). Chaque ingénieur doit maintenant s’arrêter et revérifier son travail par rapport aux nouvelles conceptions (retards importants). Certains travaux déjà effectués doivent être abandonnés et recommencés (délais plus longs).

Avez-vous eu l'idée, ou devrais-je continuer? Dans l'exemple ci-dessus, vous pouvez remplacer le concepteur par un développeur d'API backend et la situation empire encore davantage.

Solution: Organisez-vous en petites équipes dédiées interfonctionnelles. Travaillez ensemble pour une petite série de tâches et obtenez des retours et des éclaircissements les uns des autres.

5. Vos équipes ne sont pas colocalisées.

Les équipes de grandes entreprises ont tendance à être composées de «ressources» (tirez-moi s'il vous plaît pour appeler des «ressources») à partir d'un vaste pool réparti géographiquement. En conséquence, les équipes de produits d'entreprise ont des membres dans des fuseaux horaires différents. Cela rend la coordination très lente et coûteuse. L'exemple ci-dessus pourrait facilement être écrit à titre d'exemple à travers des zones géographiques.

Il en résulte beaucoup d'attentes et de problèmes de communication. La fidélité de la communication à distance n’est jamais aussi bonne que face à face. Les appels vidéo facilitent un peu les choses, mais ce n’est pas la même chose que de pouvoir marcher ensemble vers le tableau blanc et d’arranger des choses.

Solution: Mettez tous les membres de votre équipe dans la même pièce ou au moins au même étage du même bâtiment. Si vous devez travailler avec des personnes éloignées, séparez les tâches conformément à la loi de Conway, ce qui signifie que divisez-les géographiquement par composant (modules avec des interfaces clairement définies) et non par fonction (conception, ingénierie).

6. Votre équipe est trop grande.

Il est typique de trouver d’énormes équipes dans des entreprises fabriquant des produits qui ne sont franchement pas aussi sophistiqués. Les équipes sont si nombreuses pour diverses raisons, principalement en raison du fait que les cadres ont tendance à construire leur ego autour de grands groupes de personnes.

100 ingénieurs pour construire un produit SaaS? Sérieusement?

Les grandes équipes sont plus lentes car les coûts de coordination sont énormes. Vous avez besoin de davantage de couches de gestion, de réunions et de documentation. L’effet négatif d’une grande équipe sur sa vitesse s’aggrave de manière asymptotique au fur et à mesure de sa croissance.

Solution: Vous devez utiliser la plus petite équipe possible pour créer des produits dans une entreprise. Si vous pouvez le réduire à une vingtaine, voire à une douzaine, vous vous en tirerez très bien.

7. Vous avez trop de dette technique.

Les entreprises ont tendance à avoir beaucoup d'anciennes bases de code. Cependant, ce n’est pas la vraie raison pour laquelle la dette technique s’accumule pour les équipes d’entreprise Agile. Je parierais que la majeure partie de la dette technique de votre projet actuel a été mise par votre équipe depuis le début de votre projet actuel, au lieu d’être héritée par l’utilisation de systèmes hérités plus anciens.

En effet, malgré les 15 années de répétition de la communauté Agile sur l’importance des pratiques techniques de (1) programmation par paires, (2) de développement piloté par des tests et (3) d’intégration continue sur la qualité du code, très peu les équipes d’entreprise font réellement l’une de ces choses.

Pour diverses raisons (principalement liées à la vente de «Agile» à des cadres par de grandes sociétés de conseil qui se concentrent sur le processus mais pas sur l’excellence technique), les équipes d’entreprise Agile ont rarement adopté les pratiques techniques essentielles qui rendent Agile aussi formidable. en premier lieu.

En conséquence, de grandes équipes d'ingénieurs génèrent des systèmes mal conçus et mal exécutés, puis se brisent les uns contre les autres au cours de leurs longs et douloureux cycles de publication.

Solution: Employer «Extreme Programming», fondamentalement. Utilisez les pratiques techniques d’Agile, dans l’intérêt de Pete !! En outre, utilisez les outils technologiques modernes et les langages construits dans l’esprit Agile. Si vous êtes trop préoccupé par le risque pour utiliser ces nouveaux outils parce que «nous sommes une société cotée en bourse», eh bien, Amazon vous écrase déjà. Bonne chance avec ça.

8. Vous faites trop de choses en même temps.

Là-haut, avec des équipes dédiées, il est essentiel de faire plusieurs choses à la fois et de les faire très bien. La plupart des équipes d'entreprise, probablement parce qu'elles comptent trop de personnes, ont tendance à travailler sur des dizaines de fonctionnalités en même temps.

Vous feriez mieux de limiter vos itérations à quelques fonctionnalités clés sur lesquelles travaillent tous les membres de l’équipe. En langue Kanban, nous appelons cela les limites «Work in Process» (WIP). En substance, vous créez un environnement plus collaboratif en obligeant un certain nombre de personnes à travailler ensemble sur les mêmes éléments. Personne n'est autorisé à démarrer une nouvelle chose à cause des limites du WIP.

Les résultats sont moins de choses à la fois faites mieux et plus rapidement. Plus de travail d'équipe et de collaboration. Qualité supérieure et moral supérieur. Moins de reprises et moins d'erreurs.

Solution: Implémentez immédiatement les limites WIP. Si vous avez une équipe de 10 personnes, définissez la limite WIP sur 5 éléments afin que tout le monde soit obligé de se jumeler à quelqu'un d'autre. Croyez-moi, vous serez surpris.

9. Le déploiement d'un nouveau logiciel prend trop de temps.

Le problème du long déploiement est lié au problème de ces systèmes existants. Les entreprises ont généralement une équipe des opérations chargée de diriger le code jusqu'à la production. Ces personnes sont formées pour s'assurer que le code est sécurisé, performant et fonctionnel avant qu'il ne soit autorisé à vivre sur les serveurs de l'entreprise.

Encore une fois, pendant que vous vous efforcez de laisser de simples ingénieurs mortels déployer leur propre code pour la production, des sociétés comme Amazon volent rapidement votre part de marché. Vous voudrez peut-être peser le risque d'ouvrir l'accès de la production à l'équipe d'ingénierie avec le risque de disparaître du marché parce que vous êtes trop lent pour réagir aux menaces concurrentielles.

Solution: DevOps. Tout ingénieur doit pouvoir créer de nouvelles infrastructures de développement et de test à tout moment. Les poussées en production doivent passer par un processus automatisé comportant tous les tests et toutes les dispositions nécessaires.

10. Le reste de l'entreprise est inconscient.

Et enfin. Votre «expérience» dans Agile, si importante pour vous et votre équipe, ignore complètement le nombre de fonctions critiques dont vous aurez besoin pour faire votre travail. Je parle des achats, du droit, du marketing, des ressources humaines, etc. Si vous devez coordonner avec une partie non agile de l’organisation de manière opportune, vous vous retrouverez dans un monde de souffrances.

Il doit exister un moyen de travailler avec des groupes extérieurs à votre équipe de manière à ne pas gâcher totalement vos efforts.

Nous avons remarqué dans la communauté Agile que les commandes descendantes fournies par la suite C, la transformation Agile, ne fonctionnaient pas vraiment. C’est parce que si les gens sur le terrain ne sont pas achetés et excités par le changement, cela ne collera pas. Et bottom-up non plus, sans soutien exécutif.

Solution: Vous avez essentiellement trois stratégies pour gérer la traduction Agile vers non Agile, et vous devez tout faire en même temps.

  1. Organisez une campagne d’influence continue au sein de votre organisation pour gagner des supporters clés de haut niveau. Je vous garantis que d’autres dirigeants et dirigeants de votre entreprise essaient ou envisagent d’essayer d’utiliser Agile à une échelle ou à une échelle quelconque. Allez les trouver et faites des alliances. C’est après tout comment les choses se passent dans les grandes institutions humaines. Les entreprises ne font pas exception.
  2. Déterminez ce dont vous avez besoin parmi les groupes fonctionnels non-Agiles de votre organisation et assurez-vous de leur parler à l'avance. Dites-leur ce que vous faites, comment cela fonctionne et, surtout, comment il leur sera plus facile de travailler avec vous comme vous le leur demandez.
  3. Coupez impitoyablement vos dépendances. Cette partie est plus ou moins sous votre contrôle. Faites pression pour utiliser des outils, des infrastructures, des supports marketing, un langage juridique ou autre, que vous et votre équipe pouvez créer, emprunter ou acheter vous-même. Cela prendra du temps pour que cela se produise, vous devriez donc commencer immédiatement.

Agile, bien fait, c'est génial

Non, vous n'êtes pas fou d'essayer cela. En fait, je dirais que c’est la seule façon de placer votre entreprise dans la position concurrentielle qu’elle doit être pour la prochaine génération. L'alternative est la mort lente - ou rapide - aux mains de concurrents plus petits et plus agiles.

Si vous voulez obtenir de l'aide, je m'intéresse toujours à un café ou à un appel téléphonique. Laissez moi un mot.

Être un meilleur leader technologique

Inscrivez-vous à la classe de maître Startup Patterns pour les leaders technologiques émergents. Entrées variables, mais les places sont limitées. Appliquer maintenant.