Crédit : Dreamstime
L’Église Agile est endommagée de l’intérieur par des forces institutionnelles qui ont en fait refusé ou n’ont pas pu s’adapter à l’humanité radicale incarnée dans ses groupes collectifs, auto-organisés et interfonctionnels. Une enveloppe évidée de Scrum cachant 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 services réaffirment la microgestion descendante, renforçant les silos, en enchaînant la polyvalence et en banalisant les ingénieurs logiciels comme de simples rouages du code.
Cette imposture du vrai Scrum défait non seulement les avantages assurés du produit Agile, mais aussi ses principes centrés sur l’humain, qui mettent l’accent sur la confiance, le partenariat, le respect, la connexion et les environnements de travail durables.
Agile n’était pas censé être en faisant cela.
L’engagement brisé d’Agile
Le Manifeste Agile est bref, doux… et révolutionnaire :
- « Les individus et les interactions sur les processus et les outils »
- « Utiliser un logiciel plutôt que de remplir de nombreuses formalités administratives »
- « Coopération avec les consommateurs plutôt que de négocier un contrat »
- « Répondre à une modification plutôt qu’à suivre un plan »
« Oncle » Bob Martin – parmi les principaux provocateurs et signataires du manifeste, et auteur de Clean Code : A Handbook of Agile Software Application Workmanship – aurait en fait caractérisé le manifeste comme « un ensemble de valeurs basées sur sur la confiance et le respect mutuels et favorisant l’organisation l des modèles basés sur les individus, la coopération et la construction des types de communautés organisationnelles dans lesquelles nous souhaiterions travailler. »
Agile devrait être centré sur les personnes, pas sur les procédures – sur des personnes faisant équipe 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 la satisfaction complète de chaque individu.
Il y a une foi ancrée dans le manifeste que cette méthode d’application logicielle l’ingénierie est à la fois nécessaire et remarquable pour les modèles plus anciens, tels que Waterfall. Nécessaire en raison de la complexité et de l’indétermination inhérentes au génie logiciel. Supérieur car il exploite la puissance collective complète de l’intelligence de chacun. Ceci est secondaire par rapport aux nombreuses idées essentielles d’Agile : Nous valorisons les gens.
C’est une entreprise rare aujourd’hui qui ne paie pas de pure forme à cette idée. « Nous apprécions nos gens. » De nombreuses organisations accordent plutôt la priorité à la gestion des ressources humaines de leurs produits. Ceci étant désormais inacceptable à dire à haute voix, de nombreuses entreprises l’ont habillé en 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 étaient initialement destinés à représenter la complexité relative des histoires. Ils sont une approximation d’une abstraction de l’effort relatif attendu, faite avant d’engager réellement l’ingénierie. Ils ne sont pas une estimation du temps, et ils ne sont pas une base légitime pour fixer un délai.
Et pourtant, c’est précisément ainsi que de nombreuses organisations utilisent des points d’histoire, en les connectant à des chronologies pour extraire des estimations brillantes de leur … eh bien, disons des chapeaux. Ils s’attendent alors à ce que leurs possessions humaines s’adaptent à la stratégie plutôt qu’à ce que le plan s’adapte aux individus et aux leçons émergentes de l’exécution.
Ils pressent leurs employés de créer du code, en respectant le calendrier pour fournir des histoires à temps. S’il s’avère qu’une histoire estimée à quatre heures prendra en fait 16, eh bien, le temps de marteler des Red Bulls, puis bousculez-vous pour équilibrer les mathématiques fantastiques 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 « coopération des consommateurs » au-dessus du « règlement de l’accord » ? Est-ce « réagir pour modifier » plutôt que « suivre une stratégie » ?
Clairement non. Ce sont des histoires comme des mini-cascades, chacune traitant l’ingénieur comme un rouage de la machine de son entreprise. Des histoires comme des commandes entièrement définies pour des portions de code, sans aucune compréhension de l’artisanat, de l’imagination 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 technique descendante et linéaire qui ne donne pas aux ingénieurs logiciels l’autonomie, l’accès et l’autorité pour piloter l’exécution de ce que le groupe de produits demande.
Il n’y a pas de place pour de vraies conversations et une vraie collaboration. Pas de place pour que de meilleurs concepts émergent, ou pour que quiconque change d’avis.
Scrumfall s’appuie, pour le dire simplement, sur le groupe de produits (composé d’humains) offrant une spécification totale et optimale avant le début du développement . Et cela repose sur le groupe d’avancement (comme les êtres humains) qui planifie une exécution totale et idéale avant qu’une seule ligne de code ne soit écrite.
Pas même le Dr Winston W. Royce, qui a composé l’article fondateur sur ce que nous appelons maintenant Waterfall, croyait que c’était possible. « Je pense que dans ce concept », a-t-il composé, « mais la mise en œuvre expliquée ci-dessus est risquée et accueille l’échec. »
Lorsque les défauts inévitables de spécification et d’application émergent plus tard, Royce a composé, « Le style nécessaire change sont plus susceptibles d’être si perturbateurs que les exigences logicielles sur lesquelles le style est basé et qui offrent la justification de tout ce qui est cassé. »
Il n’est pas surprenant que nous ayons besoin d’une méthode différente.
Scrumfall peut-il fonctionner ? Bien sûr, dans les cas les moins importants. Besoin d’une page de connexion de base ? Nous pouvons spécifier, approximer et exécuter cela de manière rapide sans beaucoup de partenariat continu.
Mais malgré tous les obstacles vraiment intrigants, importants, voire révolutionnaires du génie logiciel, le travail qui est complexe et non déterministe– nous avons besoin d’êtres humains, collaborant à des méthodes significatives pour créer ensemble de meilleurs services.
L’impact papillon engendre des bugs
La coopération introduit inévitablement imprévisibilité dans la procédure. (Et les envahisseurs Waterfall cachés dans le cheval de Troie de Scrum n’aiment pas l’incertitude.) L’imprévisibilité n’est pas un bogue mais une caractéristique d’Agile, qui identifie que de bien meilleures solutions ne peuvent émerger que si la procédure accueille les non-identifiés et protège l’autorité des individus à modifier leur esprit.
L’ensemble du domaine de l’ingénierie des applications logicielles est si jeune, à peine plus de 50 ans, et évolue si rapidement. Comparez cela aux millénaires d’avancées, d’améliorations et de normalisations du génie civil. Une grande partie de ce que nous faisons est nouveau, une expédition vers l’inconnu.
L’application logicielle est également beaucoup plus compliquée. Bien que le nombre brut de lignes de code ne soit qu’une mesure non raffinée de la complexité, pensez que même une application iPhone de base contient généralement 40 000 lignes de code, avec un logiciel plus substantiel dépassant généralement d’innombrables lignes de code. La base de code de Google est estimée à 2 milliards de lignes de code, ce qui équivaut aux 3,3 milliards du génome humain.
Lorsque vous considérez toutes les interactions entre ces lignes de code, vous entrez sur le territoire de la théorie de l’agitation, en créant des logiciels application impacts papillon hautement conscients : à des répercussions totalement inattendues.
En d’autres termes, nous gérons une procédure naturellement non déterministe. Séparer, isoler et restreindre les individus ne résoudra jamais l’incertitude. La mise en œuvre du respect de délais arbitraires et de stratégies rigides n’engendrera pas de résultats déterministes.
Au lieu de cela, ces chaînes de mini cascades créent le chaos, un mauvais code et, paradoxalement, des dépassements de dépenses et des délais manqués. Le succès à long terme est sacrifié à l’importance à court terme de Scrumfall de satisfaire des mesures arbitraires. C’est aussi une voie sûre pour stresser les ingénieurs, qui partiront rapidement pour d’autres opportunités avec une satisfaction et une durabilité plus complètes, moins d’agitation.
La chute de Scrumfall ouvre le véritable pouvoir d’Agile
Agile reste une très bonne idée qui fait passer la valeur des individus avant celle des procédures. Sa restructuration radicale du cycle de vie de l’avancement des applications logicielles continuera de transformer notre domaine et de produire des solutions exceptionnelles.
Mais pour libérer le véritable pouvoir d’Agile, nous devons accepter pleinement la complexité non déterministe du sens problèmes que nous résolvons. Il y a beaucoup de choses que nous ne comprenons 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 méthode pour un bon service. Vous avez juste besoin de leur faire confiance avec la flexibilité de résoudre les choses comme ils pensent le mieux.
Il y aura des mauvais tournants tout au long de la méthode. Les individus changeront d’avis ou verront une bien meilleure solution. Certaines histoires prendront plus de temps que prévu. (Et certains peuvent prendre moins de temps.) Vous devrez peut-être modifier votre chronologie, reconsidérer votre MVP ou redéfinir vos priorités.
Agile considère 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 limiter toute cette incertitude, Agile l’accueille comme l’essence même de la production.
Il y a un équilibre à maintenir, naturellement. Agile ne peut pas être l’anarchie des développeurs qui ne produit jamais un produit fini. Scrum (ou Kanban) mis en œuvre de manière appropriée permet à l’équipe de rester alignée sur ce qui est requis et sur ce qui conduira raisonnablement au résultat préféré dans un délai et un budget limités.
Mais nous devons arrêter de détériorer le pouvoir d’Agile en déterminant fanatiquement la vanité systèmes de travail plutôt que la valeur de ce qui est fourni.
Pour réaliser le véritable potentiel 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 cohérents de Waterfall qui se cachent à l’intérieur Scrumfall.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
