Scrumfall : Quand Agile devient Waterfall sous un autre nom

L’Église Agile est corrompue de l’intérieur par des forces institutionnelles qui ont en fait refusé ou été incapables de s’adapter à l’humanité radicale incarnée dans ses groupes collectifs, auto-organisés et interfonctionnels. Une enveloppe évidée de Scrum dissimulant les maîtres d’œuvre de Waterfall est le cheval de Troie de cette trahison.

Avec les techniques de Waterfall se faisant passer pour Scrum – appelez-le Scrumfall – les organisations réaffirment la microgestion descendante, renforçant les silos, en enchaînant la flexibilité et en banalisant les ingénieurs d’applications logicielles comme de simples rouages ​​​​créant du code.

Cette imposture du vrai Scrum défait non seulement les avantages garantis d’Agile, mais aussi ses principes centrés sur l’humain, qui mettent l’accent sur la confiance, la coopération, le respect, la connexion et un lieu de travail durable.

Agile n’était pas censé être de cette manière.

La garantie brisée d’Agile

Le Manifeste Agile est bref, doux… et révolutionnaire :

• « Les gens et les interactions plutôt que les processus et les outils »
•  » Exploitation d’un logiciel plutôt que d’une documentation détaillée »
• « Partenariat client plutôt que négociation d’un contrat »
• « Réagir au changement plutôt que suivre une stratégie »

« Oncle » Bob Martin– parmi les principaux provocateurs et signataires du manifeste, et auteur de Clean Code : A Handbook of Agile Software Craftsmanship— aurait caractérisé le manifeste comme « un ensemble de valeurs basées sur la confiance et le respect de l’autre et la promotion de modèles d’organisation basés sur les personnes, p partenariat et la construction des types de quartiers organisationnels dans lesquels nous souhaiterions travailler. »

Agile est censé être centré sur les individus, pas sur les procédures – sur des personnes travaillant ensemble avec soin pour résoudre les problèmes ensemble dans une culture d’autonomie et de respect partagé, une culture durable qui valorise la santé, le développement et l’épanouissement de chaque individu.

Il y a une foi ancrée dans le manifeste que cette technique d’ingénierie logicielle est à la fois nécessaire et remarquable pour les personnes âgées dessins, tels que Waterfall. Nécessaire en raison de la complexité inhérente et de l’indétermination de l’ingénierie des applications logicielles. Supérieur en raison du fait qu’il exploite la puissance collaborative complète de l’intelligence de chacun. Cependant, cela est secondaire par rapport au concept fondamental d’Agile : Nous valorisons les individus.

C’est une entreprise rare aujourd’hui qui ne paie pas de paroles pour ce concept. « Nous valorisons nos individus. » De nombreux services donnent plutôt la priorité à la gestion de leurs ressources humaines de base. Cela étant désormais inacceptable à énoncer à voix haute, de nombreuses entreprises l’ont revêtu des vêtements de Scrum, déclarant l’idéologie Nimble tout en réaffirmant la microgestion hiérarchique de Waterfall.

Une imposture du vrai Scrum

La mauvaise application des points d’histoire est le vecteur par lequel cette simulation de Scrum est fournie.

Les points d’histoire Scrum ont été initialement prévus pour représenter la complexité relative des histoires. Ils sont une approximation d’une abstraction de l’effort relatif anticipé, réalisé avant d’engager réellement l’ingénierie. Ils ne sont pas une estimation de temps, et ils ne sont pas une base légitime pour fixer une date d’échéance.

Et pourtant, c’est précisément le nombre de les organisations utilisent des points d’histoire, les liant à des échéanciers pour extraire des devis brillants de leur … eh bien, disons des chapeaux. Ils anticipent ensuite leurs atouts humains pour s’adapter au plan plutôt que le plan s’adapte aux personnes et aux leçons émergentes de la mise en œuvre.

Ils pressent leurs individus de créer du code, en respectant le calendrier pour livrer des histoires à temps . S’il s’avère qu’une histoire d’environ quatre heures prendra en fait 16, eh bien, le temps de marteler des Red Bulls, puis de se bousculer pour équilibrer les calculs de rêve qui mettent à zéro la valeur de l’humanité.

Est-ce que qui ressemblent à une méthodologie qui place « les individus et les interactions » au-dessus des « procédures et des outils » ? Une qui place la « collaboration client » plutôt que le « règlement de contrat » ? S’agit-il de « réagir au changement » plutôt que de « suivre une stratégie » ?

Certainement pas. Ce sont des histoires comme des mini-cascades, chacune traitant de l’ingénieur comme d’un rouage dans le fabricant de son employeur. Des histoires comme des commandes entièrement définies pour des morceaux de code, sans aucune compréhension de l’artisanat, de la créativité et de la réflexion importante nécessaires pour résoudre des problèmes aussi complexes.

La cascade sous tout autre nom est toujours obsolète

Ces mini-cascades déguisées en Scrum reflètent une approche descendante et linéaire qui ne donne pas aux ingénieurs d’applications logicielles l’autonomie, l’accès et l’autorité pour piloter l’application de ce que l’équipe produit exige.

Il n’y a pas d’espace pour de véritables discussions et un véritable partenariat. Pas de place pour que de meilleures idées émergent, ou pour que quiconque change d’avis.

Scrumfall s’appuie, pour le dire simplement, sur l’équipe produit (composée d’humains) offrant une spécification totale et optimale avant le début du développement. Et cela compte sur le groupe de développement (comme les êtres humains) qui planifie une application complète et idéale avant qu’une seule ligne de code ne soit composée.

Pas même le Dr Winston W. Royce, qui a écrit l’article critique sur ce que nous appelons maintenant Waterfall, croyait que c’était possible. « Je crois en ce concept », a-t-il composé, « mais l’application expliquée ci-dessus est dangereuse et accueille l’échec. »

Lorsque les imperfections inévitables de la spécification et de l’exécution émergent plus tard, Royce a composé, « Les modifications de style nécessaires sont susceptibles d’être si perturbateurs que les exigences logicielles sur lesquelles la conception est basée et qui fournissent le raisonnement pour tout sont violées. »

Il n’est pas surprenant que nous ayons eu besoin d’une technique différente.

Scrumfall peut-il fonctionner ? Bien sûr, dans les cas les plus insignifiants. Besoin d’une page de connexion standard ? Nous pouvons définir, estimer et réaliser cela de manière rapide sans une grande coopération continue.

Pour tous les obstacles vraiment fascinants, importants, voire innovants dans le génie logiciel – le travail qui est complexe et non déterministe – nous avons besoin d’êtres humains, collaborant à des méthodes significatives pour élaborer ensemble de meilleures options.

L’impact papillon engendre des bugs

Le partenariat présente imprévisibilité inévitable dans la procédure. (Et le fait d’entrer dans les chefs de projet Waterfall cachés dans le cheval de Troie de Scrum n’aime pas l’imprévisibilité.) L’incertitude n’est pas un bogue mais une fonction d’Agile, qui identifie que de meilleures options ne peuvent émerger que si le processus embrasse l’inconnu et sécurise la prérogative des individus à modifier leur esprit.

L’ensemble du domaine du génie logiciel est si jeune, à peine plus de 50 ans, et change si rapidement. Comparez cela aux millénaires de développements, d’améliorations et de normalisations du génie civil. Une grande partie de ce que nous faisons est tout nouveau, une exploration de l’inconnu.

L’application logicielle est également beaucoup plus compliquée. Le nombre brut de lignes de code n’est qu’une procédure de complexité non raffinée, considérez que même une application iPhone de base a normalement 40 000 lignes de code, avec une application logicielle plus importante dépassant généralement des millions de lignes de code. On estime que la base de code de Google contient 2 milliards de lignes de code, comparables aux 3,3 milliards du génome humain.

Lorsque vous considérez toutes les interactions entre ces lignes de code, vous entrez dans le domaine de la théorie du chaos, la création de logiciels application très sensible aux effets papillon : aux effets follement inattendus.

En bref, on gère une procédure naturellement non déterministe. Séparer, isoler et confiner les gens ne résoudra jamais l’incertitude. Faire respecter des dates d’échéance approximatives et des stratégies rigides n’entraînera pas de résultats déterministes.

Au lieu de cela, ces chaînes de mini cascades causent des ravages, un mauvais code et, paradoxalement, des dépassements de coûts et des délais non respectés. Le succès à long terme est sacrifié à l’essentiel à court terme de Scrumfall pour effectuer des mesures arbitraires. C’est aussi un moyen sûr de stresser les ingénieurs, qui partiront bientôt pour d’autres opportunités avec une satisfaction et une durabilité plus complètes, moins d’agitation.

La chute de Scrumfall libère le véritable pouvoir d’Agile

Agile reste une excellente idée qui place la valeur des personnes avant celle des processus. Son extrême restructuration du processus de vie du développement logiciel continuera de transformer notre domaine et de produire des options remarquables.

Cependant, pour libérer le véritable pouvoir d’Agile, nous devons accepter complètement la complexité non déterministe des problèmes significatifs nous résolvons. Il y a beaucoup de choses que nous ne savons pas au début d’une toute nouvelle tâche, et Agile dit que c’est tout à fait correct.

Les personnes intelligentes qui collaborent dans une culture centrée sur l’humain peuvent découvrir leur propre chemin vers une excellente option. Vous devez simplement leur faire confiance avec la polyvalence nécessaire pour réparer les choses comme ils l’entendent.

Il y aura des virages incorrects tout au long du processus. Les individus changeront d’avis ou verront une bien meilleure option. Certaines histoires prendront plus de temps que prévu. (Et certains peuvent prendre moins.) Vous devrez peut-être modifier votre chronologie, repenser votre MVP ou redéfinir vos priorités.

Agile soutient que rien de tout cela n’est cassé, rien de tout cela n’est une erreur et rien de celui-ci est gaspillé. C’est ce que font les individus intelligents lorsqu’ils résolvent des problèmes complexes. Au lieu d’essayer de restreindre toute cette imprévisibilité, Agile l’accueille comme l’essence même du développement.

Il y a un équilibre à maintenir, bien sûr. Agile ne peut pas être une anarchie de concepteurs qui n’aboutit jamais à un élément terminé. Correctement exécuté, Scrum (ou Kanban) maintient le groupe aligné sur ce qui est nécessaire et sur ce qui aboutira raisonnablement au résultat souhaité dans un délai et un plan de dépenses limités.

Mais nous devons arrêter de briser le pouvoir d’Agile en déterminer fanatiquement des unités de travail vanité plutôt que la valeur de ce qui est livré.

Pour comprendre la véritable capacité d’Agile, nous devons nous réengager envers ses principes fondamentaux et les vivre dans tout ce que nous faisons en bannissant les maîtres d’œuvre implacables de Chute d’eau cachée à l’intérieur de Scrumfall.