Qu'est-ce que putain de quoi le Programmer Anarchy??

Cela fait maintenant plus de 20 ans que le mouvement “Agile” essaie de changer l’organisation du travail, une poussant un praxis non fordiant, plat ou les opérationels (dev) regagnent son pouvoir d’action. Sans réelle réussite il faut l’avouer.

Depuis un peu plus de 10 ans, des gens ayant démontré de grandes réussites avec des organisation divertes essaient de faire surgir une nouvelle organisation digne du manifeste.

Faisons un petit tour sur Memory Lane avant de faire le point sur ce qu’est le Programmer Anarchy.

Au début était l’XP

J’ai commencé ma carrière en utilisant du XP (Xtreme Programming), méthodologie pensée par Kent Beck, publiée en 1999. On le connaît pour avoir nommé ou niveau en avant plusieurs choses: TDD, user story et pair-programming.

Il mettait surtout en avant le besoin de réduire la chaîne de commandement: Les dev doivent discuter avec le Client et les Utilisateurs. C’est à eux de penser le système (réutilisant de l’idée de l’Orienté Objet d’avoir une modélisation du monde réel). Pour ce faire, on crée un modèle à base d’User Story dont le but est de pouvoir discuter et penser le système.

Ensuite l’idée principale est d’implémenter en pair-programming, où un dev sera le pilote, écrivant le code, et l’autre sera le copilote, créant les contraintes et comportements. En travaillant par petites étapes, utilisant du TDD pour garantir la conformité du système et la propreté de la codebase. Une fois un comportement complet réalisé, on le présente au client pour avoir un retour et on itére.

XP est une méthode surtout de production, on n’y parle pas de gestion de projet, de manager ou autre masters. Non, les dev s’organisent. Comment? Pas le problème. Comme on peux suivre qu’ils taffent? Bah, ils font des previews et ça avance toutes les semaines…

C’était mon plus gros choc, et mon premier amour en “organisation du travail”. XP4ever…

2001 sort alors le Manifeste pour le développement agile de logiciels.

L’arrivée de Scrum

Pendant ce temps, c’était un peu l’ébulition dans la partie organisation. On était en plein boom de Lean/Sigma Six, le livre Lean est sortie en 1996. D’autres, presque uniquement Japonais prenais plutot le Toyota Production System (qui est au Lean, ce que la Pizza Napolitaine est à la Pizza Havaïenne).

Ainsi on voit sortir des livres voulant partir de ses “nouvelles méthodes”, mais appliqués à la production de logiciel profesionnelle. Qui devient une vrai industrie: la majorité des softs sont fait des équipes de dizaines, voir centaines de personnes.

Celui qui rentre dans l’histoire est le Scrum (Le Guide Scrum est publié en 2010), par Jeff Sutherlan et Ken Schwaber. Ainsi il se base sur ce qui a été produit avant. Et on met vraiment au centre l’adaptation et la recherche de régularité. On ne met toujours pas en place d’organisation interne. Et l’équipe continue de parler aux clients. Le Product Owner est le client, son rôle n’est pas de dire à l’équipe quoi faire, mais de acter les choix et valider les proposition de l’équipe. Il est un mandataire avec du pouvoir, pas un passe-plat.

L’un des problèmes dans le développement informatiques, est que les phases de conception et production s’enchaines. Il est donc impossible de faire comme en industrie, où une fois la conception faite on peut lancer une production prédictible sur la quelle on travaillera pour réduire le temps de production. A chaque boucle, on peut se tapper une dérive sans la voir et qui ne sera pas relié à l’équipe produsant. Pour gagner de la régularité, on limite la quantité de travail et le temps à réaliser. On espère ainsi réduire le risques de dérive et le temps total de la dérive si elle survient.

On suit la vélocité de l’équipe pour savoir si elle va bien. Dans le cas contraire on intervient pour les aider à débloquer leur situation. Les preview servent à faire valider la valeur aux clients. Chaque équipe gère sa semaine comme elle veut. Le daily sert à s’auto-organiser.

Scrum structure les Product Owner (capable d’acter des choix sur le produit), les Scrum Master (facilitateur sans lien hiérarchique). Ils structure des artefacts comme le Product Backlog et des évenement comme la Daily.

Agile™, Agile is dead and we killed it!

Et ensuite vient ce que les américains savent faire de mieux:

On voit plusieurs méthodologies apparaitres. On va rééditer des Guides. Il faudrait aussi former des gens, et les certifier (tous les 2 ans?)! Là on a un business plan!

Mais praxis organisationelle où chaque équipe a le droit de s’organiser comme elle veut, ça se vend difficilement aux grandes structures qui aiment l’homogénité. Et ils n’achéteront jamais avec trop de changement.

Alors on met en place des managers. On remet une organisation super horizontale, mais avec couches les unes sur les autres!

Et du coup, un artefact ayant pour but de suivre l’avancement, devient une mesure de la performance (Burn-down) et perd sont utilité autre que le thêatre de sécurité pour la direction de l’entreprise. Comment on sait que l’équipe avance? Voici le nombre de tickets qu’elle a traité! Le daily? C’est du reporting. On peut savoir si les équipes travaillent. Leur vélocité? Si elle est trop faible, c’est une mauvaise équipe! C’est quoi trop faible? On, a pas de donnée statique fiable, mais on fera malgré tout un jugement au doigt mouillé! Et si le tout fonctionne pas? C’est pas la méthode c’est les gens… Faut mieux le former! Et on peut vendre les formations pour ça!

On arrive à la fin de la boucle: l’Agile est mort, maintenant tout le monde est Agile™.

Et les valeurs de manifeste:

• Donner du pouvoir aux devs (opérationnels): maintenant il y a des managers qui leur disent quoi faire
• Donner de la valeur aux clients: valeur? On leur donne des features! C’est mieux! Et puis qualifié la valeur c’est chiant, par contre qualifier les tickets, ça on peut faire!
• La collaboration? Colla-quoi? On a backlog à pondre! GO!! GO!!

Ce qui fera dira à Dave Thomas (pragmatic dave): Agile is dead à la GOTO 2015. Il sera accompagné de plusieurs (sauf ceux dont le business dépend directement) parlant de comment on a dévoyé l’esprit de ce changement.

Et on est toujours là. Soit on a une organisation ultra-rigide, qui fait du washing agile des organisation d’avant. Soit l’organisation YOLO et une utilisation des mot sans valeur pour faire passer la pilule.

Mais du coup on fait quoi? On devrait s’étendre et se mettre un sac en papier sur la tête? Une se balade avec nos serviettes partout?

Programmer Anarchy

Fred George, lui pousse une autre manière. Et cela passe par une organisation sans chef: une anarchie! Et, il l’a non seulement implémenté, mais fait avec un grand succès dans différentes entreprises. Je ferai pas sa biographie, mais elle est assez étendu et cool, si on aime le soft.

Mais qu’est ce que putain de quoi que le Programmer Anarchy?? Bis le retour!

Une autre manière de s’organiser. En gardant les valeur du XP et du manifeste, pour dégager tout le décorum. Il part de l’assertion suivant: en tant que dev, nous vivons dans un monde Complexe (selon le Framework Cynefin).

Dans un monde Complexe, il n’y a pas de lien visible entre les causes et les effets. On connait ça bien sous le non “Effet de bords”. Tu sais c’est quand tu change une fonction dans une librairie et que windaube plante maintenant.

Hors dans selon Cynefin, dans un environement complexe il n’y a pas de “Best Practices” ou même de “Good Practices”. Il y a ce que l’on nomme “Emergent practice”. En gros faut se prendre un mur et en suite dire “Merde y avait un mur ici? Merde, bon bah ici faut prendre à gauche”, vala une “Practice” émerge.

Pourtant c’est une organisation fordienne (Simple ou Compliquée) que déploie la plus part des entreprises (et oui on connais tous une boîte qui fait autre chose, mais c’est l’exception pas la normal…). On traque les tâches, pour espérer éviter la divergeance. Et on veut assurer la complétude de la définition au lieu de la valeur ajoutée. Ils organisent les équipes avec des chefs qui vont “s’assurer que le travail est fait”. Pour donner envie aux gens de faire du bon travail. Ils prennent des expert pour leur dire comment résoudre leur problème (et quand ça marche pas, le problème n’est jamais la méthode mais les gens). Ils silotent et éloignent les dev des utilisateurs/clients.

Mais du coup, il fait quoi de différent putain?

Alors dejà, il acte que les “best practices”, c’est pas justes des “practices”. Il remet en questions tous les rôles non opérationnels (tout le monde apporte de la valeur directement). il éclate l’organisation du travail standard, en mettant au centre du systéme les gens et la valeur pour les clients. En faisant confiance que gens aiment être fier de leur travail, et feront de leur mieux lorsque l’organisation donne du sens à leur travail et toutes les informations nécessaires à des choix éclairés.

Mais du coup il change quoi?

La peur de l’échec

On assume que si l’on essaie de faire quelque chose que nous ne savons pas faire, nous allons échouer la première fois. Mais que cet échec, si structurer et critiquer, pourra apporter de la valeur pour réussir la deuxieme ou x-ième fois.

Du coup, pas de peur d’échec. l’échec, en première instance, est recherchée même. Plus vite on échoue, plus vite on apprend pour grandir.

On arrête le Task Management

Desormais la métrique de base est la fonctionnalité. Pas la tâche. Et la réusite n’est pas de finir la fonctionnalité, mais que celle-ci apporte de la valeur au client. Ce qui implique plein de choses (définir ce qu’est la valeur recherchée’, définir comment la qualifier et quantifier, être capable de la monitorée).

Et oui, très peu d’entreprises sont capables de faire ceci en vrai.

Daily

On arrête le reporting, que ceux qui ont déjà lu un export du Jira-like de la boîte qu’il remplit jette la première pierre. Le reporting si c’est pour faire des tableau, fait directement ton tableau automatiquement. Et un KPI c’est jamais une cible, c’est un indicateur pour savoir si on s’approche de la cible ou pas!

Alors on fait quoi dans la daily? S’il y a une daily, on s’organise pour la journée. On dit aux gens ce qu’on va faire, non pas pour leur dire, mais pour s’organiser! Comme ça si on touche une brique que d’autres utilises, on doit en discuter. Si on va casser un brique que d’autres utilisent? On en discute. Si on galère à finir un truc et ça peut mettre en retard quelqu’un d’autre: ON EN DISCUTE! Vous avez compris, c’est un moment d’organisation. Que va-t-on faire pour que tout roule bien; s’il y a un problème on en discute pour le règler.

Vous voila organisés pour la journée! Peut-être même pour la semaine, selon le type de tâche! Pour la suite, le reporting automatique existe, et ils font ça très bien!

Niveau rôles?

On veut simplifier les choses et revenir à la base: redonner du pouvoir aux opérationnels! Leur rendre leur capacité d’agir.

QA et Testeurs

Alors en gros c’est quoi un QA/Testeur? Au mieux un dev spécialisé aux méthodes de qualité et spécialisé sur l’utilisation d’outils de tests. Qu’on bride en leur fermant le périmètre. Du coup… Bah chaque dev réintégre ses fonctions. Comment bien coder sans connaître des méthodes de qualité? On a de très bon softs pour avoir de la conformité automatique (test). Par contre on sait pas quelle surface on doit tester, ni pourquoi. Et bien, on discute et on défini cette surface et processedures à suivre. Et vala, tout dev peut faire du QA.

Mais on test quoi? Comme le dis Oncle Bob: “Tout ce dont tu veux certifier le fonctionnement”. Comment on définie ça? ON DISCUTE!

Pour les outils? On a tous des préférences. Ainsi certains peuvent avoir une spécialité “outils de tests” (qui la plus part du temps sont des outils d’automatisation). Ils peuvent ensuite former le reste des équipes et tada tout le monde fait de la QA.

Du coup les QA? Ils reprennent un poste de Dev, qui va avoir une appétence pour les outils/méthodes/process de tests. Mais Dev avant tout!

Les PM et autres managers

Que font les PM? En vrai, ils remplissent plein de roles différent:

Business analyst: Il discute avec les client pour comprendre leurs problèmes et ensuite pouvoir répondre aux questions des devs. Important: ce n’est pas un expert métier! Juste les devs sont trop con pour comprendre le métier… En plus ils savent pas parler… Et puis ils savent se tenir, on va pas les présenter aux clients!

• Alors ici c’est simple. Si tes dev sont con, ils seront incapables d’implémenter quoi que ce soit de manière efficiente et efficace dans un systeme informatique. Et s’ils savent pas dev, les embauche pas!

• S’ils savent pas communiquer? Comment vont ils communiquer avec le reste de l’équipe? S’ils n’ont pas les compétences de communication de base… pourquoi tu les as recrutés déjà?

• Si tes équipes m’ont pas compris les régles de bases de l’étiquette et la vie en société à plus de 24 ans, soit tu les aides à les comprendre soit… A nouveau pourquoi tu les as recrutés?

Et si le rôle du BA c’est jouer au Téléphone Arabe. Petit spoiler: le message passer mieux sans! Du coup, recrute des équipes qui savent communiquer, qui sont intélligents et qui ont intégrer les regles de bienséance en société. Et plouf, le rôle de BA disparait.

Chef de projet et autres managers: Il joue le rôle de gréffier (prendre des notes, faire des rapports, suivre des dates, être responsable des userStories). Il joue aussi le rôle de Leader (émulation, donner du sens au travail, créer une cohésion). Il est aussi sensé être l’Ambassadeur, il représente l’équipe et transmet leur voix aux autres groupes sans être celui qui fait les choix. Coach/Mentor pour aider à grandir et/ou guider les membre de l’équipe. En tant que concierge il est en charge de répondre aux besoin de l’équipe quand ils ont besoin de matériel ou des softs. Et enfin il peut souvent être une personne avec un complexe Napoléonien.

• Greffier: On a plein d’outils pour automatiser un peu tout ça. Tout le monde devrait prendre notes! Et pour suivre les Stories: à nouveau des outils. Et ça représente pas un taff à temps plein.

• Leader: Dois-je vraiment expliquer pourquoi la plus part des manager ne joue pas vraiment le rôle de Leader? Serieux?

• Ambassadeur: Quand est-ce que vous avez eu un manager ou PM qui négocie sans vous vendre? La dernière fois qu’ils n’ont pas fait un choix que vous devez assumer?

• Coach/mentor: Rare sont les managers avec de vrai compétences pour cela. Et encore plus rare sont ceux qui ont du temps pour cela en plus de tout le reste.

• Concierge: Aujourd’hui c’est une part très forte parmi les rôles de manager. ëtre au services des équipes. Mais a-t-on vraiment besoin de quelqu’un pour ça? Payé aussi cher?

• Personne avec un complexe Napoléonien: Il aime donner des ordres. Et si ça plante? C’est de la faute des autres! Et on le veut pourquoi?

Vous connaissez je suis sur des gens qui sont capables, voir apprécient, faire le greffier. Et les parties de notes on les réparties dans la team. Vous connaissez des dev, qui savent être de bon Ambassadeurs, et ils pourront continuer d’être dev. Il y a plein de dev qui aiment coacher et mentorer, donnez leur du temps pour ça! La conciergerie? Mettez de la doc, et des outils/procedures pour rendre les gens autonomes sur ça.

Pour la partie Napoléon, pas besoin de remplacer en interne! Et tout le monde devrait vouloir jouer ce rôle à l’externe.

Et vala plus de manager et chef de projets.

Dev

C’est le centre des équipes sur le développement. C’est à eux qu’on va redonner le pouvoir. On les organise et au lieux de les siloter, on leur permettre de s’organise sur les besoins business. Et leur donner les outils pour autre autonomes.

Experts métier

Au lieu d’avoir des mandataires d’expert métier, on va chercher des experts métier directement. Et en interne il faut s’assurer qu’ils aient le pouvoir de faire des choix ou des méthodes pour pouvoir rapidement faire émerger un choix métier qui sera acter et ne bougera pas pendant quelques mois.

Et le reste?

C’est tout. Rien d’autre n’est obligatoire.

Ce qui veut pas dire que rien d’autre n’est nécessaire. Juste que rien d’autre n’est obligatoire. Le reste: faut en discuter et le définir.

Le TDD? Tout et rien est du TDD. Mais que veut on en tirer? Et comment ça apporte de la valeur ajoutée? Procedures de conformité? Si elle rapporte de la valeur ajoutée, il faut la définir. Sinon, on oublie. Backlog pléthorique? Non, on la gérer, néttoie, purge et on met les procedure si elle existe. Comment on traite les feedback? A vous de voir? Le pair-programming? Pas obligatoire!

En gros, tout le reste du gras n’est pas nécéssaire en soit. Mais un besoin spécifique relié à notre contexte. Du coup, faut connaitre et définir bien votre contexte et ajouter les pratiques nécessaires.

Et c’est ça l’avenir de l’Agilité? Sérieux?

Alors oui et non. Mais plus surement non.

Le Manifeste, pousse une idéologie très anarchiste (non, anarchie n’est pas chaos et c’est pas non plus du communisme). Ce qui est assez dingue, surtout quand le manifeste est signée par des mecs très capitalistes!

On y parle beaucoup d’auto-organisation. De remise en question des règles/procédures si elles n’apportent pas de valeur. On y parle de beaucoup de communication pour trouver un concensus. Et enfin d’avoir un groupe fortement investie dans la direction et les choix fait par l’organisation. Et voulant participer à tout cela.

Si vous lisez de la litterature Anarchiste, vous y retrouver pas mal de choses.

Tout un tas d’ideaux qu’on ne retrouve presque jamais dans l’implémentation de l’Agile™. Celui-ci est fait pour pouvoir être achetable et utilisable par toutes les organisations. Comment tout changer sans rien changer!

Le Programmer Anachy, prend une possition extrême en poussant son praxis des valeurs du Manifeste à son paroxisme!

Ce qui le rend presque impossible à implémenter dans la majorité des entreprises, simplement et rapidement. le changement sera long et pénible! Ce qui ne veut pas dire qu’il ne serait pas bénéfique sur le long terme. Mais difficile de croire que beaucoup d’entreprises prendront ce risque.

Et malgré tout, quand on voit les résultat que Fred a réussit à avoir avec sa method chez Forward Technology et par la suite est assez dingue. Mais je crains que cela présuppose un fort pourcentage de profiles senior (en technicité et expérience) parmi les équipes et une forte appétence pour le leadership et la liberté parmis celles-ci. Ainsi qu’une forte envie de la direction de les laisser faire pourvue que les résultat soient bénéfiques.

Par contre, je pense vraiment que cela pourrait conduire à un Nivarva pour Tech! La vrai question étant de savoir si nous pourrons l’atteindre.

See ya space-cowboy!