Durée des cycles agiles

La durée des cycles est une question qui revient fréquemment quand on parle de mettre en place des méthodes agiles dans une entreprise.
Évidemment, il est impossible de donner une durée absolue ; comme pour le reste, il faut l’adapter à l’entreprise, les personnes, les besoins… La plupart du temps, plusieurs visions s’affrontent :

  • Les développeurs qui ont déjà travaillé “en agile” ou qui ont lu des articles sur le sujet, et pour qui un sprint fait 2 semaines. C’est comme ça.
  • Les “décideurs”, pour qui il est plus efficace de faire des cycles longs − entre 1 et 3 mois de développement − car cela maximise la durée de développement par rapport au reste.
  • Les clients (internes ou externes), qui oscillent entre un désir brûlant de voir l’avancement de leurs projets et de demander des modifications en temps réel d’un côté, et de l’autre un dégoût prononcé pour les tests et peu de temps à consacrer pour faire des remontées structurées.
  • Les personnes qui participent à la conception et dont l’avis peut varier énormément suivant qu’elles aient été formées à l’agilité ou non. Quand elles ne le sont pas, elles ont tendance à imaginer le produit parfait, sans vouloir le découper de manière incrémentale ; auquel cas, elles préfèrent évidemment des longs cycles. Celles qui ont été formées à l’agilité connaissent les avantages de réfléchir de manière plus itérative et n’hésitent pas à partir moins loin dans leurs conceptions.

La conception

Il est assez intéressant de voir que la plupart des informations qu’on peut trouver sur le sujet − que ce soit sur Internet ou dans les formations agiles − se concentrent uniquement sur le développement. Même en lisant des choses sur les principes agiles appliqués à la spécification (user stories, principalement), tout le monde semble penser que la création de ces spécifications est une chose hyperfacile et pour laquelle il n’y a pas vraiment besoin d’établir un process, et qu’en conséquence on peut partir du principe que tout commence une fois que l’équipe de développement reçoit les user stories (ou qu’elle n’a qu’à piocher dans un backlog bien rempli).

Mais c’est une erreur complète.

Les phases de conception sont au moins aussi importantes que celles de développement, de test et de déploiement.
Pour être menées correctement, elles doivent être faites de la bonne manière, par les bonnes personnes, avec des processus bordés.

J’ai un exemple en tête. Une entreprise qui est passée à une organisation agile (du Scrum «by the book») avec des cycles de 2 semaines, sans se préoccuper vraiment de  la manière dont les spécifications étaient réalisées. Leur idée a été de mener en parallèle les spécifications et le développement (jusque-là rien d’incohérent), en misant sur le fait que deux semaines de spécification étaient suffisantes pour alimenter deux semaines de développement. Ainsi, un “Sprint Zéro” devait alimenter le premier sprint de développement qui commençait deux semaines plus tard.
Si certains développements peuvent être spécifiés très rapidement, d’autres demandent beaucoup plus de temps. Spécification et développement sont sur des temporalités très différentes. Ce qui devait arriver arriva : Le premier sprint de développement n’a pas pu être complètement alimenté par le sprint zéro. Et surtout, il ne suffit pas de dire à des gens «Vous avez deux semaines pour spécifier, démerdez-vous» pour qu’ils réussissent à faire leur boulot ; il faut un peu de process si on ne veut pas partir dans tous les sens (et donc arriver nulle part).

Les cycles et ce qu’ils impliquent

Un cycle représente une unité de temps au bout de laquelle on va (tenter de) créer quelque chose dont le résultat sera montrable.

Se focaliser uniquement sur le travail de développement est une erreur, car cela peut entraîner de graves oublis dans les phases amont (spécification) aussi bien que dans les phases situées en aval (test, déploiement).
Il est de la responsabilité de l’ensemble de l’équipe de fournir du logiciel utile et de qualité. “Utile” implique que le client s’en serve, et donc que les spécifications soient menées correctement (en prenant en compte les besoins et en sachant changer de direction quand il le faut) ; “de qualité” veut dire que l’on se donne les moyens pour réduire les bugs, augmenter l’évolutivité, réduire les coûts inutiles, documenter ce qui doit l’être, etc.

J’ai expliqué précédemment pourquoi je pense que la manière de produire les spécifications doit être prise en considération dans la mise en place d’un cycle agile. Similairement, on ne se pose plus trop la question sur le fait de tester le logiciel avant de le déployer en production.

Avoir un cycle implique donc que ce qui en sort est testé et validé. Et il faut voir que cela a un coût, mais qu’il est difficile de mettre le curseur au bon endroit. En effet, une phase de test & déploiement a une durée incompressible ; une telle phase ne sera pas deux fois plus longue à la fin d’un cycle de 4 semaines qu’après seulement 2 semaines de développement. Par contre, attendre 3 mois avant de vouloir valider quoi que ce soit paraît suicidaire, car le risque de rencontrer des problèmes bloquants (ou juste très importants) augmente avec le temps qui passe.

Le rôle des développeurs

Si je mets en avant les lacunes des organisations qui se focalisent sur le développement au détriment de la vue d’ensemble (depuis les spécifications jusqu’au déploiement), c’est parce que tout problème a tendance à retomber sur l’équipe de développement.

Une fonctionnalité a été mal spécifiée ? Pas de problème, la demande sera précisée en cours de développement ; avec plusieurs changements en cours de route si nécessaire. C’est le meilleur moyen pour cumuler les retards et générer du code spaghetti.
Un développement n’a pas été testé correctement ? Mettons-le quand même en production. Si un bug est trouvé par la suite, on se dépêchera de faire un correctif. C’est parfait pour avoir des problèmes énormes en production (pouvant impacter le chiffre d’affaires ou la réputation à long terme, par exemple), et à faire des correctifs rapides et eux-mêmes buggués, conduisant au suraccident.

Non seulement la qualité globale du travail de l’équipe diminue, mais en plus cela fait peser une pression inutilement forte sur les développeurs, juste parce que d’autres personnes n’ont pas fait leur travail ou l’ont mal fait.

Le rôle des développeurs sur les projets est triple :

  • Accompagner les phases de conception, pour proposer des solutions techniques aux problèmes fonctionnels.
  • Réaliser le code qui implémente la demande fonctionnelle, en cherchant à trouver la bonne mesure entre le temps passé et la valeur intrinsèque de la fonctionnalité, en suivant les bonnes pratiques de l’entreprise.
  • S’assurer que son code fonctionne, que ce soit d’un point de vue technique (adéquation avec le reste de l’architecture, performance, etc.) ou fonctionnel.

À cela s’ajoutent des responsabilités parallèles en fonction des situations (propositions techniques, organisation de conférences ou de hackathons, ou autre).
Mais dans tous les cas, les développeurs ne se destinent pas à prendre sur eux les lacunes des autres…

Les cycles de deux semaines

Lorsque quelqu’un me dit qu’il travaille sur des cycles de 2 semaines, je lui réponds «Non, ça c’est la durée de votre sprint de développement». Je ne remets pas en question ce choix, deux semaines étant souvent une durée ni trop courte ni trop longue pour assurer des développements.
Mais que se passe-t-il pour ceux qui essayent vraiment de faire tenir leur cycle en deux semaines ? Pour commencer, les spécifications ne sont pas prises en considération ; c’est une erreur, je ne vais pas revenir là-dessus. Ensuite, on peut imaginer que le cycle se déroule de la manière suivante :

  • En début de cycle, une demi-journée est consacrée aux rituels de début de cycle (étude des user stories, planning poker).
  • En fin de cycle :
    • Une demi-journée est utilisée pour faire la démo des nouveaux développements aux clients.
    • Une demi-journée est consacrée aux tests fonctionnels (automatisés et/ou par les clients). Le déploiement sur un environnement de test (préprod, qualification, appelez-le comme vous voulez) conditionne cette demi-journée, qui peut être réduite si tout ne s’est pas bien passé…
    • Une demi-journée ou une journée est consacrée aux résolutions de bugs mineurs, en fonction des retours de tests. Les bugs majeurs font que le développement est sorti de la release et sera traité sur un autre cycle.
    • Une demi-journée est consacrée au déploiement en production.
    • Une demi-journée est réservée pour ce qui permet de clore le cycle : la rétrospective ou le niko-niko, l’analyse de ce qui a été écarté durant le cycle, etc.

Au final, il reste donc au mieux 7 jours de développement (ce qui n’est pas si mal en fait). Mais surtout, ce genre de cycle a deux impacts qui sont souvent oubliés un peu facilement :

  • Le moindre grain de sable peut tout enrayer. Une mise en préprod un peu longue, des tests qui démarrent un peu tard ou qui durent plus longtemps que prévu, une longue liste de bugs à corriger absolument… et c’est l’ensemble du cycle qui risque de déborder. Avec pour résultat un « intercycle » qui ne servira qu’à faire les tests, les débogages ou le déploiement qu’on n’avait pas eu le temps de faire.
  • On fait peser une contrainte forte sur l’ensemble des parties prenantes. Les clients ont une fenêtre de tir extrêmement réduite pour tester les développements qui les concernent. Les développeurs n’ont pas de temps de répit qu’ils peuvent consacrer à des refactorings.

Le sentiment d’urgence continuelle créé par la combinaison de ces deux points peut se révéler très anxiogène à la longue. Comme le dit Jason Fried au sujet des cycles utilisés chez Basecamp (j’y reviens plus bas) :

These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Automatisation et déploiement continu

Sur un cycle de 2 semaines, on cherche évidemment à automatiser le plus possible les tests, pour minimiser le temps passé à tester et pour réduire les impacts possibles.

Mais il n’en reste pas moins que tout n’est pas testable automatiquement. Que ce soit dans le design (pour un site web) ou pour des questions d’infrastructure (une plate-forme de production peut légitimement avoir des différences par rapport à une plate-forme de test), il faut souvent valider à la main certains points-clés.

Le déploiement continu est quelque chose qui peut être très efficace lorsqu’il est correctement conduit. En mettant en production les développements au fur et à mesure qu’ils sont prêts, on augmente la réactivité de l’entreprise.
Sauf que lorsque cela est mal mené, on peut vite tomber dans un travers assez classique : On se dépêche de mettre en production des développements qui ne sont pas suffisamment testés (que ce soit de manière automatisée ou non), parce qu’il sera toujours facile et rapide de mettre en ligne un correctif s’il le faut. Sauf qu’en procédant de la sorte, on fait encore peser la responsabilité sur les seules épaules du développeur (s’il y a un bug, c’est de sa faute et non celle de celui qui a mal testé), et on risque de fonctionner à coups de correctifs qui s’empilent en faisant perdre toute vision d’ensemble.

Dans une entreprise que j’ai visitée il y a quelques années, un graphique était affiché sur un écran dans l’open-space. Une courbe montrait l’évolution du chiffre d’affaires, et des barres verticales symbolisaient les mises en ligne ; ainsi, lorsqu’un bug avait pour effet de faire chuter le chiffre d’affaires, il était facile d’identifier le développement responsable.
Sauf que je considère qu’on doit tout faire pour ne pas risquer d’avoir un site tellement bogué qu’il ne va générer aucun chiffre d’affaires, ne serait-ce que 5 minutes. Que ce soit pour le manque à gagner financier ou la perte d’image qui peut se révéler catastrophique à moyen terme, cela me semble trop grave. Surtout lorsque l’alternative est de différer le déploiement de seulement 2 semaines… De plus, on peut imaginer que des développements bogués passent à travers les mailles du filet, simplement parce qu’ils impliquent une faible baisse du chiffre d’affaires (mais une baisse quand même).

Pour que ça fonctionne sans accroc, il faut y mettre des moyens humains et techniques assez importants.

Les cycles de 6 semaines

Les gars de Basecamp ont mis en place des cycles de 6 semaines. Ils l’ont annoncé sur leur blog, puis sont revenus dessus pour expliquer comment cela se passait.

Je vous invite à lire les deux articles, qui sont assez longs.
En résumé, ils constituent des équipes de 2 ou 3 personnes (un ou deux développeurs et un designer), en fonction de ce sur quoi les gens ont envie de travailler pendant les 6 prochaines semaines. Chaque équipe réalise un “gros projet” (qui occupe tout le cycle) ou plusieurs “petits projets”.

Ils n’expliquent malheureusement pas clairement comment le travail se découpe au long de ces cycles. On apprend néanmoins qu’ils ont une équipe QA (Assurance qualité) de 2 personnes, qui est mise à contribution par les autres équipes pour s’assurer de la qualité des projets avant leurs mises en ligne.
(quand je parlais de moyens humains, on peut en voir un bon exemple ; ils ont 2 personnes dédiées à la qualité, pour 4 développeurs et 4 designers)

Mon expérience

J’ai déjà parlé sur ce blog (ici et ) de la manière dont j’avais mis en place les cycles chez Fine Media, continuellement améliorée pendant 6 ans.

Pour commencer, les projets étaient prédimensionnés suivant la technique des tailles de t-shirt (S, M, L, XL) − technique aussi bien utilisée dans les organisations agiles que dans de grosses entreprises. La durée de conception dépendait de cette estimation, et la partie plus classique «développement + test + déploiement» durait toujours un mois.

Si on prend l’exemple d’un projet Medium (environ 3 jours de développement), on avait une chronologie comme suit à partir de la validation de l’expression de besoin écrite par le client interne :

  • 1 semaine pour réaliser les wireframes
  • 2 semaines pour faire les maquettes
  • 1 semaine pour écrire la spécification fonctionnelle
  • 1 semaine pour écrire la spécification technique
  • 2 semaines [DEVeloppement] pour réaliser le développement
  • 1 semaine [STABilisation] pour tester le projet (par le développeur et par le client)
  • 1 semaine [Mise En Prod] pour valider en préprod puis mettre en prod

De manière un peu plus graphique, ça donne ça :

Vous pouvez imaginer que les cycles se chevauchent. Durant la semaine de MEP, la priorité des développeurs est de résoudre les bugs qui seraient trouvés en préprod (voire en prod) ; comme cela ne les occupe pas à plein temps, ils font les analyses techniques nécessaires pour les projets qu’ils auront à développer le mois suivant.

La semaine dévolue aux tests permet aux clients de s’organiser pour réaliser les validations nécessaires sans être dans la précipitation. Pour l’équipe technique, ce temps était mis à contribution pour faire des débogages, mais aussi pour réaliser des refactoring mineurs ou lancer des projets purement techniques qui sont ajoutés à la liste des projets par la suite.

À titre de comparaison, voici le cycle complet pour un projet Large (de 4 à 10 jours de développement). Vous pouvez voir que les durées de conception sont adaptées en conséquence :

Toutes ces durées sont évidemment d’ordre indicatif, certains projets ayant besoin de plus de temps pour certaines étapes, alors que d’autres projets pourront carrément se passer de certaines autres (par exemple, pas de maquettes sur des projets de back-office). Mais elles sont cohérentes face à ce qui avait pu être constaté. On peut trouver certaines durées très longues, mais elles sont aussi à mettre en perspective avec le fait que les mêmes personnes s’occupaient de plusieurs projets à la fois.

Ce workflow permettait de s’assurer qu’on était bien dans les clous, et qu’on n’essayait pas de faire tenir à tout prix un projet dans un cycle alors que les phases de conception étaient à la ramasse.
Et cela permet de voir que même avec des mises en production tous les mois, la vraie durée des cycles de développement est bien plus longue.

Et vous ?

Ça m’intéresserait de savoir comment les choses sont organisées dans votre équipe/entreprise. Est-ce que les phases de conception sont gérées ? Êtes-vous sur des cycles qui se résument à des sprints de 1, 2 ou 3 semaines ? Utilisez-vous des cycles plus longs, et si oui comment sont-ils structurés ?

Combien de développeurs mettre sur un projet

Je considère la question intéressante : Combien de développeurs faut-il assigner à un projet ?

Intéressante parce que cette question revient à une fréquence relativement élevée, alors que sa réponse est simple à comprendre et qu’elle reste invariable au fil du temps.

Si cette question revient fréquemment, c’est bien parce que l’élan naturel de la plupart des décideurs (souvent des gens qui viennent du business et qui ne savent pas comment on fait du logiciel ; mais je connais des informaticiens qui ont le même tropisme) est de penser que pour aller plus vite, il faut mettre plus de ressources.

Après tout, le moyen le plus simple pour peindre un mur plus vite, c’est de faire appel à plus de peintres, non ?

Le mythe du mois-homme

Ce phénomène a été disséqué par Frederick Brooks dans son livre Le mythe du mois-homme. Paru en 1975 et réédité en 1995, c’est un classique des livres de management informatique. Eh oui, cela fait plus de 40 ans que ce problème a été analysé, et pourtant il est toujours autant d’actualité !

À défaut de le lire (l’édition française est introuvable, la seconde édition américaine est maintenant hors de prix, mais la première édition se trouve aisément en PDF − ne me demandez pas si l’auteur et l’éditeur ont donné leur accord pour sa diffusion), je vous conseille de lire l’article consacré au livre sur Wikipédia.

Pour faire un résumé très rapide, le livre présente deux concepts :

  • Le premier est que c’est une illusion de croire que le travail réalisé par un développeur en deux mois peut être fait par deux développeurs en un mois. Le parallèle archiconnu est celui des femmes enceintes (si une femme fait un enfant en neuf mois, neuf femmes ne feront pas un enfant ensemble en un mois).
  • Lorsqu’un projet est en retard, lui affecter des personnes supplémentaires ne fera qu’ajouter encore plus de retard. Chaque nouvel intervenant devra prendre le temps de monter en compétence, et devra communiquer avec tous ceux déjà en plus ; ainsi, ce n’est pas 1 canal de communication qui va s’ajouter, mais X canaux (X étant égal au nombre de personnes qui travaillent déjà sur le projet). Et cela peut aboutir à des situations ridicules, lorsque le temps de traitement des échanges d’information est supérieur au temps nécessaire à chacun pour réaliser son boulot.

Continuer la lecture de « Combien de développeurs mettre sur un projet »

Livre : Reinventing Organizations

Le livre Reinventing Organizations est un best-seller dont une version illustrée a été éditée. J’ai acheté cette version, qui met son contenu en scène à travers des illustrations bien réalisées.

Le livre se découpe en trois parties :

  • La première est consacrée à une étude de différents types d’organisations existants, avec un focus sur l’émergence d’un nouveau type plus moderne.
  • La deuxième partie explique ce nouveau type, à travers les concepts qui se retrouvent dans les cas où ce genre de management a été mis en œuvre.
  • La troisième partie donne des outils pour aider à la mise en place de ces principes au sein d’une organisation.

Ce livre est vraiment intéressant. Que l’on soit d’accord ou non avec ce qu’il présente, tout bon manager (même les mauvais) devrait le lire pour s’ouvrir aux concepts qui y sont abordés.
Je ne vais pas détailler les trois parties du livre, mais pour vous donner envie de le lire, je vais vous résumer les différents types d’organisations qui y sont décrits. L’auteur donne une couleur à chaque type (on peut trouver ça bizarre, mais au final ça marche plutôt bien).

(Je vais paraphraser certains passages, et reproduire quelques illustrations. Encore une fois, le but est de vous faire connaître ce livre, pas d’en faire un plagiat. Je vais mettre des citations quand les mots du livre le mériteront.)

Rouge − Stade impulsif

Au début de l’humanité, il n’y avait pas d’organisation réelle. Il y a environ dix mille ans, avec l’apparition de groupes plus larges, est apparu le rôle du chef, garant de l’ordre. Le pouvoir s’exerce de manière brutale s’il le faut.

Continuer la lecture de « Livre : Reinventing Organizations »

Le cycle en cascade

Quand j’ai créé ce blog, j’ai écrit des articles sur différentes méthodes de gestion de projets (cycle en Vitératif, agile, …). Bizarrement, je n’ai jamais pris le temps d’en écrire un sur la méthode la plus simple, la gestion en cascade. Je pensais à l’époque que tout le monde connaissait cette manière de travailler, mais il se trouve que ce n’est pas le cas et que cela mérite qu’on s’y attarde un peu.

Principe

Le principe du cycle en cascade est assez naturel. L’organisation du travail est découpée en étapes qui se succèdent les unes aux autres.

Continuer la lecture de « Le cycle en cascade »

Les valeurs en entreprise

Je préparais depuis quelque temps l’écriture d’un article sur la question des valeurs en entreprise. Je me décide après avoir lu récemment un article sur les valeurs des startups.

L’article parle principalement du syndrome qu’ont certaines startups, misant sur leur “coolitude” (avoir des beaux locaux, un baby-foot, …) au détriment des valeurs fondamentales qui permettent d’avoir un environnement de travail sain et efficace.

J’ai connu plusieurs entreprises dans ma carrière, qui véhiculaient des valeurs bien différentes les unes des autres. La plupart du temps, les valeurs d’une entreprise n’ont rien d’explicite : elles sont le résultat de la personnalité des fondateurs (ou des managers, si les fondateurs ont déjà quitté le bateau), de la manière dont ils gèrent l’entreprise et ses salariés, mais aussi de la personnalité de tous ceux qui travaillent dans l’entreprise.

Netflix a une approche très pragmatique des valeurs d’entreprise. Ces slides l’illustrent très bien :

 

 

Comme ils le font remarquer, il est assez facile de placarder de grandes valeurs générales. Ils donnent l’exemple d’Enron dont la première valeur officielle est l’intégrité… ce qui est amusant quand on sait que les malversations des dirigeants de l’entreprise ont mené à mettre la clé sous la porte (et les ont conduits derrière les barreaux).

Petite parenthèse : Plutôt que de s’intéresser à Enron, on pourrait parler de l’exemple de Google, plus proche de nous. L’entreprise a été condamnée à verser une amende de 500 millions de dollars à l’état américain en 2011. Officiellement, des petits malins se seraient amusés à contourner une limitation et à faire afficher dans AdWords des publicités pour des pharmacies canadiennes (cf. cet article). La chose paraît presque anodine. Sauf que la réalité semble un peu plus moche (lisez ce long article de Wired paru en 2013). Ajoutons qu’il semblerait que certains aspects de cette instruction sont cachés avec soin (d’après cet article anglais). Et je ne sais pas pour vous, mais quand je tape «google amende 500 millions drogue» dans Google, je n’ai aucun résultat qui parle de cette affaire… Ce qui est bien différent sur Yahoo!, Bing ou Qwant. Je rappelle qu’à l’époque la devise de Google était «Don’t be evil» et que leurs 10 principes fondamentaux incluent «Il est possible de gagner de l’argent sans vendre son âme au diable» (cf. Wikipédia). Ah c’est beau et important, d’avoir des valeurs…
Fin de la parenthèse

Ce point de vue est particulièrement intéressant. Parce qu’il est assez facile de proclamer une liste de valeurs, mais il est beaucoup plus difficile d’en tirer quelque chose de concret au quotidien.
Surtout qu’on tourne toujours autour des mêmes concepts d’Excellence, d’Esprit d’équipe, d’Intégrité, de Communication, d’Agilité, …
Pour ceux qui connaissent la série How I Met Your Mother, ces valeurs grandiloquentes et déconnectées de la réalité ont à peu près autant d’utilité que les posters motivationnels de Barney Stinson

En la matière, je préfère de loin le «Make mom proud» vu dans les locaux de Box.

Je vous suggère la lecture de l’article Your Company’s Culture is Who You Hire, Fire & Promote. Il présente l’idée que les employés d’une société s’intéressent à ce que font leurs patrons, pas à ce qu’ils disent. Ça paraît évident, dit comme ça, mais la réalité montre bien que le «faites ce que je dis et pas ce que je fais» est encore bien présent dans les entreprises. Ce sont donc les actes et le comportement général des managers qui façonnent les valeurs et l’image de l’entreprise.

Dans les notions abordées par cet article, il y a le «No Asshole Rule», qui pourrait être comparé à une tolérance zéro envers les comportements toxiques. La difficulté est évidemment de détecter de tels comportements, car une personne qui ne peut pas travailler en équipe (ou en tout cas avec l’équipe en place) n’aura pas un comportement problématique en permanence.
Il parle aussi du fait que bien des entreprises se trouvent des excuses pour ne pas se débarrasser des personnes qui ne sont pas en phase avec les valeurs. Bien souvent il s’agit des performances de ces personnes, et cela peut être encore plus criant lorsqu’elles centralisent des compétences uniques dans la structure.

Pour revenir aux slides de Netflix, le message important est donc (je me contente de traduire comme je peux la slide n°6) :

Les vraies valeurs d’une entreprise, par opposition aux valeurs qui font bien, sont celles affichées par ceux qui sont récompensés, promus ou qu’on laisse partir.

Oui, ce sont les personnes qui composent l’entreprise qui en font les valeurs au final. Récompenser un manager qui hurle sur son équipe, c’est envoyer un message clair sur les techniques de management autorisées. Ne pas virer un employé qui sabote son travail et celui des autres, parce que c’est un narcissique qui pense tout savoir mieux que les autres, cela ne motive pas le reste de l’équipe. Accompagner vers la sortie quelqu’un de bonne volonté qui n’a pour seul défaut que sa jeunesse et son inexpérience, c’est là encore une erreur basique.

Il faut aussi remarquer une chose : En Amérique du Nord, il est assez facile de virer quelqu’un rapidement si cette personne a un comportement qui n’est pas aligné avec les valeurs de l’entreprise (mais aussi si elle n’est pas performante). Je ne vais pas débattre sur les avantages sociaux que nous avons en France, mais je pense personnellement que c’est une bonne chose que l’on ne vive pas continuellement avec la crainte de se faire virer du jour au lendemain et/ou sans bonne raison. Il faut reconnaître que j’ai croisé des assholes (j’aime le terme en anglais, il exprime bien la chose) qui savaient très bien donner le change pendant leur période d’essai ; j’en ai même connu qui le sont devenu au fur et à mesure d’un long et lent processus s’étalant sur plusieurs années.

Toutefois, j’ai déjà vu des grilles d’évaluation des employés, réalisées par les services RH, qui servaient à définir lesquels étaient les éléments à récompenser, ceux à accompagner et ceux dont il fallait se séparer. Ces grilles sont toujours avec deux axes : la performance (les connaissances, les compétences) d’un côté, et le potentiel de l’autre (la capacité à apprendre, progresser, s’améliorer).
Dans l’article dont je vous parle, l’auteur propose une grille dont les axes sont la performance et l’alignement avec les valeurs de l’entreprise. C’est intéressant parce que ça mène à prendre en compte ce facteur, à voir les collaborateurs sous un angle différent.
Mais il n’en reste pas moins qu’il est très compliqué de se séparer de quelqu’un au motif que cette personne ne respecte pas les valeurs de l’entreprise. C’est n’est pas tout blanc ou tout noir ; et si le doute doit bénéficier à l’employé, il sera néfaste pour l’entreprise à terme.

Dans les comportements qui ne sont compatibles avec aucune valeur d’entreprise, il y a l’utilisation du rire pour déstabiliser les individus et les organisations. Ce type de comportement est difficile à détecter, car l’humour est quelque chose de positif ; c’est ce qui détend les gens, fait relâcher la pression, génère de la cohésion. Mais c’est à double tranchant : le rire peut devenir moquerie et devient alors une arme de manipulation.
À ce sujet, je vous suggère de lire Le rôle du rire dans les organisations. Très intéressant, il explique notamment le lien entre rire et pouvoir (extrait : «Le pouvoir de celui qui sait faire rire les autres tend donc continuellement à augmenter, parce qu’il draine vers lui la sympathie et l’admiration des autres, et parce que, confusément, il se fait craindre.»).
J’ai vu comment le rire pouvait apporter du pouvoir à celui qui le générait… et comment le fait d’avoir du pouvoir rend les gens drôles (car si générer le rire donne du pouvoir, rigoler est alors un moyen de s’inféoder et de reconnaître implicitement le tenant du pouvoir). Évidemment, dans une entreprise, le rire est d’autant plus utilisé comme arme de pouvoir quand il se fait aux dépens d’autres personnes de la même organisation ; la moquerie rabaisse de manière proportionnelle au nombre de personnes qui rient.
Pour surfer sur l’actualité, on peut voir le même rapport entre rire et pouvoir avec les agissements de Cyril Hanouna (extrait : «Moquer quelqu’un (…) c’est “pas pour rire”, c’est “pour dominer”»). Que penser alors des amuseurs en entreprise qui se réclament du rire d’Hanouna ?

Comme le dit Frédéric Mazzella (co-fondateur de Blablacar), les valeurs − quand elles sont exprimées et vécues réellement − sont importantes pour les entreprises, et pour plusieurs raisons.
Premièrement, elles différencient les entreprises les unes des autres. Vivre certaines valeurs peut être un argument réel pour faciliter le recrutement, soit parce qu’elles sont réellement positives (au contraire de ce qui est vécu dans les autres sociétés), soit parce qu’elles définissent l’ADN de l’entreprise et orientent donc les profils des gens qui pourront s’y épanouir (sans pour autant porter de jugement sur la qualité intrinsèque de ces valeurs).
Elles servent aussi à remettre l’humain au centre de l’activité de l’entreprise, redonnent de la valeur et du sens au travail. Elles définissent les règles et donnent une direction, ce qui permet à tous de comprendre ce qu’il peut apporter à son niveau, et ce qu’il peut attendre des autres.

Ce dernier point m’évoque un parallèle avec les concepts de gamification. Plus que de motiver les gens en leur faisant gagner des cadeaux virtuels, ces concepts sont appréciés de certaines personnes parce qu’ils offrent une lecture simple et rapide du travail qu’on attend d’eux (et donc aussi du comportement qu’on attend d’eux, si on élargit ça aux valeurs). Lorsqu’il y a une règle du jeu claire, il est facile de s’y conformer.

The Galion Project (un think tank qui réunit des entrepreneurs de la french-tech) a publié un document PDF téléchargeable sur le sujet des valeurs d’entreprise. Je vous invite à le télécharger, mais je vais essayer de résumer quelques points-clés.
Les valeurs ont un triple impact : Sur le recrutement (évoqué plus haut), le management et la prise de décision (donner de l’autonomie en montrant la direction voulue par l’entreprise, ce qui rejoint le message de Netflix).
Il y a plusieurs événements qui peuvent déclencher le besoin d’exprimer les valeurs : Quand la taille de l’entreprise dépasse 10 à 15 personnes, quand le travail est délocalisé ou le déploiement international.
L’appropriation des valeurs par les équipes est absolument nécessaire, et le meilleur moyen pour y arriver est de les créer de manière collaborative, en s’assurant qu’elles soient communes à tous, exprimées de manière formelle, et qu’elles correspondent à la réalité de ce qu’est l’entreprise au quotidien.
Les valeurs doivent être revues tous les 3 à 4 ans.

J’ajouterais personnellement que les valeurs, ainsi que les moyens déployés pour les mettre en œuvre dans l’entreprise, doivent être au cœur des préoccupations du top-management. Du PDG. Sinon ça ne fonctionne pas.

Le vocabulaire teinté

J’ai déjà parlé des problèmes liés aux noms de code (à la con) donnés aux projets.
Là, je partage avec vous une anecdote assez marrante, mais au final assez crispante quand elle se renouvelle tous les jours. Elle date d’il y a 3 ans, mais reste complètement d’actualité.

Je vous fait grâce du contexte. Mais, dans l’entreprise qui nous a rachetés, il y a des webservices qui permettent d’accéder à différents types de données. Il y a plusieurs webservices différents, avec pour chacun des versions différentes, tout ça étant très bien géré (on sait jusqu’à quelle date une version spécifique sera supportée, on est accompagné quand il faut migrer de version).
Ce sont des webservices comme on les faisait partout il y a quelques années, à base de SOAP, sûrement écrits en Java.

Il a été décidé que les nouveaux webservices devraient être plus souples d’utilisation − ce qui est une très bonne chose évidemment − et cela passe notamment par une communication REST-like : les paramètres sont envoyés en GET ou en POST, et les résultats sont récupérés en XML ou en JSON.
Bref, l’évolution technique n’est pas fondamentale.

Au fil du temps, les gens ont développé un vocabulaire assez étrange et amusant. Ils parlent du webservice pour parler des anciens webservices, et de l’API pour parler des versions plus récentes.
En soi, c’est marrant. De mon point de vue, les termes “webservice” et “API” sont plus ou moins interchangeables. Un webservice expose une API ; une API repose sur une solution technique (bibliothèque de fonction, webservice, CORBA, …).

Il y a 3 ans, j’avais donc reçu un email qui m’avait vraiment fait rire. Petit extrait :

Au même titre qu’aujourd’hui vous récupérez (…) via un WS, demain vous récupéreriez via une API (vu que les WS ne sont plus en vogue il me semble)

Bon, c’est un peu méchant de se moquer de personnes non techniques, lorsqu’elles doivent manipuler du jargon technique.

Ce que tout ça montre, c’est que toute entreprise développe son propre vocabulaire. C’est normal. Et la plupart du temps, certains termes ou expressions sont utilisés avec une signification particulière, parfois très éloignée de leur définition initiale. Ceci s’explique souvent par des raisons historiques : quelqu’un a utilisé un terme dans un contexte donné, et d’autres personnes l’ont réutilisé pour parler de la même chose, mais dans un contexte différent qui aurait dû en changer le sens.

C’est d’ailleurs un fait connu en linguistique.

De manière générale, il faut accepter la chose et apprendre ce vocabulaire qui est teinté par la vie de l’entreprise. Avant la création de mon entreprise actuelle, j’ai travaillé dans une société où la multiplication des acronymes et des contre-sens avait poussé à écrire un lexique pour regrouper tous les termes propres au secteur industriel concerné en général, et à cette entreprise en particulier ; très bonne initiative, confiée au département juridique…

Je dis ça mais, il n’en reste pas moins que j’ai du mal à dire « webservice » et « API » comme si c’était des termes complètements antinomiques.

Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

De la gestion de projet à la gestion de workflow

Il y a une chose qui me chiffonne lorsqu’on s’intéresse aux méthodologies agiles, telle qu’elles sont définies « by the book », ou telle qu’elles sont enseignées. On y décrit un fonctionnement à base de sprints de développement, qui s’enchaînent les uns après les autres, avec une durée de l’ordre de la quinzaine de jours. Même en décrivant la partie qui se situe en amont du développement (écriture de user stories, gestion du backlog), et celle qui se situe en aval (tests, validation, mise en production), tout reste centré sur le développement.

Au final, dans la vraie vie, ces périodes de conception et de validation finissent par manger sur la période de 2 semaines qui devrait être consacrée au développement. On se rend compte assez vite des limites du système…

De mon point de vue, il faut prendre la gestion de projet à un plus haut niveau. Et il faut définir un workflow global, qui va permettre à tous les intervenants du projet de savoir ce qu’ils ont à faire et pour quand. Je vais illustrer cela en expliquant ce qui est mis en place dan mon entreprise ; c’est le fruit d’un process dérivé de la méthode Scrum, qui est affiné sans cesse depuis plus de 5 ans. Continuer la lecture de « De la gestion de projet à la gestion de workflow »

L’email n’est pas mort (suite)

Il y a 4 ans, j’écrivais un article intitulé L’email n’est pas mort, dans lequel je réagissais au courant de pensée disant que la messagerie électronique était condamnée en milieu professionnel, face aux réseaux sociaux d’entreprise.

Pour faire simple, je disais que l’email est un outil parmi beaucoup d’autre (j’en listais une douzaine), et que vouloir travailler sans email est aussi intelligent que de vouloir travailler sans téléphone : il ne faut pas travailler avec ce seul outil, mais ça ne veut pas dire qu’il faut le bannir pour autant.
La force des outils universels, c’est avant tout l’usage et la pérennité dont ils bénéficient, qui sont assez difficile à prendre en défaut.

Ce qui me fait revenir là-dessus, c’est l’annonce de l’arrêt par Facebook de leur système de messagerie, qui avait été présenté en 2010 comme un « Gmail-killer » et qui n’aura finalement été qu’un pétard mouillé.

L’autre fameux tueur d’email qui n’aura pas fait long feu, c’est Google Wave. L’outil était splendide, mais difficilement utilisable au quotidien. Présenté en 2009, Google annonçait sa mort un an plus tard, pour finalement fermer le service début 2012.

Bref, que faut-il penser de tout ça ? Eh bien qu’il est difficile de remplacer quelque chose d’aussi universel que l’email. Mais plutôt que de vouloir le remplacer, je reste persuadé qu’il est beaucoup plus malin de chercher à enrichir le système, à le compléter, à s’y adosser pour aller plus loin.

La gestion de projet, ça n’existe pas

Le titre de cet article peut sembler un peu polémique, mais vous allez voir qu’il n’en est rien. Mon point est de faire ouvrir les yeux sur ce qu’on appelle la gestion de projet, et pourquoi trop souvent « ça se passe mal ».

La chose la plus importante à comprendre :
On ne gère pas des projets, on gère des hommes

Un projet est une chose immatérielle, qui regroupe à la fois :

  • un but à atteindre,
  • une équipe,
  • une unité de mesure du travail effectué,
  • un référentiel.

Ce que l’on gère au quotidien, ce sont les personnes qui travaillent sur le projet.

Le corollaire : On peut faire le suivi d’un projet ; on peut mesurer l’avancement du travail de l’équipe ; on peut anticiper les dérives et les problèmes éventuels.

Qu’est-ce que cela implique ? Une fois que l’on a intégré ces notions, on peut mettre en place un management à la fois plus humain et plus efficace. Tout le monde sait depuis longtemps que la « gestion de projet » à l’ancienne, à base de diagrammes de Gantt servant à faire claquer le fouet au-dessus des têtes, est contre-productive : elle fait croire qu’une personne seule (le « chef de projet ») peut faire glisser les curseurs caractérisant le projet (qualité, coût, délai) à partir d’une sorte de panneau de contrôle aux pouvoirs tout-puissants. Elle résume les hommes et les femmes qui travaillent sur le projet à de simples pions qui sont manipulables et réaffectables à loisir.
Certaines personnes en viennent même à rêver d’une notion que le travail peut se découper en unités interchangeables. Pour qu’une tâche aille deux fois plus vite, il suffit alors d’y affecter deux personnes ; comme si deux taxis pouvaient vous amener à l’aéroport en une demi-heure lorsqu’un seul taxi vous y emmène en une heure.

Ce type de gestion ne peut qu’amener à des frustrations, des retards, une diminution de la qualité.

C’est en s’occupant des hommes et des femmes que l’on peut atteindre l’objectif d’un projet. Le jour où tout le monde a intégré cela, c’est une tout autre dimension qui s’offre à nous : On peut capitaliser sur les compétences de chacun, car on a pu les identifier. On réduit les retards, car on implique dans la planification ceux qui vont vraiment faire le travail. On crée un meilleur produit car on implique toute l’équipe en amont de la réalisation. On s’assure que les documentations nécessaires sont présentes, non pas pour la forme, mais parce qu’elles sont utilisées. On fidélise ses collaborateurs, parce qu’on s’intéresse à leurs envies et à leur progression professionnelle.

Quand je dis que tout le monde doit intégrer cela, je parle vraiment de toutes les strates de management de l’entreprise. Un chef de projet peut isolément mettre en place une bulle autour de son équipe ; mais si la prise de conscience n’est pas effective autour et au-dessus de lui, il se heurtera à des murs et la bulle finira par exploser. Par contre, si tous les managers sont sur la même longueur d’onde, les résultats seront durables.