Faire face à la dette des systèmes

Préambule/tl;dr : J'ai récemment publié Le principe d'agilité de Lloyd Braun principalement comme une observation idiote mais vraie sur la façon dont cette ligne classique de Seinfeld "Sérénité maintenant, folie plus tard" se rapporte à Agile. J'ai terminé ce post avec une déclaration sur la façon dont nous devons mieux nous préparer à la "folie" qui viendra plus tard. Dans cet esprit, je présente mon approche de la constitution d'équipes productives. Il s'agit de rembourser la dette de vos systèmes.

L'équipe technique moderne est brisée. Nous comptons trop sur les seniors et ne misons pas sur les juniors.

J'ai beaucoup réfléchi à ce problème au cours de la dernière année, car j'ai adapté plusieurs équipes à notre "nouvelle normalité". Il y a des mois, j'ai commencé un article pour soutenir l'argument selon lequel les responsables du recrutement devraient embaucher des juniors. Pour faire un argumentaire efficace, je savais que je devais répondre à une préoccupation commune : "D'abord j'ai besoin de seniors pour former les juniors..." Rapidement l'article s'est étoffé.

Si vous êtes nouveau dans le domaine de la gestion, voici mon "traité" sur la gestion. Il s'agit de savoir comment constituer des équipes hautement efficaces et productives et s'appuie sur plus d'une décennie de gestion réussie de plusieurs grandes équipes.

Ce qui suit est une longue lecture - donc le tl;dr est :

Nous parlons beaucoup de #DebtTechnique, mais la Dette Technique est le symptôme d'un problème plus vaste que j'appelle la Dette des Systèmes.

La recette est simple :

1) Chargez vos aînés de rembourser votre dette de systèmes et de faciliter le travail.

2) LOCATION. JUNIORS.

3) Arrêtez de lutter contre l'attrition. Les juniors resteront en moyenne 18 à 24 mois. Ils veulent des expériences variées. Ils chercheront d'autres emplois. En tant que communauté technologique, nous VOULONS que les juniors acquièrent plus d'expérience sur leur chemin vers l'ancienneté. Cela les rend meilleurs et cela nous rend meilleurs. Alors, embrassons l'attrition. Commençons par nous concentrer sur leur permettre de tirer le meilleur parti de ces 18 mois, puis soutenons-les dans leurs prochaines étapes.

Toute bonne équipe de livraison met l'accent sur la convivialité. Les principes qui régissent l'utilisabilité apparaissent sous de nombreuses formes différentes : le principe de Pareto , le test de grand-mère , le principe du bien suffisant , etc. Et tous arrivent à quelque chose de très humain : est-ce plus difficile que nécessaire ?

On le voit tout le temps : des designs minimalistes qui privilégient la facilité d'utilisation et sont hyper concentrés sur une vision claire. Tout le reste est une distraction, c'est du ballonnement.

Il y a beaucoup de gens qui parlent de leadership, de gestion, d'équilibre travail/vie personnelle et de travail à distance/en personne. Tout est réévalué - et la question qui me trotte dans la tête depuis des mois est simplement celle-ci : le travail est-il plus difficile qu'il ne devrait l'être ? Ce n'est en aucun cas une nouvelle question, mais c'est un fil qui a traversé la majeure partie de ma carrière. J'adore écrire du code et créer des produits, mais une vue holistique peut révéler que plus de code n'est pas toujours la solution. Plus de code signifie plus de coûts de formation et de maintenance.

Si vous êtes un nouveau manager, garder cette question à l'esprit peut être très utile. Les managers sont responsables de beaucoup : vous aidez chaque individu - à accomplir ses livrables et ses objectifs personnels. Vous êtes responsable de la cohésion et de la direction de l'équipe. Vous êtes souvent responsable de l'établissement de processus et de politiques. Ensuite, il y a l'allocation et la planification des ressources, ainsi que la gestion des horaires de prise de force. Mais le fil conducteur de tout cela est la même question : est-ce plus difficile que cela ne devrait l'être ?

À quand remonte la dernière fois que vous avez évalué votre mécanique interne ? En considérant votre équipe de livraison comme un produit, dans quelle mesure est-il facile pour vos consommateurs (l'équipe commerciale/opérationnelle) d'atteindre leur objectif ? Et en considérant l'ensemble de votre entreprise comme un produit, est-il facile pour les clients d'atteindre le leur ?

En se concentrant sur les personnes, les mêmes questions s'appliquent : à quel point est-il difficile pour votre équipe de faire son travail ? Quelles structures, cadres, processus artificiels et hiérarchies existent qui feraient secouer la tête votre grand-mère à quel point vous avez compliqué les choses ?

Une introduction à la dette

Tout ce train de pensée d'évaluation critique de vos processus internes est, en fait, une partie de la philosophie Agile qui est souvent négligée. Les équipes affirment qu'elles sont entièrement agiles, ou un "hybride agile", mais en y regardant de plus près, vous réalisez ce qu'elles veulent dire, c'est qu'elles coupent simplement les coins gênants pour livrer plus rapidement des produits bâclés. En matière de logiciels, tout développeur chevronné saura exactement ce que cela devient une recette pour une dette technique sans cesse croissante. La blague continue des codeurs est que la dernière personne l'a mal fait, et si vous le voulez bien , vous devrez le reconstruire. Ce n'est pas dû à la paresse ou au manque de capacité. Le travail sur le terrain est plus facile car il élimine toute la dette technique - mais, laissé aux mêmes mauvais processus, il ne fera que croître une fois de plus.

La dette technique est un symptôme, et même lorsque vous êtes bon pour la rembourser activement, vous ne traitez toujours que le symptôme . Ce symptôme vient de l'erreur de penser qu'Agile se limite à la livraison de logiciels.

Une bonne définition de la dette technique est "l'accumulation de travail qui doit être refactorisé". Comme mentionné, cela découle de la prise de raccourcis lorsque l'on se concentre sur la livraison. À moins que vous ne le remboursiez activement, il croît rapidement. Le résultat d'une trop grande dette technique est la fragilité et l'instabilité.

Au mieux, la dette technique est une décision intentionnelle : il s'agit de mettre quelque chose à crédit avec l'intention de le rembourser plus tard. Dans de tels cas, la dette technique n'est pas mauvaise - à condition que vous soyez diligent pour rembourser la dette. L'incarnation la plus néfaste de la dette technique est lorsque vous ajoutez involontairement à la dette, ou pire - vous ne savez pas que vous y avez ajouté.

La dette technique traite de la technologie, mais il existe un concept similaire de dette de processus - des processus hérités qui sont devenus obsolètes, fonctionnent mal, créent des frictions, ont un impact sur la dynamique inter-équipes ou peuvent ne plus s'appliquer à mesure que les rôles ont changé. La dette de processus couvre nos déficiences opérationnelles non techniques.

Il existe encore d'autres formes de dette qui ont un impact sur la livraison : la dette de conception, la dette d'architecture.

Bien sûr, la dette n'est pas intrinsèquement mauvaise. Tout comme vous pouvez stratégiquement assumer une bonne dette financière, contracter l'une de ces formes de dette est une décision stratégique. Au lieu de payer 20 000 $ sur une voiture en une seule fois, vous contractez un prêt auto et étalez les paiements sur 10 ans. De même, la pile technologique que vous utilisez, la façon dont vous avez structuré les compétences de votre équipe, l'ancienneté de ces rôles et les processus qui pilotent votre entreprise prennent une forme de dette qui est remboursée sur une période.

Seulement - parfois nous ne remboursons pas. Ou, pire : nous pensons que nous remboursons la dette, mais nous en accumulons davantage.

Présentation : Dette des systèmes

J'aimerais introduire un concept que j'appellerai la Dette des Systèmes (Systèmes comme dans la Théorie des Systèmes ; pour en savoir plus sur la Théorie des Systèmes, lisez le fantastique Thinking in Systems de Donnella Meadow ).

La dette des systèmes est la cause primordiale et profonde des formes de dette en aval qui entravent ou ont un impact négatif sur la livraison - que ce soit par des décisions de l'entreprise ou des décisions techniques, d'architecture ou de processus. C'est le produit de raccourcis calculés dans l'entreprise, mettant le travail à crédit. La dette du système entrave le fonctionnement d'un système par sa conception structurelle.

Dans Thinking in Systems, Meadows donne un exemple simple de système : une baignoire. L'entrée du système est le robinet, la sortie étant le drain. Meadows explique comment différents facteurs peuvent empêcher la baignoire de se remplir, de rester à niveau ou de déborder. Un système optimal est le niveau d'eau restant - avec l'entrée (robinet) et la sortie (vidange) s'écoulant au même débit. La dette des systèmes serait la conséquence de prendre des raccourcis lors de la composition du système. Pour étirer l'analogie de la baignoire, peut-être que le robinet est mal installé et que l'eau finit par fuir. Peut-être que l'emplacement du drain entraîne une accumulation d'eau dans certaines zones, de sorte que la baignoire ne peut jamais se vider complètement. Peut-être que notre eau a besoin d'être adoucie et provoque l'accumulation de calcaire.

Dans ces cas, il n'y a pas d'impact immédiat, et il est toujours possible de créer un système optimal - mais ce qui est caché, c'est l'accumulation de dettes qui met le système à rude épreuve : le robinet doit couler plus vite pour compenser les fuites, ou le robinet coule plus lentement et la baignoire prend plus de temps à se remplir.

Si vous connaissez le livre de Meadows - bon nombre de ses exemples sont ancrés dans la réalité avec des modèles fournissant généralement une vision statique ; le système ne change pas avec le temps. C'est parfait pour ses objectifs, mais lorsqu'il s'agit d'individus, d'équipes, d'opérations et d'entreprises, ce que nous sommes aujourd'hui n'est pas ce que nous serons demain.

Pour définir la dette des systèmes d'une manière légèrement différente :

Dette des systèmes = Théorie des systèmes + Modèle de maturité

Avec les équipes logicielles, vous voyez la dette des systèmes se manifester de plusieurs manières :

• Avec le temps, si elles ne sont pas gérées, les équipes développent de plus en plus de "savoirs tribaux". Ceux-ci apparaissent comme des habitudes bien intentionnées, des raccourcis et des solutions de contournement. Parce qu'ils produisent des gains d'efficacité à court terme, ils font oublier les lacunes à long terme. S'il n'est pas remboursé, il existe un risque évident de perte de connaissances par attrition régulière. Cela entraîne des pertes de productivité car les équipes doivent pivoter et monter en puissance. ("Joe le savait, mais maintenant qu'il est parti - nous devrons passer du temps à le découvrir.") ou une accumulation de dette technique due à la méconnaissance. ("Nous ne pouvons pas mettre à jour ce composant. Sally l'a construit, et chaque fois que nous le touchons, il se casse...")
• Les équipes s'appuieront sur des modèles de conception personnalisés, des règles de développement non officielles ou des accords qui maximisent le flux local, mais ces modèles sont fragiles à changer. Cela entrave la livraison lorsque quelque chose ne correspond pas à un modèle établi, tenant l'équipe commerciale en otage des décisions techniques. ("Nous ne pouvons pas lancer une instance personnalisée - nous ne l'avons jamais conçue de cette façon.")
• Les équipes qui deviennent complaisantes privilégient le maintien du statu quo sur les rétrospectives perturbatrices. Ils organisent peut-être encore des rétrospectives, mais s'ils ont perdu confiance en leur capacité à résoudre les vrais problèmes, ils ne se concentreront que sur la résolution de problèmes insignifiants. ("Nous sommes surchargés de demandes d'incidents, mais peu importe - nous devons juste continuer à les résoudre, je suppose...")
• Le malaise ou l'indifférence qui accompagne le fait d'atteindre une vitesse durable malgré des frictions adressables. La vitesse durable crée un faux sentiment d'efficacité. (« Avons-nous vraiment besoin de changer le processus ? Nous avons atteint notre rythme - pourquoi le perturber ? »)

Avec les équipes Product & Operations, vous voyez la dette des systèmes de la même manière :

• Le raccourci "chaque appel client est une alarme incendie" , engageait l'équipe de développement pour résoudre rapidement les problèmes mineurs retarde les versions, réduit la vitesse, etc. ("J'ai besoin que l'équipe examine un problème soulevé par un client en colère, ça va ne prend que 20 minutes...")
• Le chaos de la dernière personne à qui j'ai parlé est ma priorité la plus élevée oblige l'équipe à changer constamment de contexte et ne peut pas se concentrer sur un problème jusqu'à son achèvement.
• Lorsque la priorisation est un raccourci grâce à l'utilisation de métriques trompeuses. Par exemple, le client fort en dollars qui n'est plus aligné sur les objectifs commerciaux. Ils avaient du sens dans vos premiers jours de démarrage, mais à mesure que l'entreprise a mûri, ce même client est devenu plus problématique. ("Nous ne savons pas si nous voudrons conserver ce client, mais ils nous paient cher donc nous devons le faire...")

Pour réitérer : Toutes les formes de dette sont lorsque nous choisissons de prendre un raccourci maintenant avec l'intention de le réparer plus tard. La dette technique, c'est quand on fait ça avec du code. La dette de processus, c'est quand nous le faisons avec nos processus formels. La dette des systèmes, c'est quand nous faisons cela au niveau organisationnel. Je préfère le voir comme « dette des systèmes » au lieu de « dette organisationnelle » parce que penser à l'organisation comme un système, cela signifie que la dette technique, de processus et de conception sont toutes directement causées par la dette des systèmes. Les facteurs qui nous poussent à contracter de la Dette Technique sont in fine liés à la Dette Systèmes. ("Vous ne pouvez sauver qu'un nombre limité de personnes de la noyade dans une rivière avant de commencer à regarder en amont pour déterminer pourquoi elles continuent de tomber.")

Par exemple : l'équipe de développement publie une nouvelle fonctionnalité qui a été correctement planifiée et chiffrée. L'équipe a été sur la bonne voie, mais dans les étapes finales, elle rencontre un problème qui force une question redoutée : retarder la publication en résolvant le problème correctement ou faire le strict minimum puis le résoudre correctement lors de la prochaine itération ? Ils choisissent de prendre en charge la dette technique : "Nous l'obtiendrons à la prochaine itération."

C'est maintenant que la dette des systèmes commence à entrer dans l'équation. L'équipe pourra-t-elle vraiment y remédier ? L'équipe est-elle suffisamment qualifiée pour refactoriser ? L'entreprise répondra-t-elle par "c'est assez bien, nous devons passer à autre chose" ? Les coûts futurs révéleront-ils qu'il est maintenant devenu trop coûteux de faire de la bonne façon ? Un changement de priorités ou une augmentation des problèmes urgents retarderont-ils soudainement le correctif d'une autre itération ? Puis une autre itération, puis une autre...

De plus, en regardant en amont : pourquoi a-t-il fallu si longtemps pour rencontrer le problème ? Quelles mauvaises hypothèses ont été faites? S'agissait-il de mauvaises hypothèses ? Il y a toujours le problème que vous ne pouvez pas résoudre avant la fin du jeu - mais alors pourquoi est-il devenu une question de retarder la sortie ? Les promesses ont-elles été faites trop tôt ? Aurait-il dû y avoir un plus grand tampon? Cela aurait-il été résolu si la Personne A (vendeur commercial en amont) parlait davantage à la Personne F (développeur en aval) suivant la chaîne la plus courte ?

Un autre exemple trop familier concerne l'infrastructure, l'architecture et les modèles d'hébergement dans lesquels nous nous enfermons très tôt, sur la base d'hypothèses sur la façon dont l'entreprise évoluera dans 3 à 5 ans. Une petite équipe peut choisir de s'endetter très tôt sur l'infrastructure et l'architecture en faveur d'une livraison plus rapide plutôt que d'adhérer aux meilleurs principes DevOps.

Bien sûr, il est facile de peindre des scénarios comme celui-ci sans les détails - mais quels que soient les détails et les excuses pour ces détails : la dette des systèmes s'accumulera. C'est inévitable. C'est OK - cela nécessite juste une attention constante et se concentre sur le remboursement à des niveaux maintenables.

Raccourcis de compensation

Nous nous endettons - Système ou autre - comme un raccourci. Avant de creuser plus profondément dans la dette des systèmes et comment la rembourser, prenons d'abord un peu de recul et demandons-nous pourquoi prenons-nous les raccourcis ? Les raccourcis, tout comme la dette, ne sont pas intrinsèquement mauvais - mais ils doivent être analysés de près.

Penser aux raccourcis physiques est une excellente façon de commencer. Si vous avez déjà été piéton ou cycliste, vous avez certainement remarqué à quel point les choses sont conçues pour les véhicules d'abord, les piétons ensuite. Lorsque vous marchez, vous finissez par prendre de nombreux "raccourcis" et ne suivez pas les routes - mais bien sûr, ce ne sont pas des raccourcis. Ces raccourcis sont les chemins optimaux à vol d'oiseau pour un piéton qui peut aller là où les voitures ne le peuvent pas. En fait, construire nos itinéraires principalement pour les voitures dans les zones piétonnes est [une autre forme] (une autre forme) de dette systémique.

Dans le monde des affaires, nous prenons des raccourcis pour compenser - par manque de temps, de budget, de ressources, de responsabilité ou de vision plus large. Le temps, le budget et les ressources sont tous à l'honneur - mais la responsabilité et une perspective large sont exactement au cœur de ma question d'ouverture : est-ce plus difficile que cela ne devrait l'être ? Lorsque vous sauvez des gens de la noyade dans une rivière, il s'agit de regarder en amont (perspective large) et de désigner la personne (responsabilité) qui continue à pousser les gens.

En d'autres termes : si vous allez avoir une conversation sérieuse sur la dette des systèmes, tout le monde doit faire partie de la conversation. Les efforts localisés ne vont pas plus loin.

Alors, comment remboursez-vous la dette des systèmes ?

Revenons à cette question précédente : dans quelle mesure est-il facile pour votre équipe de livraison de livrer ? Si vous ne vous êtes jamais posé cette question, il est temps d'obtenir des mesures ! Ces mesures ne vous donneront pas nécessairement les réponses, mais elles constituent un point de départ important. En ce qui concerne les KPI, le meilleur conseil que j'ai jamais reçu était qu'un KPI individuel n'est ni mauvais ni bon. C'est objectivement juste un nombre, une valeur. C'est votre affaire comme d'habitude - et c'est à vous de décider si vous voulez ou non ajuster ce nombre à la hausse ou à la baisse. Si vous êtes un fan du système OKR ou des objectifs SMART, c'est très bien car connaître vos KPI vous permet de faire de meilleurs OKR qui sont facilement quantifiables.

Alors commençons par quelques notions de base et descendons dans les mauvaises herbes. Ce qui suit n'est pas une liste exhaustive, et il peut y avoir de meilleures questions adaptées à votre groupe. Considérez cette liste comme un point de départ pour poser de meilleures questions.

Livraison:

• Quel est votre délai d'exécution et votre temps de cycle pour les articles hautement prioritaires/urgents ?
• Quel est votre délai de livraison et de cycle pour les articles de faible priorité ?
• Combien avez-vous alloué au remboursement de la dette ?
• De combien votre dette augmente-t-elle ?

Ces questions peuvent sembler familières à quiconque suit les performances de son équipe - mais n'oubliez pas de les poser au niveau de l'organisation. Le Lead Time du développeur a peut-être commencé à partir du moment où le ticket a été créé - mais combien de temps a-t-il existé dans la tête de quelqu'un ?

Ressourcement :

• Quelle est la répartition actuelle de votre équipe (senior vs juniors) ?
• Quel est votre risque d'attrition chez les seniors et les juniors ?
• Quel est le coût de la perte d'un senior ?
• Quel est le coût de la perte d'un junior ?
• Quel est le coût et la durée d'une location ?
• Quelle est la durée de votre entretien/on-boarding ?
• Quelle est la durée de votre formation/montée en puissance (et quelles ressources doivent être impliquées, et donc perdre en productivité ?)

Carnet de commandes :

• En supposant que le cadre stratégique du chef de produit est défini, combien d'exceptions sont faites ?
• Combien d'épopées/fonctionnalités ne sont pas ancrées dans des analyses de rentabilisation objectivement définies liées à la fois aux finances et aux délais ?
• Comment le pipeline Sales/Business Dev alimente-t-il finalement votre backlog logiciel, et quel est le temps de plomb et de cycle pour ceux-ci ?
• À quelle fréquence les objectifs commerciaux de haut niveau changent-ils et dans quelle mesure ce chaos affecte-t-il les efforts en aval ?
• Quels sont les objectifs de croissance à long terme de l'entreprise et comment les compétences de l'équipe et le plan de ressourcement s'alignent-ils ?

Carnet des opérations

• Combien de problèmes clients sont soulevés quotidiennement ?
• Combien de problèmes de clients doivent être transmis au support de niveau 1, 2, 3 ?
• Quel est le délai moyen de résolution ?
• Quel est le délai d'exécution d'un problème client et quel est le délai entre l'appel initial et la création du ticket de développement ?

Avoir une idée simple du temps qu'il faut pour que quelque chose passe de la création à la disponibilité peut être très instructif, surtout lorsqu'il s'agit d'un problème client.

Il existe un certain nombre de ressources qui aident à améliorer les métriques ci-dessus - mais la philosophie clé derrière tout cela est : 1) Mesurer, 2) Analyser, 3) Résoudre, 4) Itérer. Plus le niveau 3 peut décharger les problèmes vers le niveau 2, plus le niveau 2 vers le niveau 1 et plus le niveau 1 peut permettre au client de résoudre indépendamment, plus tout le monde devient productif.

Développeurs :

• Combien de temps leur faut-il pour récupérer la source et compiler ?
• À quelle vitesse fournissez-vous les informations d'identification aux nouveaux développeurs ?
• À quelle vitesse peuvent-ils se lever et interagir avec un environnement de travail inférieur ?
• Combien de temps faut-il à un développeur pour publier le code en production (mesuré à partir de sa date d'embauche) ?
• Combien de temps faut-il pour monter en puissance sur votre SDLC et vos processus ?
• S'ils commencent à mi-sprint, combien de temps restent-ils sur la touche ?
• Dans l'ensemble, quelle est votre courbe d'apprentissage actuelle ?

À titre de comparaison : Etsy est un excellent exemple d'efficacité et constitue une excellente référence. Etsy s'assure que les développeurs se déploient en production dès leur premier jour .

Vision holistique:

• Quel est le parcours de livraison de la création à la disponibilité ? Cartographiez le flux de travail - peut-il être optimisé ?
• Quel est le parcours client des ventes aux revenus (et au-delà) ?
• Que sont le RPO et le RTO ?
• Comment les performances de l'entreprise se comparent-elles aux performances élevées de livraison telles que décrites dans Accelerate: The Science of Lean Software and DevOps ?
• Quels sont les 10 meilleurs scénarios catastrophe cauchemardesque ? C'est quelque chose que FedEx a fait pour améliorer ses opérations et créer un « Playbook » interne pour en faire l'entreprise qu'elle est aujourd'hui.

Compte tenu de tous les chiffres et mesures derrière ce qui précède, je répéterai que chacun de ces chiffres représente votre activité habituelle. Bien qu'ils ne soient pas intrinsèquement mauvais ou bons, la dette des systèmes rend plus difficile le maintien de ces chiffres à long terme. Certains chiffres peuvent surprendre et révéler des domaines où cette dette a peut-être déjà eu un impact.

L'étape suivante consiste à examiner comment ces mesures changent au fil du temps - à mesure que vous avez mûri et continuez à mûrir. Par exemple, les ingénieurs qui ont construit le produit principal vous ont enfermé dans une architecture qui approche des limites de son évolutivité. Dans ces cas, les équipes cherchent comment elles peuvent rembourser la dette technique - mais qu'en est-il de la dette des systèmes ? Compte tenu d'un ensemble limité de ressources, d'un risque croissant d'attrition et d'une entreprise en pleine maturité, comment maintenez-vous les KPI de livraison tout en remboursant la dette technique ?

"Tuez vos chéris", virez vos "rock stars", détruisez vos "usines cachées", arrêtez d'être utiles

Ce sont un tas de déclarations audacieuses dans un seul titre. Le point dans tout cela est que : Être "utile" pour raccourcir un processus peut être dangereux. Si nous souscrivons à l'idée que « ce qui est mesuré est fait », le problème d'être utile, c'est qu'il n'est souvent pas mesuré .

Imaginez un client appelant parce qu'il a accidentellement supprimé un enregistrement dans son portail en se déplaçant trop rapidement. Ils manquent de temps - et ne peuvent pas passer par le processus de restauration d'un enregistrement. Ils appellent et votre employé du support client, voulant être utile, passe immédiatement à l'ingénieur de la base de données qui, voulant être utile, restaure immédiatement l'enregistrement. Le client est ravi, le score NPS monte. Tout est super, non ?

Ignorant les risques évidents de quelqu'un mettant à jour une base de données de production pendant un moment, il y a beaucoup d'informations précieuses qui se perdent en étant utiles :

• Pourquoi est-il si facile de faire une action aussi dramatique que le client a fait l'erreur en premier lieu ?
• Pourquoi est-il si difficile d'annuler l'action dramatique qu'ils ont dû appeler ?
• Pourquoi le service client n'a-t-il pas pu le gérer ?
• Quel impact sur la productivité a été le résultat d'être utile et de changer de contexte ? (Une tâche apparemment simple de 20 minutes finit par durer plus de 35 minutes en raison du temps nécessaire pour revenir à un flux productif.)

Soyons clairs : mon titre est audacieux. Mais, je ne préconise pas d'aider un client - cependant, je pense que de telles actions devraient être suivies d'une analyse des causes profondes. Rien de trop formel - mais quelque chose pour éviter un problème similaire à l'avenir.

Dans une organisation, j'ai amélioré la productivité de notre équipe de développement de 50 % simplement en mettant en œuvre un Playbook. Un client appelle et il est accueilli avec courtoisie par un représentant du service client qui suit un flux de travail clair vers la résolution. S'ils ne peuvent pas le résoudre, nous avons une boucle de rétroaction afin qu'ils ne fassent remonter un problème qu'une seule fois. Le résultat a été une équipe de support client plus compétente et qualifiée, une équipe de développement avec moins d'interruptions, moins de stress dans l'ensemble et, surtout, des clients satisfaits.

Le fait est que lorsqu'un travail utile se produit dans l'ombre, vous ne pouvez pas résoudre la cause première.

Nous voyons le même problème avec le développeur Rock Star qui prend trop de travail et de responsabilité pour compenser une équipe moins qualifiée - seulement pour qu'ils deviennent frustrés, s'épuisent et partent (un coût qui peut être dévastateur). Le grand livre de Will Larson - un puzzle élégant - fait un excellent travail sur la façon de gérer vos "Rock Stars".

Le Pouvoir des Juniors...

Les personnes âgées sont essentielles au succès d'une organisation et d'un produit, mais elles représentent également l'un des plus grands risques.

Par exemple, un développeur senior connaîtra la base de code de fond en comble. Ils savent ce qui est documenté et ce qui ne l'est pas. Ils sauront où il évolue bien et où il s'effondre. Ils sauront où sont enterrés les squelettes. Nous nous tournons souvent vers eux - nous nous appuyons sur eux pour créer et concevoir des fonctionnalités, concevoir des solutions et aider à résoudre les bogues les plus délicats. Ce sont les gourous du savoir qui peuvent répondre à toutes les questions. Ils forment et encadrent le personnel subalterne et sont consultés lors de l'élaboration de solutions.

Qu'il suffise de dire que l'on demande beaucoup aux cadres supérieurs. C'est une affirmation évidente, compte tenu de leur expérience et peut-être de leur intérêt pour le succès de l'organisation. Cependant, je dirais que c'est là que nous assumons le plus de dette systémique.

Tout membre du personnel supérieur qui fait progresser un livrable est un raccourci qui accumule la dette des systèmes.

Je vais répéter parce que c'est facile à mal interpréter. Vous pouvez demander à un membre senior de l'équipe de travailler sur un livrable, mais vous devez prévoir de rembourser la dette qui se sera accumulée en le faisant.

S'appuyer sur les seniors pour les livrables est un modèle brisé - en particulier dans le monde d'aujourd'hui où il y a de nombreux candidats juniors et qualifiés au niveau d'entrée, et le risque d'attrition intermédiaire à senior est à la fois élevé et coûteux .

La main-d'œuvre virtuelle à distance a rendu plus critique pour toute organisation d'élever l'équipe junior/intermédiaire tout en réduisant l'impact de l'attrition du personnel senior. Cela ne signifie pas diminuer le personnel senior, mais cela signifie une différence structurelle dans l'approche.

En utilisant une généralisation, les équipes seniors d'aujourd'hui sont largement responsables de la complexité des systèmes : leur expérience et leur expertise produisent des systèmes matures, et les composants plus petits basés sur des tâches sont mis en œuvre par les membres les plus juniors de l'équipe.

C'est exactement le modèle qui s'avère problématique lorsqu'un membre de l'équipe senior part, ainsi que la structure qui accumule la dette des systèmes. Dans cette situation, le senior est responsable des complexités et peut intervenir pour aider lorsque l'équipe junior ne peut pas livrer (le développeur "Rock Star", par exemple).

Ce problème est encore exacerbé par le taux actuel d'attrition du personnel : par exemple, les développeurs juniors à l'échelle nationale resteront dans un poste pendant 18 à 24 mois (plus longtemps dans les grandes entreprises). En d'autres termes, au moment où un junior atteint un point où il peut commencer à apporter des contributions plus importantes, il est sur le point de s'en aller.

Les organisations se battront pour retenir le personnel senior, se battront (quelque peu) pour retenir le personnel junior - et souffrent constamment d'une fuite des connaissances. En fin de compte, c'est une bataille perdue d'avance - même si le personnel est conservé ou si de nouveaux membres de l'équipe se joignent, ils sont maintenant dans une position où ils doivent rembourser une grande partie de la dette des systèmes.

Facilitez le bon travail et acceptez l'inévitable

Imaginez un petit restaurant étoilé Michelin. Le chef de cuisine est très impliqué dans la fabrication des assiettes, avec des plats trop complexes pour être distribués à une équipe de cuisiniers. Le chef est le restaurant dans ce cas.

Comparez cela avec les restaurants franchisés plus larges. Vous avez un chef de cuisine chez Corporate dont la responsabilité n'est pas de produire des plats qui sont consommés par les clients. Au lieu de cela, leur objectif est de produire des plats reproductibles. Des plats facilement reproductibles (tout en étant savoureux). Des plats optimisés pour que la courbe d'apprentissage soit minimale - les nouveaux cuisiniers peuvent facilement être formés pour produire les plats, et la perte de leur départ éventuel a moins d'impact. Les chefs cuisiniers s'associent également à des experts en efficacité pour examiner comment la cuisine du franchisé peut être optimisée pour la livraison.

C'est le modèle que nous devrions utiliser lorsque nous pensons à l'équipe moderne. La responsabilité de l'équipe senior ne doit pas être la complexité du produit. Il doit être entièrement axé sur la simplification de la livraison : simplification de la formation et de la montée en puissance, des temps de configuration, des temps de construction, de la rationalisation des délais et des cycles (à tous les niveaux, de la solution de vente/produit, à la planification des itérations, jusqu'à la publication).

Comment structureriez-vous les choses si vous savez que vous ne pouvez retenir les gens que pendant 18 mois ? En fait, comment structureriez-vous les choses si vous les mettiez sur un contrat de 18 mois, avec une résiliation ferme à la fin ? Vous voudriez que la montée en puissance soit aussi rapide et courte que possible. Vous voudriez que votre équipe d'experts s'assure que vos nouvelles recrues peuvent être embauchées en quelques semaines afin qu'elles puissent maximiser l'impact. Vous voudriez vous assurer que votre équipe d'experts peut garder une porte tournante qui maximise l'efficacité et ne jamais intervenir pour aider (pour le risque de s'endetter).

En construisant un système qui peut être plus adaptable, qui peut englober et tirer parti de l'emploi à court terme, vous réduirez par la suite l'impact si vous deviez perdre un membre de l'équipe senior, car les connaissances sont immortalisées dans le processus, pas chez les personnes.

Tag, c'est toi

Qui t'a appris à jouer au chat ? Peu importe où vous êtes dans le monde, vous avez probablement appris à jouer à ce jeu avec d'autres enfants. Les adultes n'ont pas besoin d'apprendre aux enfants à jouer au chat.

Nous considérons les mèmes comme des images amusantes, mais la définition originale d'un mème est un élément d'une culture ou d'un système de comportement transmis d'un individu à un autre par imitation ou par d'autres moyens non génétiques.

Tag est un mème. Personne ne possède les règles. Personne n'est responsable de l'amélioration du jeu. En fait, les règles sont simples tout en prenant en charge des variantes comme Freeze Tag. De plus, il peut être adapté à différents environnements. Il est conçu pour une porte tournante d'enfants qui finissent par se transformer en adolescents trop cool.

Il y a très peu de système de dette dans un jeu comme Tag. Comparez Tag à d'autres jeux de terrain de jeu qui nécessitent plus de joueurs ou plus d'équipement... British Bulldog, Dodgeball, Duck Duck Goose, Cops 'n Robbers, Red Rover. Peut-être que vous avez joué à ces jeux, peut-être pas. Ces jeux portent un peu plus de dette système. Plus de règles, plus d'équipement ou plus de joueurs signifient avoir besoin de plus d'animateurs.

Alors, comment pouvons-nous fonctionner comme Tag ?

1. Tirez parti des personnes âgées pour abaisser la barre . Les seniors ne sont pas là pour jouer à Tag ou livrer la spécification. Leur objectif est de baisser la barre : comment les gens peuvent-ils s'entraîner plus rapidement et générer de la valeur plus rapidement ? Comment des versions fréquentes, incrémentielles et régulières peuvent-elles avoir un faible risque d'impact ? (*tousse toux* DevOps, Agile)
2. Cartographiez les processus, cartographiez les flux et identifiez les points d'étranglement : peut-être que le problème n'est pas l'équipe logicielle. Ce n'est peut-être pas le manque d'une équipe de test dédiée. Peut-être que le problème se situe en amont : l'entreprise surcharge le pipeline de livraison avec des priorités contradictoires ?
3. Quel est le moteur pour que les gens fassent une pause ? Il n'y a absolument rien de mal à faire une pause - mais ce sont souvent des indices étonnants d'un courant de frustration sous-jacent. Suivre quand et pourquoi quelqu'un s'éloigne peut être très instructif : peut-être qu'il s'est éloigné parce que le code prend un certain temps à compiler et à se déployer. Peut-être qu'ils se sont retirés parce qu'ils ont besoin de réfléchir plus profondément à un défi auquel ils sont confrontés. (Ce n'est pas une mauvaise chose, mais le problème aurait-il pu être décomposé pour réduire la complexité ?) Peut-être qu'ils se sont retirés parce que le besoin d'un client les frustrait. Peut-être qu'ils ont besoin de prendre de l'air parce qu'une nouvelle fonctionnalité force une refonte ou révèle une mauvaise hypothèse.
4. Observez le manque de pauses : tout aussi révélateur, c'est quand quelqu'un est trop tête baissée. Ils ne peuvent pas s'éloigner - leur attention est requise. Cela signifie soit qu'il y a une trop grande dépendance à l'égard de quelqu'un, soit que le travail et la portée ont été définis trop largement, soit que le système sous-jacent est beaucoup plus complexe qu'il ne devrait l'être.
5. Construire une culture de simplification. C'est-à-dire, vos Managers, vos Seniors, vos Intermédiaires - tout le monde devrait pouvoir dire : "C'est plus compliqué que ça ne devrait l'être - comment pouvons-nous rendre cela plus facile ?" Recueillir des commentaires - en particulier des juniors. Les juniors ne sont pas assez valorisés. Ne commettez pas l'erreur de penser que leur manque d'expérience signifie qu'ils sont naïfs. Les juniors ne savent peut-être pas toujours qu'il existe de meilleures façons, mais ils sont très francs quant à l'endroit où ils dépensent (et gaspillent) leur énergie.
6. Chaque fois qu'un senior contribue à une livraison, découvrez pourquoi. Tous. Temps. Un bogue P0 dans la production a nécessité un correctif urgent. Le code de bas niveau nécessitait une modification. Un client avait besoin d'une discussion. Les cadres avaient besoin d'une présentation pour une mise à jour.

Une marée montante soulève tous les bateaux. Les personnes âgées devraient être la marée, pas les bateaux.

La preuve est dans le pudding

Un principe directeur tout au long de ma carrière a été de comprendre l'impact du problème sur la productivité. Il ne s'agissait pas de faire des équipes plus efficaces mais des équipes plus percutantes. Les chefs de produit ont pour mantra de mesurer le résultat, pas la sortie. L'efficacité compte lorsque vous savez ce que vous faites et que vous avez juste besoin de le faire plus rapidement. L'impact est une cible mobile amorphe, mal définie. Cela demande de s'adapter. C'est pourquoi les principes Agile, OKR, Lean et Kanban peuvent être si puissants lorsqu'ils sont utilisés correctement.

Se concentrer sur les résultats à l'échelle du système et rembourser la dette des systèmes m'a donné l'occasion d'avoir un impact de diverses manières.

• Pour une entreprise SaaS, cartographier le processus de la soupe aux noix depuis le début de la phase de prévente jusqu'au déploiement du code en production. Mesurer le temps de plomb et de cycle du point de vue de chaque étape pour identifier les goulots d'étranglement. En le considérant comme un seul système, nous pourrions alors identifier comment mieux qualifier, mieux disqualifier, et comment et quand restructurer le processus de vente et de mise en œuvre en fonction du type de client. L'application d'une approche Kanban consistant à tirer le travail plutôt qu'à le pousser, à définir des limites strictes de WIP (tout en tenant compte du mou - voir l'analogie Drum-Buffer-Rope de Goldratt ) et à formaliser la définition du terminé nous a permis d'améliorer continuellement le flux de travail lui-même. Enfin, un principe supplémentaire, dans ce cas, était de ne pas laisser le processus entraver la productivité . En créant une piste accélérée, les choses pouvaient aller plus vite dans la mesure du possible (c'est-à-dire des "raccourcis"), mais cela s'accompagnait toujours d'une analyse de l'échec du processus de base (c'est-à-dire le remboursement de la dette du système). Cela a permis de rationaliser les implémentations de 6+ semaines à 2 et est devenu un système autogéré.
• La dotation en personnel avec une philosophie Juniors First m'a permis de quadrupler la taille de notre équipe en 6 mois. En réduisant le temps de démarrage et en concentrant l'équipe senior sur la productivité du junior, nous pouvions faire face à l'inévitable et prévoir l'attrition . Cette approche a laissé à tout junior atteignant sa marque de 2 ans avec deux options attrayantes : passer à un rôle plus intermédiaire où leur objectif s'est déplacé vers l'habilitation des juniors tout en continuant à développer leurs compétences, ou travailler avec l'équipe sur une sortie à l'amiable. Cette transparence a aidé à lutter contre les démangeaisons de 2 ans que les juniors ressentent lorsqu'ils sont confrontés à l'incertitude de leur carrière.
• Rassembler les équipes des opérations et du développement sous un même processus. Cela a aligné les équipes de sorte que plutôt que des flux de travail parallèles, c'était circulaire : la sortie de l'équipe des opérations était l'entrée de l'équipe de développement. Les résultats de l'équipe de développement sont devenus les apports de l'équipe des opérations. En mettant en place un playbook "vivant" , avec des boucles de rétroaction stratégiques, les équipes sont devenues de plus en plus autonomes. Cela a libéré l'équipe senior de l'implication dans les opérations et réduit les délais de plus de 7 mois à 3 semaines.
• Faire pivoter la vision de l'équipe de développement SaaS des étapes de développement logiciel (définition, mise en œuvre, validation, publication) à l'orientation client en mettant l'accent sur l'impact tout en priorisant le travail le plus proche de l'achèvement. Cela a permis aux équipes de livraison d'avoir une meilleure idée de l'impact et des priorités et a permis à l'entreprise d'être plus consciente et critique des travaux/clients à faible impact.
• Investissements dans la rationalisation du processus de développement itératif en réduisant les délais de construction et de déploiement. C'était l'un de ces moments "Observer les pauses" où l'équipe s'éloignait fréquemment en raison de l'impuissance d'un long processus de construction/déploiement. Surtout, le correctif n'était pas entièrement technique - mais basé sur un processus. En établissant un nouveau processus, les équipes de livraison sont devenues 200 % plus productives.
• Ne pas créer de logiciel pour les inefficacités de processus. Autant j'aime écrire du code pour résoudre des problèmes intéressants, autant le nouveau code devrait être le dernier recours. Même si le code n'a pas de raccourcis ni de dette technique propre, le code doit être maintenu. Vous avez introduit plus de dette de systèmes - et vous n'avez pas abordé la racine du problème. Ces cas sont répandus et passent facilement inaperçus - mais ils équivaut à résoudre une fuite de toit en plaçant un seau sur le sol. L'élimination de ces correctifs en s'attaquant au problème fondamental crée des gains d'efficacité incommensurables et permet à l'équipe de travailler sur ce qui compte.

Mais je ne suis qu'un responsable de niveau intermédiaire, comment puis-je mettre en œuvre un changement à l'échelle de l'organisation ?

J'ai écrit plus tôt que les efforts localisés ne vont pas plus loin et je m'en tiens à cela. Lorsque l'ensemble de l'organisation jette un regard critique sur la façon d'être plus efficace, c'est là que vous voyez une réelle amélioration. Les efforts localisés ne vont pas loin - mais ils vont loin, et quand ils le font, ils apportent avec eux le capital d'influence.

La vente à emporter

Je conclurai par ces derniers principes :

1. La dette des systèmes s'accumule pour tout raccourci commercial (logiciel, conception, processus ou autre). Cela, en soi, est OK.
2. Trop de dettes est une mauvaise chose et nécessite un remboursement continu et intentionnel.
3. Ce remboursement devrait être effectué par l'équipe senior. L'équipe senior doit également se concentrer sur la manière de réduire les risques liés à la dette future (en recherchant d'abord les inefficacités locales, puis les inefficacités à l'échelle du système). Les seniors ne devraient pas travailler sur des livrables, mais quand ils le font, ce devrait être une fois. Établissez des boucles de rétroaction qui demandent "Pourquoi était-ce nécessaire et comment pouvons-nous l'empêcher à l'avenir ?"
4. Une bonne mesure de la santé de la dette des systèmes consiste à examiner la santé de l'intégration de votre équipe junior. Prévoyez le départ de votre équipe junior après 18 mois. C'est bon. Permettre à l'équipe Senior de les rendre efficaces le plus tôt possible.
5. Enhardir la voix de l'équipe junior pour identifier les problèmes. Même les problèmes naïfs sont révélateurs d'un problème plus sérieux ("Quand est-ce que je reçois mon adresse e-mail ?" ; "Comment puis-je obtenir des données de test ?" ; "Que fait notre équipe ?" ; "Je viens de saisir le code source, et J'obtiens des erreurs de construction.")
6. Prévoyez que toute personne dans n'importe quel rôle partira après 18 mois. C'est aussi OK. L'équipe senior doit être là pour travailler à la construction des processus et du pipeline qui permettent une livraison continue malgré les perturbations . Ils devraient construire des processus autonomes, des équipes autogérées et auto-organisées. L'équipe junior devrait finir par se lasser du travail, car c'est devenu répétitif. Les membres de l'équipe doivent constamment et activement se rendre redondants et inutiles.
7. Plan pour ceux qui resteront au-delà de 18 mois. Bien que vous vous efforciez de vous rendre licenciés, vous ne manquerez jamais de travail qui génère des gains d'efficacité. Définir un cadre de carrière qui élève les juniors aux intermédiaires, les intermédiaires aux seniors qui s'aligne sur l'efficacité axée sur les résultats.
8. Traitez le premier jour comme s'il s'agissait du dernier jour : le premier jour de travail, les employés ont la meilleure perspective de ce qu'il faut pour s'intégrer. Ils devraient penser : si quelqu'un d'autre devait se joindre après mon départ, comment cela pourrait-il être amélioré ?
9. Organisez des réunions régulières sur les questions stupides uniquement. Permettre aux gens de soumettre (anonymement) leurs questions les plus stupides. Vous trouverez les plus grandes lacunes dans les connaissances (et les problèmes) de cette façon. Ceux-ci doivent être traités.
10. Planifiez des réunions régulières de « remboursement » : Rassemblez l'équipe senior et recherchez les inefficacités. Coûtez leur impact. Coût leur résolution. (Cette liste explique pourquoi votre équipe senior ne manquera jamais de travail.)
11. La partie la plus importante d'Agile est son adaptabilité. Ajustez fréquemment. Avoir des boucles de rétroaction. Ce qui fonctionnait auparavant ne fonctionnera pas toujours. Ce n'est pas un problème - c'est la norme. Quiconque résiste au changement continu et à l'expérimentation est une plus grande partie du problème qu'il ne le pense.
12. Enfin, et peut-être le plus important : il ne s'agit pas d'un exercice « d'équipe ». Cela devrait être un exercice à l'échelle de l'entreprise. Bien que vous puissiez générer des efficacités locales au sein de votre équipe, elles n'iront pas plus loin. Cela étant dit, si vous n'êtes pas en mesure d'influencer une approche à l'échelle de l'organisation, obtenez l'adhésion de votre responsable, puis créez des chartes autour de vos équipes qui isolent votre équipe des facteurs externes. Travaillez avec votre responsable pour définir la portée de votre système plus petit, ses entrées et ses sorties, et obtenez son approbation sur la manière dont vous prévoyez d'évaluer, de développer et de rembourser votre dette de systèmes.

C'est tout! (Il a écrit, reconnaissant toute l'ironie d'avoir écrit son plus long article.)