Il y a 30 ans, l’industrie technologique a tenté d’importer des pratiques Lean, mais cela a échoué. Au lieu d’une « amélioration continue », le progrès s’est arrêté. Agile est incompatible avec la recherche, la conception et le développement évolutif UX. Il le sera toujours. Il est temps de créer une nouvelle norme opérationnelle.
Alors que les startups se recentrent sur « l’efficacité opérationnelle », soulignons que efficacité est une façon de travaillerpas votre effectif.
Le développement agile a été le principe opérationnel #1 de la technologie pour plus de 20 ans, incontrôlé, incontesté. Pourtant, il a des défauts fondamentaux qui nous ont toujours attirés l’attention.
Défaut #1 : Les humains ne sont pas des machines.
Défaut #2 : Le design n’est pas un inventaire.
Défaut #3 : Le produit ne peut pas être défini par ce qui peut être accompli par un nombre arbitraire de personnes de compétences et d’expérience arbitraires dans un sprint de deux semaines.
Jetons un coup d’œil en arrière sur la façon dont nous nous sommes limités dans le temps :
- 2001 — Agile
- 1995 — Mêlée
- 1988 – Maigre
- 1960 – Système de production Toyota (TPS)
Le SPT évolué pendant des décennies, des années 40 aux années 70, permettant à Toyota d’atteindre et de maintenir sa position dominante parmi les constructeurs automobiles mondiaux. Ces brillants débuts axés sur l’élimination temps (déchets), mura (incohérence), et plus tard (surcharger).
L’élimination des déchets était la mieux documentée. Parmi les huit types de déchets, les plus préjudiciables étaient les stocks excédentaires – produits finis et matières premières, et les machines inutilisées. En d’autres termes, des choses pour lesquelles vous avez dépensé de l’argent et qui ne vous rapportent pas d’argent. Les solutions de Toyota étaient de nature logistique et sont devenues connues sous le nom de « fabrication juste à temps ».
“Recevez les matériaux juste à temps pour que la chaîne de montage les traite juste à temps pour que le produit fini réponde à la demande des clients.”
Un partenaire d’excellence de TPS était «La manière Toyota.” Cette philosophie appelait à une amélioration continue, y compris à surmonter les défis vers une vision à long terme, Kaizen (innover sur les opérations), et mon préféré, genchi genbutsu. Signifiant « lieu réel, chose réelle », ce principe signifiait « allez voir par vous-même », prenez des décisions en conséquence. Il a également encouragé une approche ascendante de l’amélioration, recueillant les informations de chaque employé, quel que soit son niveau.
L’Amérique a travaillé sa magie et a transformé The Toyota Way en l’équivalent de Cup Noodles. Ok, je suis peut-être injuste. La fabrication juste-à-temps était bien appliquée aux États-Unis à… la fabrication. Il a été rebaptisé Maigre dans un article de 1988, “Triumph of the Lean Production System” – la lignée était claire.
Le Lean et ses ancêtres sont parfaits pour la fabrication de biens physiques, en particulier lorsqu’il existe un marché établi et un produit mature. Elle repose sur la prévisibilité de la demande et de la chaîne d’approvisionnement. Lorsqu’il s’agit de créer un nouveau produit, les fabricants s’appuyaient sur différents processus dans leurs départements R&D. Qu’il s’agisse de Genentech développant l’insuline synthétique ou de Proctor & Gamble développant le Swiffer, le processus a été long et assez linéaire. Celles-ci impliquaient une recherche approfondie et une analyse du marché avant le développement du produit.
Le bouc émissaire de la cascade
L’industrie du logiciel en plein essor a largement suivi ces processus ; appliqués aux produits numériques, ils sont devenus connus sous le nom de Cascade méthodologie. Le terme Waterfall est devenu un fourre-tout pour décrire un processus de développement linéaire qui aboutit à une version de produit entièrement réalisée. La critique légitime est que la sortie d’un gros produit coûteux peut toujours être un raté. En tant que tel, Waterfall est utilisé comme un repoussoir pour affirmer que l’itération, les tests et la réaction au marché sont nécessaires dans un délai plus court.
Dans les années 1990, les praticiens de l’industrie technologique ont exploré les moyens d’appliquer le Lean aux produits numériques. Malheureusement, dès le départ, ils ont mal diagnostiqué le problème. Délai de mise sur le marché est important, mais je dirais davantage du point de vue des flux de trésorerie, en particulier pour les startups. Les partisans du Lean ont jeté le bébé avec l’eau du bain. Notez que la littérature Scrum et Agile fait peu ou pas mention de la recherche ou de la stratégie. Conception a eu une mauvaise réputation en tant que longue phase de perte de temps de Waterfall. Les frameworks Lean concernent la construction et la publication.
À cette époque, il y avait un combat de style Kaiju contre Mecha entre les partisans de Lean et ceux qui avaient pratiqué le développement de Waterfall. Le monstre et le robot n’ont pas tenu compte des besoins des utilisateurs et les ont plutôt piétinés et ont détruit le monde.
Quelle est la différence? Juste le diagramme – Agile représentant une pièce, Waterfall représentant un tout.
La pratique consistant à itérer sur un produit vivant sur le marché est un luxe logiciel — les mises à jour peuvent être poussées à tout moment ; les chaînes de montage et l’outillage n’ont pas besoin d’être réorganisés. Chaque produit technologique doit être construit par étapes, mais il doit également être construit vers un objectif final et un produit entièrement réalisé. Le succès exige de la stratégie, rechercheconception et genchi genbutsu, exactement comme le souhaitait The Toyota Way. L’argument Agile vs. Waterfall est une fausse dichotomie : une entreprise peut avoir une stratégie à long terme et la mettre en œuvre tout en publiant le produit de manière incrémentielle, itérative.
L’erreur de 30 ans
Comme propriétaires de produits et les ingénieurs ont tenté d’appliquer les principes de fabrication allégée au développement de logiciels, ils ont trouvé des moyens d’imiter une chaîne de montage. Les exigences seraient déterminées juste à temps, puis une équipe interfonctionnelle se précipiterait pour publier un logiciel fonctionnel. Le terme Mêlée était un choix judicieux – cela vient du rugby, la formation d’une rangée de mecs se précipitant sur le terrain en lançant le ballon d’avant en arrière. L’approche du développement logiciel a le même niveau de finesse et de stratégie.
Vous avez tous eu affaire à Scrum, voici les raisons pour lesquelles il en est ainsi :
- Il doit être programmé dans un Sprint pour s’assurer que le logiciel peut être mis sur le marché dans un cycle “itératif”.
- La planification de sprint se produit juste avant le sprint, car c’est à ce moment-là que vous aurez les dernières informations sur ce sur quoi vous concentrer, juste à temps.
- Il y a un Daily Standup pour avoir des “améliorations opérationnelles” à la volée. (Seuls les développeurs sont autorisés à parler et la discussion n’est pas autorisée car cela laisse la machine inactive.)
- À la fin du sprint, il y a une révision pour voir le logiciel fonctionnel et déterminer ce qui n’a pas été terminé ou ce qui doit être amélioré.
- Il est également censé y avoir une rétrospective pour discuter de ce qui s’est bien passé et de ce qui ne s’est pas bien passé, dans le but d’augmenter la quantité de production.
- Le Backlog n’est pas au cœur de la pratique Scrum, c’est un artefact des dommages collatéraux et des détritus de tout ce qui est largué pendant le sprint.
Vous pouvez voir à quel point Scrum est déjà assez illogique, mais ensuite cela devient tellement pire.
Quelques-uns des créateurs de Scrum se sont réunis avec d’autres mecs qui avaient mis en place d’autres pratiques de développement Lean. Avec leurs forces combinées, ils ont créé le Manifeste pour le développement logiciel agile. Les sous-entendus marxistes sont probablement intentionnels : ils affirmaient que les travailleurs seraient propriétaires des moyens de production.
Le [Fr]Manifeste Agile
En ce qui concerne les manifestes, c’est l’un des plus documents pathétiques jamais créé. Il énumère quatre « valeurs » et douze « principes ». Ils ont peut-être été bien intentionnés à leur création – cette intention était de traiter les développeurs comme des humains, et non comme des rouages dans une machine – mais maintenant nous avons bouclé la boucle. Ces principes se sont transformés en quelque chose de caustique pour les organisations. Vus maintenant, ce sont des variations sur un thème de la façon dont un pod Scrum peut se décharger de toute responsabilité.
Points forts (et mes traductions):
- Les individus et les interactions sur les processus et les outils. (Ouais, on va faire les choses comme on veut).
- Bienvenue aux exigences changeantes, même en fin de développement. (Nous pouvons aussi changer d’avis chaque fois).
- Les projets sont construits autour d’individus motivés, auxquels il faut faire confiance. (Laissez-nous tranquilles, prenez ce que vous obtenez).
- Le logiciel de travail est la principale mesure de progrès. (Le fait que nous ayons produit quelque chose, n’importe quoi, c’est tout ce qui compte).
- La simplicité — l’art de maximiser la quantité de travail non fait — est essentielle. (On va faire le moins possible).
- Les meilleures architectures, exigences et conceptions émergent d’équipes auto-organisées. (Ne nous dis pas quoi faire).
Maintenant, ce n’est pas une attaque contre nos amis ingénieurs. La plupart des développeurs avec qui je travaille sont passionnés par le fait de bien faire les choses et se sentent contraints de produire un travail de qualité inférieure en fonction des délais de sprint et des livrables promis. Pourtant, certains leaders techniques qui ont été endoctrinés dans le culte Agile se sentent tout à fait libres de suivre les principes ci-dessus. Les exigences sont plus des suggestions que des règles, les conceptions sont sujettes à interprétation, tout est bon à couper si le résultat final “fonctionne toujours”.
La combinaison des principes Agile et des pratiques Scrum est désastreuse pour les startups. Ce sont des directives opérationnelles de la direction; les concepteurs, les PM et les ingénieurs ne s’organisent pas eux-mêmes et choisissent de travailler de cette façon. Tout est au nom d’un “MVP» et délai de mise sur le marché ; c’est ce qui arrive. Chaque. Temps.
Conception de la recherche créer des solutions aux problèmes des clients, mais ce qui est toujours construit pâle en comparaison.
Chefs de produit sont pressés de créer le prochain objet brillant sur la feuille de route… juste le moins possible.
Ingénieurs sont traités comme des machines sur une chaîne de montage, toujours censées produire et livrer, incités à prendre des raccourcis pour que tout soit « fait ».
Direction est laissé se gratter la tête pourquoi le produit est si bancal et inefficace.
Loin d’éliminer temps, Agile et Scrum créent seulement des déchets. C’est une boue boueuse d’épuisement professionnel, de dette technologique, dette de conceptionun backlog gonflé, une logique frontale codée en dur et une menace omniprésente de refactorisation complète.
Comment sortir de ce cycle ?
Arrête.
Vous ne pouvez pas transformer une solution centrée sur le client en un sprint.
- Déterminez ce qui doit être construit.
- Déterminez la meilleure façon de le construire pour l’évolutivité et la pérennité.
- Ensuite, construisez-le, quel que soit le temps que cela prendra. (Cela ne prendra pas deux ans, mais cela ne prendra pas non plus deux semaines. Les versions peuvent être découpées en tranches et en dés, tant que le produit est construit selon les spécifications.)
- Encouragez l’excellence, pas les coupes dans les coins.
- Investissez dans des efforts fondamentaux tels que des systèmes de conception et une pile de technologies propres afin que les efforts futurs puissent être plus efficaces.
- Investissez dans l’UX et la profondeur sur l’étendue des ensembles de fonctionnalités.
- Investissez dans l’efficacité opérationnelle de la bonne manière, plutôt que de réduire les effectifs et d’attendre la même quantité de production.
Sinon, une seule chose peut donner – la qualité.