"Agile est mort." Les gens disent ça tout le temps. Mais ils ajoutent nécessairement: "Nous plaisantons." Ils signifiaient en quelque sorte que
vous aviez des pratiques si mauvaises et stupides qu'Agile est morte pour
vous . Mais le «vrai» Agile n'est pas mort. C'est juste que tout le monde le fait mal. Alors j'ai réalisé: le vrai Agile est, vous savez, Agile
en théorie . Même moi, je l'ai implémenté. Et tu sais quoi? J'en ai marre.
Récemment, j'ai vu la même vieille défense dans mes articles: "Mais-mais-mais, le problème est la cascade, la mêlée et la mauvaise mise en œuvre d'Agile, le non-respect du Manifeste ... bla bla bla." Ensuite, Bob Marshall m'a dit la vérité. Il a dit: «Tais-toi, Charles. Le manifeste Agile est la cruche que nous remplissons. » Il a fait quelques commentaires avec lesquels je devais être d'accord. J'y ai pensé. Le résultat a été cet article.
Voici un test pour vous. Comment commence la première ligne d'un manifeste Agile? Ne regardez pas. Je ne sais pas? Tout va bien. Peu importe. Il dit: «Nous découvrons des méthodes de développement logiciel plus avancées ...» Arrêtez. Remarquez, il est écrit: "développement de logiciels". Il ne dit pas: «tirer votre organisation», «rembourser la dette pour la transformation», «la couper avec cette merde de commandement et de contrôle», «se concentrer sur les résultats et améliorer le travail d'ouverture», «réparer votre système budgétaire médiéval», ou quoi que ce soit valeur ajoutée plus avancée que les gens ont essayé d'y investir. Mais le fait est que lorsque les gens disent qu'Agile fait référence à toute l'organisation, c'est du révisionnisme. Ce n'est pas juste.
Remarquez aussi qu'il commence "Nous
découvrons ..." Il ne dit pas: "Nous avons reçu d'en haut ..." Ne pensez-vous pas que nous avons appris quelque chose de 2001? Je veux dire, oui, la plupart des grandes organisations sont toujours bloquées en 1987, mais d'accord, vous. Contrairement à la croyance populaire, la photo ci-dessous n'est pas vraiment de l'acte de signature du manifeste. Pouvons-nous enfin arrêter de faire semblant?
Le manifeste a servi un but précis, mais il ne vous mènera pas là où vous en avez besoin. Alors commencez vos études. Nos connaissances ont une date d'expiration, et pas aussi longtemps que nous le pensons. Tout le monde a des collègues (généralement des patrons) qui prétendent qu'ils "n'ont pas le temps d'apprendre". Vous savez vous-même qu'ils sont trop confiants en leurs connaissances. Alors, trouvez une bonne liste de livres. Tenez-vous avec de bons blogs. Voici un début: si vous n'avez pas lu
Sense & Respond ,
Lean Enterprise ,
A Seat at the Table et
Everyone Is a Change Agent , je vous suggère de le faire immédiatement. Et à vos supérieurs.
Commencez à lire les articles de John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica Hall, Neil Killick et ceux auxquels ils se réfèrent. Sont-ils tous d'accord entre eux (ou avec moi)? Non, mais ils sont intelligents et ils vous rendront également plus intelligent. Commencez à lire et encouragez les autres. Fast Company dit que le PDG moyen lit 60 livres par an. Combien de livres vos chefs lisent-ils? Et que lisent-ils? (Les articles HBR, les rapports Gartner et les romans Maeve Binchi ne comptent pas). Car avouons-le: si vos leaders sont des Scrum Masters, alors vous êtes fermement coincé dans les années 80 et 90.
Passons à l'apprentissage continu et arrêtons de prétendre que l'Agile est une sorte de remède. Il faut dire:
Agile est et a toujours été une optimisation locale pour une légère augmentation de l'efficacité du système . Seul Agile a injustement placé sous le microscope une équipe de développeurs de logiciels. Cela n'augmente pas la flexibilité organisationnelle. Non. Fait intéressant, selon Ken Schwaber (voir son «dangereux à toute vitesse»), Agile était une tentative de «compenser les dommages causés par la cascade», mais il n'a jamais donné aux organisations une alternative holistique et viable à la cascade. Parce qu'il y a une différence entre la théorie et la pratique. Travailler sur un produit est plus une pratique. Lorsque nous nous plaignons d'AINO (Agile In Name Only), nous ne sommes pas honnêtes avec nous-mêmes.
Théorie contre pratique, tu te souviens? Nous devons être pragmatiques. Agile dans la pratique est presque toujours AINO. Cela semble être un problème avec le mouvement lui-même, non? Dans tous les cas, il y a des choses plus importantes à apprendre, y compris (mais sans s'y limiter) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, Marshall Organizational Therapy, etc.
Vous pouvez vous demander pourquoi Lean UX est en tête de liste? En raison du fait que,
dans son essence, Lean UX popularise le concept d'orientation des résultats. Pensez: si vous ne savez pas quel type de changement de comportement vous essayez de créer, alors vous ne comprendrez pas vos actions. Si vous ne disposez pas d'un signal de pivot clair, vous ne pouvez plus être flexible. C'est ce qu'est Agile, après tout, pivote. Certains peuvent objecter: "Non-non-non, vérifiez et adaptez!" Bien sûr. Théorie contre pratique, tu te souviens? Je ne vois pas d'équipes flexibles qui testent et s'adaptent. Je vois des équipes Agiles essayer de rattraper leur retard, jouer avec Jira et Rally et travailler comme si elles construisaient un mur de briques sur ordre.
Agile tend en fait à masquer le problème principal - il s'agit d'un manque systémique et bidirectionnel de confiance verticale. Les Agile Coachis partent, aggravant la situation: ils laissent derrière eux des managers parlant le cochon et une équipe de développement passée à l'espéranto. Les équipes estiment que la gestion est défaillante, et la direction estime que l'accent devrait toujours être mis sur le volume, le calendrier et l'efficacité, ignorant que les délais sont arbitraires et que les estimations de temps sont une
forme de gaspillage . (Savez-vous quelles histoires ont réellement inventé pour
cacher le temps et aider à résoudre le problème lui-même? Il y a eu des conséquences désagréables ici aussi, non? Théorie et pratique).
Devinez qui va gagner? Deux camps avec deux perspectives radicalement différentes, où un camp obtient-il des notes de l'autre? Si les équipes sont comme des aveugles qui ressentent un éléphant et ne sont pas d'accord avec ce que c'est, alors le leadership est comme des éléphants aveugles attaquant les gens et convenant qu'ils sont tous plats. La solution est de reconnaître que le système est
une équipe. Terminez déjà avec des optimisations locales et réalisez que la confiance est le problème numéro 1. Arrêtez de placer injustement les développeurs sous le microscope, permettant aux autres de se cacher dans une boîte noire. (Pourquoi ne sommes-nous pas intéressés par le fonctionnement des équipes de développement stratégique? Ou par quelles contraintes architecturales héritées les systèmes?)
Et pendant ce temps, nous devons cesser de traiter les équipes de développement comme si elles travaillaient dans une usine. Nous ne tamponnons pas les plats en plastique. Nous créons des logiciels. Vous devez cesser d'agir comme si nous
servions une pizzeria . Voici les autres règles. Nous n'utilisons pas la même recette éprouvée. Nous
développons des recettes . Si vous ne l’avez pas encore compris, il s’agit d’un travail d’ouverture, pas seulement de la livraison. La négligence de la découverte entraîne des pertes massives: fonctions inutilisées et autres travaux qui n'aboutissent pas à des résultats. Cela révèle une autre faille profonde d'Agile. Il suggère que les utilisateurs peuvent être considérés comme des cobayes: "Hé, utilisez simplement ce produit de merde, alors nous l'améliorerons." Sauf que le produit merdique reste généralement le même, n'est-ce pas? Les améliorations futures deviennent des «coûts» inutiles.
Mais-mais-mais, Agile est vraiment concentré sur la recherche! Non? Nous serons honnêtes. Théorie contre pratique, tu te souviens? Si vous gagnez votre vie en concevant ou en faisant des recherches, répondez à cette question. Que pensez-vous habituellement de travailler avec des équipes flexibles? Êtes-vous initialement considéré comme une valeur et on vous a demandé d'aider à «tester et à vous adapter»? Ou vous est-il demandé de "prouver votre valeur"? Comme l'a dit Alan Cooper, lorsqu'on vous demande de «prouver votre valeur», vous êtes clairement informé que vous êtes dans un système qui ne vous apprécie pas. Veuillez noter qu'ils demandent à un participant individuel de prouver leur valeur - ils ne demandent pas dans quelle mesure leur code biaise réellement les indicateurs dans la bonne direction. En d'autres termes, ils se concentrent toujours sur les gens,
pas sur le travail lui-même . Ils sont probablement encore concentrés sur les os, pas sur la valeur, ignorant les zones où une partie importante de la valeur s'écoule réellement.
Si vous travaillez avec des équipes flexibles, la prochaine fois que l'on vous demandera de «montrer votre valeur», essayez ceci. Commencez par
leur poser
des questions. Savent-ils quel est le prix du retard? Quels exercices utilisent-ils pour évaluer ce paramètre? Quels résultats spécifiques tentent-ils d'atteindre? Quelle proportion de leur produit atteint réellement ses performances? Ne savent-ils pas? S'il existe des moyens plus rapides et moins chers de découvrir quoi développer, autres que la simple publication du code, sont-ils intéressés à apprendre? Quelle est leur efficacité de flux? À quel point est-ce mauvais? Combien de temps passent-ils en réunion? S'il existe des jeux de créateurs et des actions simplifiées qui mèneront à de meilleures solutions en beaucoup moins de temps, sont-ils intéressés à apprendre? Parce que je ne vais pas seulement vous montrer ma valeur - je vais vous apprendre à créer plus de valeur
dans tout ce que vous faites .
C'est une façon de penser différente. C'est méta. C'est stratégique. Comme le note Austin Gowella, Agile et la cascade se concentrent sur le
développement . Le design est un
test . S'ils ne sont pas intéressés, vous pouvez partir. S'ils baissent simplement la tête pour sortir un produit, en se concentrant sur les coûts, ils n'en sauront même jamais assez pour comprendre que vous obtenez généralement plus que ce sur quoi vous vous concentrez (euh, les os). Il s'agit d'une fabrique de fonctionnalités. Responsabilité mutuelle. Ils prétendent créer des plats en plastique. Vous avez des choses plus importantes à faire. Parce que la valeur réelle est fournie par les options générées par la
recherche . Plus vous créez d'options et plus votre approche est flexible, plus vous avez de chemins possibles et de meilleurs résultats. Qu'essaient-ils de réaliser? Ont-ils exploré trois à cinq façons d'y parvenir? Cela conduira à une meilleure prise de décision pour l'avenir. Une option n'est pas un choix. Deux est un dilemme. Trois - maintenant vous avez accompli quelque chose.
Avez-vous déjà entendu parler de la loi de la diversité nécessaire? Le composant avec le plus d'options
contrôle le système . Appliquez-le à la stupide lutte pour le pouvoir d'Agile contre Waterfall. Vous avez eu des cadres qui ont essayé de garder le contrôle du système par le haut et des équipes flexibles qui ont essayé de rapprocher la valeur de la source (utilisateurs réels et clients). La sortie d'une guerre civile dénuée de sens est d'enseigner aux gens comment générer des options
à tous les niveaux . La voie à suivre n'est pas Agile contre une cascade. Il s'agit d'un travail stratégique intelligent descendant (cascade) avec des tactiques ascendantes orientées empiriquement. Aide à la conception et à la découverte dans les deux cas.
Alors ... quelle est la solution? Il s'agit d'une concentration raisonnable sur des résultats clairs, pas sur la livraison, avec des résultats planifiés au lieu de notes planifiées, pas avec un projet, mais avec des équipes produit fiables autorisées à vérifier les hypothèses et à trouver le chemin le plus court vers la valeur.
Maintenant pour la formation (adapté sur la base du tableau de John Cutler).
Alors ... cela signifie-t-il qu'Agile s'en va? Bien sûr que non. Ceci est juste un article de blog stupide. Je n'ai aucun pouvoir. Et même si c'était le cas, Agile ne disparaîtrait toujours pas.
Le mouvement Agile a rendu possible plusieurs de ces concepts . De plus, contrairement à la croyance populaire, les pratiques agiles n'ont pas été inventées par le mouvement Agile. Ils sont apparus des décennies plus tôt.
Alors non, je ne veux pas qu'Agile s'en aille.
Je veux juste que nous soyons plus honnêtes.