Il y a beaucoup de jérémiades actuellement autour du sujet d’imposer les pratiques et les méthodes ‘Agile’. Ces geignards ne savent tout simplement pas comment l’imposer correctement. Moi non plus, mais voici ce que j’essaierais de faire.

Si, pour mes péchés, j’étais condamné à être « en charge » d’une organisation de développement logiciels, et d’une manière ou d’une autre, tenu pour responsable de son succès ou de son échec, je voudrais à coup sûr que cette organisation mette en pratique « le développement agile de logiciels », quoi que cela puisse être. J’aurais le pressentiment que ce serait là ma seule chance.

Étant donné que ma survie serait en jeu, devenir « Agile » deviendrait une nécessité. Bien sûr, j’irais suggérer ça à tout le monde, je ferais former tout le monde, j’essaierais de mener tout le monde sur cette voie. Toutefois, ma survie étant en jeu, s’ils ne voulaient pas aller vers l’Agile, eh bien, je n’aurais pas le choix, je devrais faire le nécessaire pour les faire aller vers l’Agile.

Bien sûr, ce serait mal. Je n’aime pas suivre les ordres, par conséquent ma règle personnelle est de ne jamais donner d’ordres. Jetez donc un œil sur le « Voile d’ignorance »1 à vos moments perdus pantagruéliques. Regardez-le plus tard, pour l’instant, nous avons du boulot à faire. S’ils ne veulent pas faire de l’Agile, je dois l’imposer.

Comment puis-je imposer l’Agile et apaiser ma conscience, admettons-le, quelque peu mollassonne en même temps ? Et quelle est la meilleure méthode Agile à imposer ? Est-ce qu’il serait mieux d’en imposer une vraiment simple, comme Scrum, ou d’y aller à fond et d’imposant quelque chose de vraiment exhaustif comme SAFe ? Il s’agit là de questions importantes.

Ma réponse est « non ». Voici ce que je ferais. J’ai écrit ce texte comme si j’étais en train de faire une présentation, avec des questions venant du public. Si vous avez des commentaires ou des questions, j’adorerais que vous me les envoyiez par mél, ou sur le Slack Agile Mentoring, ou même sur Twitter. Sur Twitter, cela risque d’être un peu confus. Il est plus probable que la discussion sera plus aisée sur Agile Mentoring. Toutefois, c’est vous qui voyez.

Comment allons-nous construire du logiciel ici à XYZ

Bonjour tout le monde ! Abordons le sujet de comment nous allons construire du logiciel ici chez XYZ.

TL-PL, nous allons tout construire avec de petites équipes. Par petite, je veux dire, le plus souvent, moins de dix personnes, avec toutes les compétences nécessaires pour construire ce que nous avons à construire. Cela inclura les experts du domaine, les experts métiers, ainsi que les développeurs. Dans certains cas, une équipe pourrait avoir besoin de se reposer sur une fonction support, tel que le juridique ou le financier, mais l’idée générale est que chaque équipe aura facilement accès à toutes les connaissances et les compétences nécessaires pour construire le produit.

Et si … il n’y avait personne de disponible avec une compétence importante ?

Trois choses me viennent à l’esprit. La première, nous construirons nos équipes par ordre de priorité, et s’il nous manque une compétence importante, ce sera une indication-clé comme quoi nous avons trop de choses à faire. La deuxième, je suis très intéressé par aider les gens à apprendre de nouvelles choses, et un manque de compétences sera un signal comme quoi nous devons faire quelque chose à cet endroit précis. La troisième, si l’effort semble vraiment important, nous pourrions embaucher du personnel pour cela. Ce que nous essaierons d’éviter à tout prix c’est d’éviter de répartir les gens sur plein de tâches/initiatives/efforts différents. Ce n’est pas bon ni pour les personnes ni pour les tâches.

Qu’en est-il pour de petits efforts en continu, est-ce que chacun d’entre eux aura une équipe dédiée ?

La plupart des petites maintenances sera associée avec un produit, et cette équipe produit fera tout le petit boulot. Il est possible que nous aurons certains types de petites choses en continu qui ne seront pas associées avec un produit. Je n’ai pas une opinion tranchée sur comment cela devrait être fait, et je laisserai cela volontiers à la personne qui aura en charge la responsabilité du produit. L’idée principale sera de se focaliser sur les choses importantes et de fluidifier le travail autant que possible. Nous discuterons des éléments de petites tailles mais importants lorsqu’ils arriveront, et nous essayerons de trouver ce qui est le mieux.

Qu’en est-il des gros produits, de ceux qui ont besoin d’avoir plus d’une équipe ?

Quelques fois, nous pourrions partitionner le produit. Nous pourrions scinder le processus de crédit et de débit de la fonctionnalité de comptabilisation de notre logiciel de comptabilité personnelle. Puis nous pourrions avoir une équipe pour chacun des deux. Ou nous pourrions considérer un autre produit à intégrer et y affecter deux équipes. Pour cela, je me repose sur le fait d’être guidé par vous, les personnes qui travaillent dessus et par le besoin.

Et si … nous avons vraiment besoin d’une seule grosse équipe ?

Mon opinion est que les équipes perdent de l’efficacité au fur et à mesure qu’elles grossissent. Donc nous travaillerons dans l’objectif de rester petit et de scinder dès que cela commencera à être trop gros. Nous serons guidés par l’expérience et la situation, et regarderons ce qui est le mieux pour les gens, le produit et l’organisation, à peu près dans cet ordre-là. Peut être qu’il y a quelque chose qui nécessite une grosse équipe, mais franchement je pense que ce n’est pas le cas , et nous y travaillerons pour l’éviter.

Qu’est-ce que ces équipes feront ?

Comme la plus grande majorité des entreprises du secteur, nous aurons généralement une seule activité - et une équipe produit focalisée avec l’autorité et la responsabilité de construire l’un (ou plusieurs) de nos produits. En travaillant avec de vrais clients et utilisateurs, chaque équipe déterminera les besoins des utilisateurs et les solutions, et les construira. Ils auront une vision générale du produit que nous pourrons tous comprendre, et nous passerons en revue le vrai logiciel très fréquemment, en examinant ce qu’il est, à quel point fonctionne t’il bien, à quel point satisfait-il les utilisateurs. Nous discuterons ensuite qu’est-ce que l’équipe devrait faire ensuite, et l’équipe décidera quoi faire et le fera.

Comment les décisions seront-elles prises ?

En simplifiant au maximum, nous avons deux axes principaux auxquels s’intéresser, la réussite du produit à satisfaire nos utilisateurs, et la pléthore de détails techniques pour la conception et la réalisation des solutions qui vont satisfaire les besoins des utilisateurs. Il y a ici une division assez claire, du moins dans mon esprit, entre les activités en relation avec le client et ce que j’appellerai les activités techniques. Pour l’instant, cela reflète nos organisations Produit et Marketing d’un côté et de l’autre notre organisation Développement.

Toutefois, ce qui est demandé et comment le faire sont entremêlés, et franchement, j’aimerais voir ces séparations supprimées où que ce soit. Prenons par exemple un produit avec une seule équipe pour faire simple. J’aimerais créer une nouvelle équipe, avec des personnes du Produit et du Développement, dédiées à ce produit. Leurs missions conjuguées sont de créer un retour viable pour ce produit.

Oui, mais comment décident-ils quoi faire ?

J’y arrivais. S’il est question de donner une décision difficile sur cette chose que le produit est capable de faire ou sur autre chose, j’aurais tendance à dire que cette décision appartient à la personne du Produit. Dans mon esprit, j’appelle ce type de personne le Product Champion. Toutefois, si cela arrive jusqu’au point que c’est au Product Champion de prendre cette décision, je considèrerais cela un peu comme un échec. Leur boulot c’est d’avoir l’expertise et une compréhension suffisante des choses pour mener l’équipe, non la commander. Et ils devraient être en capacité d’instaurer cette compréhension chez l’équipe aussi. Je préfèrerais de beaucoup voir apparaître des décisions par consensus ou du moins des décisions par consentement, plutôt que de manière autoritaire.

N’est-ce pas un peu idéaliste ?

Oui, ça l’est probablement. Et c’est ce que nous allons apprendre à faire, parce que nous sommes tous ensemble plus intelligents et plus forts qu’isolément. Mais il y a encore bien plus. Parlons du cycle de développement.

Nous sommes dans le business de satisfaire les besoins utilisateurs grâce à des logiciels. C’est le boulot de l’informatique, bien sûr, que de servir les désidératas et les besoins de nos clients. Puisque c’est le logiciel qui nous intéresse, c’est là dessus que nous mettrons l’accent de notre management et la focalisation de nos efforts. Nous nous focaliserons sur le produit : sur ce qu’il est, comment il évolue, comment il est accepté. La manière dont nous faisons cela sera différente de la manière dont certains d’entre vous sont habitués à le faire. Certains autres dans l’organisation reconnaîtront ces idées, parce qu’ils les pratiquent déjà ou sont sur la bonne route.

La règle est la suivante : Chaque équipe produit sera responsable par avoir un produit prêt-à-être-livré, opérationnel, testé à tout moment, et contenant toutes les solutions que l’équipe aura choisie pour être incorporées dans le produit.

Toutes les deux semaines, votre équipe et les parties prenantes, y compris moi, se réuniront ensemble et passeront en revue le produit. Vous attirerez notre attention en particulier sur les nouvelles fonctionnalités et les changements intervenus. Nous discuterons du marché, des besoins du client, des prochaines étapes potentielles et nous ferons bon usage de cette discussion pour vous donner de l’information au sujet de vos futures décisions. En fonction de ces retours d’informations, vous déciderez quoi faire ensuite, vous le ferez, et l’incorporerez dans le produit et nous nous verrons à nouveau deux semaines plus tard.

Attendez un peu ! Nous sommes supposés mettre une nouvelle version à disposition dans tout juste deux semaines ?

Oui. Il s’agit peut-être de la partie la plus difficile quant à la manière dont nous allons faire les choses. Certains de nos produits actuels tiennent à peine sur leurs pieds. Certains, et tout spécialement avec certains de nos produits les plus anciens, tout semble durer une éternité et nous pouvons à peine livrer une version tous les six mois et encore. Donc cela veut dire que nos réunions toutes les deux semaines vont plutôt être ennuyeuses. Je vais demander à voir le produit, l’équipe Monolithe va me montrer la même vieille version , je vais demander ce qu’il y a de nouveau, ils diront qu’il n’y a rien de nouveau. Je vais avoir l’air triste. Ils essaieront de me dire ce « ouais … mais » il y a aura vraiment des choses sympas dans la Prochaine Version. Je vais demander si cela est opérationnel, si c’est intégré, si c’est testé, si cela fonctionne, prêt à être livré dans la version en face de moi. Ils diront non, et je dirai alors ne m’en parlez pas, je suis uniquement intéressé par ce qui peut être mis dans les mains du client dès maintenant.

Je pourrais même être un vrai enfoiré là-dessus et réaliser un tableau de bord ou quelques graphiques, qui montre d’autres produits ayant, eux, ajouté des fonctionnalités toutes les deux semaines, et montrer le gros monolithe qui ne grossit pas pendant des mois, l’équipe Monolithe à coup sûr va être embarrassé.

Mains nous ne pouvons pas faire ça ! Nous ne pouvons pas ajouter de nouvelles choses toutes les deux semaines

Si l’équipe ne sait pas comment construire une version toutes les deux semaines avec au moins une nouvelle chose dedans, nous leur donnerons toute l’aide dont ils ont besoin pour apprendre à le faire. Mon expérience suggère que la plupart du temps, ils savent ce dont ils ont besoin, la plupart d’entre eux ont besoin d’un peu plus de temps pour rentrer dans ce mode. Mais peu importe le travail que cela demande, je suis sûr qu’ils vont arriver à trouver la solution, parce que l’équipe Monolithe coûte assez cher, et que l’entreprise mérite de voir ce dont ils sont capables et d’obtenir les bénéfices de leur travail avant que six mois s’écoulent.

Je suis très impliqué sur ce type de sujet. Je fais ce type de boulot depuis longtemps, et chaque fois, j’ai constaté que l’équipe trouve comment livrer de nouvelles choses de valeur toutes les deux semaines. Il y a peut-être des exceptions, et s’il y en a vraiment une, nous nous en occuperons. Mais nous allons prendre comme hypothèse que chaque équipe est capable de produire un incrément de logiciel toutes les deux semaines, et nous allons investir peu importe ce qu’il faut pour que cela arrive.

Maintenant laissez-moi poser une question à mon tour, afin que personne dans la pièce ne se sente obligé de montrer trop sa tête. « Ron, c’est comme si vous étiez en train d’essayer de nous faire avaler contre notre gré une espèce de processus agile. Et si nous ne voulons pas le faire ? »

Bonne question, Ron. Mais le fait est que je n’ai pas l’intention de vous faire avaler quoi que ce soit contre votre gré. Je me moque de la manière dont vous construisez le logiciel, enfin pas trop. J’ai beaucoup d’expérience, et certaines idées pas mauvaises sur les manières d’y arriver, et je ferai en sorte que des experts se rendent disponibles pour vous aider à faire ce qui doit être fait pour y arriver. Mais je ne vous dis absolument pas quel processus vous devez utiliser.

Ce que je suis en train de dire c’est que nous - tous autant que nous sommes - nous allons mesurer les équipes produits sur la base de leur capacité à livrer au sens littéral de la valeur toutes les deux semaines. Dans la mesure où une équipe peut faire cela, elle aura l’air bien, et dans la mesure où une équipe ne peut pas faire cela, elle n’aura pas l’air aussi bien. Et nous allons investir tout ce qu’il faut afin que cela soit possible pour chaque équipe, qu’elles soient en capacité de sembler bien sur cette mesure précise. Avec certains équipes, cela peut prendre un certain temps. Au fur et à mesure qu’elles s’améliorent pour y arriver, elles sembleront meilleures. Une fois par trimestre c’est mieux que deux fois par an. Une fois par mois c’est encore mieux, et cela se rapproche de toutes les deux semaines. J’ai des raisons de croire que nous pouvons y arriver et je me suis engagé à offrir tout ce qui est nécessaire pour faire en sorte que que cela se produise.

La ligne rouge est que nous n’allons pas imposer un processus à quiconque, même si nous allons vous aider à améliorer votre processus si vous avez besoin d’aide et si vous voulez de l’aide. Ce que nous faisons c’est de donner une contrainte favorable sur ce que vous produisez, non pas sur comment vous allez le faire. Parlons donc du pourquoi.

Que nous soyons clair, je veux réussir et je veux que nous tous, nous réussissions, et je veux que l’organisation réussisse. Nous ferons cela en offrant des solutions à nos clients, des solutions dont ils ont besoin, qu’ils apprécient, qu’il seront prêt à payer pour les avoir. Leurs besoins changent, notre compréhension sur ce qui souhaité et sur comment le faire change.

Si nous pouvons simplement offrir quelque chose de nouveau ayant de la valeur à nos clients tous les six mois, ils en bénéficieront lentement, nous en bénéficieront lentement, et le pire dans tout cela, nous apprendrons lentement. Cela nous met tous en risque. Nous devons accélérer notre cycle d’apprentissage et notre cycle de livraison de valeur. Le fondement même de faire ça, c’est d’offrir des incréments visibles ayant de la valeur, que nous pouvons voir, dont nous pouvons parler, dont nous pouvons apprendre et fournir à nos clients.

Parfois, faire cela, sera facile. Parfois, ce sera plus difficile, mais nous travaillerons et apprendrons à comment le faire plus facilement. Nous y travaillerons ensemble et nous en bénéficierons tous ensemble.

Est-ce que cela ne va pas nous mettre sous une pression incroyable ?

Mon intention n’est pas d’augmenter la pression, mais de la réduire. Je ne crois pas que la pression nous aide à mieux travailler, mais qu’elle est plus susceptible de nous causer des problèmes et de faire ralentir les choses. Il y aura de l’apprentissage à faire, beaucoup d’apprentissage, et quelques fois l’apprentissage peut se faire dans la douleur - wow est-ce que je connais ça - mais nous essayerons de faire en sorte que la douleur et la pression soit la plus faible possible. Et j’ai trouvé que travailler de la façon dont je demande peut être amusante, et j’espère sincèrement faire en sorte que cela soit le plus plaisant possible pour tout le monde.

Pour avoir le temps d’apprendre, les gens ont besoin qu’ont leurs fichent un peu la paix. Je suis bien conscient de cela et je m’engage à ce que cela soit possible. Je m’attends à ce que nous travaillons tous durement, mais nous n’essaierons pas de faire tenir cinq kilos de boulot dans un sac de deux kilos cinq. Nous trouverons un équilibre subtil entre avancée et apprentissage. Si vous trouvez que vous ou votre équipe, êtes en déséquilibre, je veux l’entendre et je travaillerai de telle sorte à ce que cela soit corrigé.

Nous pouvons avoir des urgences et nous alors devoir pousser un peu dans ces cas là. Mais chaque jour n’est pas une urgence, et nous investirons pour que ce genre de choses soit réduit au minimum.

Qu’en est-il du planning à long terme ?

J’attends de chaque équipe d’avoir une vue cohérente de la situation actuelle dans laquelle elle pense se trouver. Nous pouvons appeler cela un plan d’actions si vous voulez.

Votre plan devrait être exprimé en terme de besoins de vos clients ou de vos utilisateurs, et des solutions que vous planifiez d’offrir. Cela devrait me dire suffisamment de choses pour avoir une bonne idée du besoin et des solutions que vous envisagez. Nous travaillerons ensemble pour améliorer la communication.

Toutefois - et c’est très important - nous n’allons pas vous évaluer sur le suivi de votre plan. Nous allons nous mesurer sur la manière dont nous satisfaisons réellement nos clients. Une partie de votre travail est - en continu - de comprendre ce que veulent et ce dont ont besoin vos clients, de leur offrir des solutions à ce qu’ils veulent et à ce dont ils ont besoin, et d’être au meilleur niveau sur comment satisfaire vos clients avec ce que vous êtes en train de leur offrir.

La manière dont j’envisage cela est que chaque équipe ait une vue de ce qui l’entoure, et de là où elle veut aller ensuite. Chaque fois que quelque chose de nouveau est construit et déployé, l’équipe est à un nouvel endroit et a désormais une vue nouvelle, différente et plus complète des choses. J’attends de votre équipe d’avoir ce type de vue, de la garder à jour, et de la communiquer à vos parties prenantes.

À quoi devrait ressembler cette vue ?

Honnêtement, je ne pense pas que nous nous soucions vraiment de savoir à quoi cette vue doit ressembler. Je ne préfère pas avoir à subir une heure de visionnage de diapositives PowerPoint, donc je ne vais pas vous conseiller ça. Mais si c’est la meilleure manière de communiquer votre vision des choses, j’essayerai de faire avec. C’est à votre équipe de gérer le problème de créer et de communiquer la vision, et cela inclut de trouver de la part des parties prenantes comment et à quel degré votre vision peut leur convenir.

Je suis certain que nous trouverons des manières appropriées pour présenter la vision, et j’espère que le Grand Opéra ne sera pas l’un d’entre eux. Ce serait encore pire que PowerPoint.

En résumé, nous allons créer des équipes focalisées sur le client et le produit, avec la responsabilité et l’autorité pleine et entière de pouvoir gérer certains types de clients et ce qui les préoccupent. Ces équipes créeront une vision en continu du paysage du client et du produit, elles décideront ce qui doit être construit ensuite sur la base de cette vision. Elles produiront de nouvelles versions de leurs produits toutes les deux semaines. Elles partageront sur ce qu’elles ont créé avec leurs parties prenantes toutes les deux semaines. Nous parlerons de la vision actuelle et du produit actuel, et de ce qui à faire ensuite. Les équipes décideront des prochaines étapes et ce sera reparti pour un tour.

Notre priorité sera mise sur le fait de créer de nouvelles solutions concrètes pour nos clients toutes les deux semaines, des solutions opérationnelles, testées, livrables qui seront passées en revue, mises au plus vite dans les mains de nos clients, et d’utiliser ces résultats pour guider des décisions futures.

Des questions ?

On dirait que vous êtes toujours en train de nous imposer une espèce de processus “Agile”

Non. Je suis, toutefois, en train de mettre un cadre, aussi clairement que possible, quant aux résultats que nous devons voir du processus que vous utilisez : une vision améliorée du paysage du client et de la solution, une production rapide de solution prêt-à-être-mise-aux-mains des clients par rapport à leurs besoins, et une communication en continu sur ce qu’il se passe et comment cela se passe.

Quant au processus que vous utilisez, nous n’imposons rien. Nous demandons un certain type de résultats, dont l’entreprise a besoin, et nous nous engageons à vous aider à apprendre à comment produire ces résultats.

N’est-ce pas simplement une manière déguisée de nous forcer à devenir “Agile” ?

Eh bien, nous demandons un logiciel opérationnel, testé, livrable toutes les deux semaines, de livrer ce que vous avez été en mesure de livrer il y a deux semaines. Il arrive simplement que je connais une manière basique d’y arriver, avec des équipes pluridisciplinaires ayant toutes les compétences nécessaires pour faire le boulot. Il arrive simplement que je crois que ces équipes trouveront des tests unitaires et d’acceptations exhaustifs qui seront la clé pour y arriver, qu’ils voudront apprendre pour faire évoluer leur conception en douceur grâce au refactoring dont ils auront besoin pour que leur système reste intégré tout le temps et ainsi de suite.

Étant donné que nous mettons en place une cadence de deux semaines pour la planification et la revue, vous pourriez vouloir envisager d’adopter des éléments de processus qui soit en accord avec cela et il y a de grandes chances que vous les trouviez dans l’espace de réflexion “Agile”. Je suis certain que vous trouverez plusieurs manières de faire cela, et je peux vous indiquez certaines options si vous en avez besoin.

Mais vous êtes absolument libre d’utiliser le processus de votre choix, aussi longtemps que vous nous donner ce dont nous avons besoin : une vison claire du produit, et un produit livrable toutes les deux semaines.

Mon intention est de vous donner tout ce dont vous avez besoin pour que vous donniez l’assurance que l’entreprise réussisse. Et ce dont j’ai besoin, c’est d’avoir un produit opérationnel, testé, livrable, réalisé selon la vision évolutive du client et de la solution, toutes les deux semaines.

D’autres questions ? Vous savez où me trouvez.


Auteur : Ron Jeffries
Source : How to impose Agile
Date de parution originale : 20 Juillet 2018


Traducteur : Nicolas Mereaux
Date de traduction : 12/06/2019


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. Le Voile d’ignorance est une méthode pour établir la moralité d’un problème. Veuillez consulter cet article de Wikipedia pour en savoir plus.