Vous avez dit agile ?17 octobre 2012

Les derniers succès dans la nouvelle économie sont souvent le fruit de petites entreprises ayant commencé dans leur « garage », avec des processus très agiles. « Small is beautiful » était leur leitmotiv. La question qui nous intéresse est de savoir si ce sont des exceptions dues à quelque fondateur génial, ou si des enseignements peuvent en être tirés dans l’organisation d’entreprises de grosse taille. Il est intéressant de voir que des sociétés comme Google ou Facebook, voire Amazon, continuent d’être flexibles et innovantes malgré une taille respectable (32 000 / 3 000 / 22 000 salariés respectivement).

A l’heure où « l’offshore » est aussi à la mode que le « lean », comment ajuster organisation et processus pour atteindre une efficacité maximale ?

Quand 1 vaut mieux que 10

Le fameux logiciel (système d’exploitation) de l’iPhone a été développé par 60 développeurs, alors que Motorola n’a pas réussi à développer un système concurrent avec 1 500 personnes : non seulement la qualité des développeurs n’est pas compensable par leur quantité mais au contraire, le surdimensionnement d’une équipe est contre-productif. Nous avons vu des projets prendre plusieurs mois de retard pour 15 jours homme de développement.

Pourquoi ? À « l’unité de base », le développeur : « Un bon développeur en vaut 10 médiocres » (étude de Sackman, Erickson et Grant) : les bons développeurs fournissent un code de meilleure qualité et plus rapidement. La qualité du code impacte ensuite les phases de test, de débogage, de maintenance et d’upgrade. Au niveau de l’équipe, les actions ne sont pas parallèles mais interdépendantes : du coup, les compétences ou incompétences se multiplient au lieu de s’additionner et une erreur fait perdre du temps à toute la chaine.

En fait, on retrouve ici des lois « ancestrales », que l’on retrouve dans de nombreux autres secteurs, dès lors que l’on est plus dans l’exécution pure : artisanat, création, analyses, etc. Un développeur est un « créateur » de code, et non un simple exécutant, reproduisant un même geste à l’infini.

A partir de là, le management doit être adapté, et permettre l’initiative, en évitant le management « militaire » : un ordre exécutable dicté à tous, efficace pour l’exécution pure, bien moins dès lors que l’on attend un minimum d’initiative. Ceci s’applique à tout l’encadrement, mais aussi aux techniciens et autres populations qui ne sont pas exécutants purs, et d’une manière générale à tout grand projet.

Simplicité et légèreté

Revenons donc au logiciel pour comprendre ce qui fait le succès de ces équipes efficaces. Un des points du développement de logiciel a été pendant de longues années, la dualité spécifications fonctionnelles – développement.

Il faut bien voir que décrire (« spécifier ») un logiciel peut être aussi compliqué que de l’écrire réellement. Par ailleurs, des spécifications sont toujours sujettes à interprétation, et à partir de là, fausses par nature.

A partir de ce constat, les nouvelles méthodes de développement tendent à limiter au maximum la phase de spécification et de la fusionner avec le développement. Attention, il ne s’agit pas pour autant de « foncer puis réfléchir après », mais bien de limiter la phase de réflexion à l’architecture générale et aux interfaces, et de découper le tout en sous-ensembles cohérents.

Grace à ces méthodes, Facebook publie une nouvelle version chaque semaine, Firefox est passé à des cycles de 6 semaines pour une nouvelle version, au lieu de plusieurs mois, voire années auparavant.

Quels sont donc les outils mis en place ? Les équipes sont légères et responsables, avec un responsable fonctionnel (product owner), unique représentant du client, un facilitateur (Scrum master) chargé d’épauler l’équipe dans ses relations avec l’extérieur et de résoudre ses problèmes non techniques et enfin une petite équipe compétente et responsabilisée de développeurs possédants une vision globale du projet et force de propositions. Tout à l’opposé de ce qu’on peut rencontrer dans certains projets où il y a plus de décideurs, chefs de projets, valideurs, etc. que d’acteurs effectifs. Nous avons vu des projets prévoyant 35 k€ de gestion de projet pour 5 de développement !

Oser la flexibilité

Les spécifications seront donc légères et évolutives, pour s’adapter aux contraintes du développement, et aux inévitables évolutions du besoin : elles ne sont qu’un outil dans la production du logiciel. Elles doivent se réduire au strict nécessaire pour ne pas paralyser le développement et elles doivent pouvoir évoluer au cours du projet en fonction des contributions de chacun.

Exit donc les spécifications-contrat détaillées, rassurantes mais figées. En fait, comme elles ne sont jamais parfaites, elles constituent un fardeau à l’origine des conflits client/fournisseur classiques sur les délais de livraison. Les spécifications deviennent alors le support d’un dialogue, un des outils permettant de transmettre aux développeurs la vision du produit. Et le dialogue ne prend fin qu’à la livraison.

Détailler n’est pas gagner

Ceci est un enseignement largement généralisable : combien de plannings hyper détaillés qui ne seront pas respectés, dès le premier jour ? Combien de contrats de 50 pages à peine lus qui ne serviront à rien lorsqu’on se sera finalement aperçu d’un malentendu fondamental sur le fond ?

Le détail rassure mais fait courir le risque d’oublier l’essentiel. La 25e décimale de ce pi est-elle exacte ?
Pi = 31,415926535897932384626433832795028841971693993751058209749445923078164062862089
98628034825342117067 ???  Je vous laisse vérifier…[1]

La culture de la simplicité est très difficile à obtenir. La simplicité est hautement compliquée… 1/2 g t² Peut être vous souvenez vous de cette formule de la chute des corps. Il aura fallu attendre Galilée et Newton pour avoir une formule aussi simple, qui néglige les frottements de l’air, mais juste dans le cas général. Tout le monde n’est pas Newton. Mais c’est en cherchant des résultats simples et concis plutôt qu’à produire un pavé de 200 pages qu’on a de plus de chance d’aller dans la bonne direction.

La culture client / fournisseur

La culture client / fournisseur interne a sans doute de nombreux bénéfices. L’un est sans doute de permettre une lisibilité des processus internes, et un découpage en « livrables » intermédiaires. Néanmoins, dans beaucoup de cas, elle conduit à des surcouts par empilement des besoins et méconnaissance des contraintes des autres. C’est ce que nous appelons la complexité technique :

• « Le produit est trop cher parce que ces incapables du service achats n’ont pas su me trouver ma pièce au bon prix. Ils n’ont pas respecté leur SLA ! » (Service Level Agreement) Mais bien sûr, j’ai oublié de leur dire que 3m était une longueur approximative, et que j’aurais bien pu me satisfaire du standard de 3,02m.
• « J’ai spécifié une colonne pour le mois et une autre pour la date. Ce n’était pas vraiment ce que je voulais, ça a rallongé mon projet d’un mois et maintenant, je ne peux plus changer. »

Cela vous rappelle quelque chose ? La co-écriture du produit entre marketing et développement est fondamentale pour l’efficacité globale du projet. La discussion des interfaces (logicielles, physiques) entre deux équipes doit toujours être négociée et non spécifiée.

Itérations

De pair avec ces spécifications flexibles, des processus itératifs adaptés aux changements sont nécessaires: le logiciel est développé par incréments (sprint) successifs et périodiques.

Une validation est effectuée en fin de Sprint (plutôt qu’en fin de projet), « quelque chose » est livrable en fin de Sprint, il est possible d’ajouter des fonctionnalités non prévues à chaque Sprint, les codes précédents sont optimisés (Re-engineering), une analyse du Sprint est réalisée pour préparer d’éventuelles formations, améliorer des process et permettre les transferts de connaissances en interne.

Les Sprint sont typiquement de 15 jours. La durée peut être adaptée au projet :

• Deux heures pour la préparation d’une présentation
• Quelques semaines pour un projet industriel lourd.

La bonne durée équilibre la possibilité de voir quelque chose de concret en regard de la stabilité du besoin et de la latitude d’interprétation.

Ces méthodes peuvent réellement inspirer des projets aussi divers que la préparation d’un séminaire ou le lancement d’un nouveau produit. Nous avons vu ainsi des clients demandant des plannings détaillés à la demi-heure d’un séminaire de 3 jours, alors qu’il était clair que le planning devait s’adapter aux réactions des participants.

Les estimations sont toujours fausses

Au lancement du projet, les estimations sont absolument nécessaires, mais forcément fausses : le projet n’est pas encore délimité, les difficultés ne sont pas visibles, les estimations sont faites par le management ou le marketing plutôt que par les opérationnels, les résultats d’un projet/d’une équipe sont transposés à un/une autre, sans tenir compte de leurs spécificités…

Les aléas du projet choquent notre sens rationnel et notre optimisme humain. Mais les défis techniques, les changements, les contretemps, les erreurs sont inévitables. S’il n’y en a pas, on peut réellement se demander si le projet crée réellement de la valeur ! Il faut donc accepter l’imprévisibilité et la gérer en estimant des portions de projets et en révisant les estimations régulièrement.

Bon du premier coup

Vient ensuite la question de la qualité. Le « bon du premier coup » est toujours largement supérieur à la « qualité statistique ». Si le flacon de shampoing ne sort pas de la ligne car une simple barre détecte que le bouchon n’est pas bien enfoncé, vous pouvez corriger immédiatement et vous êtes certains d’une qualité à 100%, bon marché. Un niveau impossible à atteindre par contrôle a posteriori.

Comment l’opérationnaliser ?

• Déjà par la culture : éviter les « on corrigera plus tard », de la faute d’orthographe qui sera détectée par l’éventuel correcteur, au « bug » grave qui est censé être détecté par la validation / qualité.
• Protéger ses équipes du « crunch mode » : phase de travail acharné pour satisfaire le deadline. L’augmentation de cadence se paye par une perte en qualité qui elle-même peut engendrer des contretemps.
• Mettre en place des contrôles immédiats : cohérence des résultats, validation par le client des itérations.
• Avoir des outils propres et lisibles : le code informatique doit être aussi propre que les postes de travails de Toyota!

La relecture par des pairs (des plans, du code, de la présentation, du business case, etc.) est une bonne méthode : on s’applique lorsqu’on sait qu’on sera relu. Par respect, on fournit une matière claire, propre et correctement présentée.  Le retour sur investissement est généralement immédiat.

Veille et investissement

Enfin, l’incontournable des bons livres de management et d’organisation personnelles : commencer par l’important et non l’urgent. Si l’on s’inspire encore des développeurs, ceux qui sauront rester au-dessus de la mêlée sont ceux qui auront su rester sans arrêt aux aguets des derniers progrès de l’état de l’art, et qui ainsi pourront choisir le bon modèle, outil, langage, framework, en fonction du problème à résoudre.

Il est souvent tentant et rassurant de passer du temps à régler les affaires courantes, alors que la veille et l’investissement semblent plus aléatoires. Pourtant, il est généralement plus efficace de trouver un moyen de régler définitivement un problème, en trouvant une solution existante, en l’automatisant ou en le délégant (« apprenez à un homme à pêcher et vous le nourrirez toute sa vie »), qu’en le résolvant soi-même. Même si la recherche de la solution pérenne prend deux ou trois fois le temps de la résolution simple, la rentabilité est généralement très rapide.

Finalement, l’apparente révolution de « l’agile » dans le monde informatique est riche d’enseignements dans la gestion de projets divers. On peut argumenter qu’elle est dans la continuité des méthodes « qualité » débutées dans les années 70. Néanmoins, cette « qualité » a été tellement mal interprétée, et a conduit à tant de classeurs et manuels rassurants, dormants paisiblement dans des armoires, que nous pensions utile de refaire un tour d’horizon des méthodes « disruptives » permettant de mettre sur le marché un nouveau produit toutes les semaines et non plus tous les ans, le tout sans surcoût.

Morand STUDER

 

[1] La 25e décimale est juste, mais vous aviez bien évidemment noté que la virgule était mal placée…