DSI : Livrer plus de valeur pour moins d'argent ? oui, mais comment ?

78% des DSI estiment que la pandémie a eu un impact « grave ou majeur » sur leur organisation.

12 novembre 2020

– 6 min de lecture

Séverin Legras

Directeur Agilité, Projets & Produits

Gartner estime que les budgets des DSI vont baisser de 8% en 2020 par rapport à 2019.

Dans ce contexte, c’est toujours la même sempiternelle question qui revient : comment faire plus quand on a moins d’argent ?

Il n’y a pas de solution miracle

Si la réponse à cette question était si simple, quelqu’un en aurait fait une méthode et serait devenu probablement très riche en très peu de temps.

Pas de solution miracle donc, mais peut-être des pistes de solutions à chercher dans les modes de fonctionnement de certaines équipes.

Première piste : dépenser moins.

Maigrir : lean, lean, lean…

Il s’agit ici d’optimiser les processus, de standardiser et d’automatiser au maximum pour réduire les coûts. L’approche Lean et ses dérivés dans l’industrie, l’IT ou le Management contient tout un tas de méthodes pour arriver à cet objectif. Cet article à ce sujet est très intéressant : “Sorry, But Lean Is About Cost Reduction…” et identifie certaines pistes :

Eliminer les gaspillages (c’est ce qui est le plus connu dans Lean et parfois on s’arrête là).
Analyser et catégoriser les coûts et s’attaquer aux coûts non justifiés
Rationaliser les activités
Supprimer des postes (mais pas les personnes que l’on emploiera à travailler sur le système)

… Oui mais pas n’importe comment !

Vous noterez que cet article au titre provocateur insiste finalement sur le fait que l’approche Lean n’a pas pour seul but de réduire les coûts, mais permet de le faire si on l’adresse de manière globale et intelligente.

Sur ce point, considérer qu’il est possible de réduire les coûts en supprimant des postes et en demandant toujours plus aux employés a peu de chance d’être rentable. Les coûts cachés ne sont pas loin : augmentation du turnover, de l’absentéisme, désengagement.

Par exemple, cette étude montre qu’une implémentation d’une approche Lean qui ne serait centrée que sur les aspects méthodologiques au détriment des aspects humains peut conduire à une augmentation de 82% du nombre d’arrêts maladie et de 62% de leur fréquence moyenne. En effet, une culture du process à outrance peut conduire à une diminution de l’autonomie et du contenu cognitif du travail, deux facteurs jouant sur la motivation intrinsèque du travailleur comme nous le rappelle Dan Pink dans cette vidéo “la vérité sur ce qui nous motive”.

Simplifier

Vous connaissez les 4 valeurs du Manifeste Agile ? Normalement oui.

Vous connaissez les 12 principes sous-jacents ? Moins sûr n’est-ce pas ?

Je les relisais récemment et l’un d’entre eux me semble totalement aligné avec le thème de cet article : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Apprendre à faire simple pour travailler moins et donc dépenser moins, vous en avez forcément entendu parler.

Innovation frugale vous connaissez ? Allez lire cet article où Navi Radjou nous dit :

“L’objectif est également de faire des produits simples, robustes et durables. Et d’aller vite.”

Qu’est-ce qui nous empêche de faire pareil dans la DSI ?

Planifier juste à temps et pas tout le temps : roadmap produit, sprint planning, et basta !
Estimer par comparaison plutôt que chiffrer : j’ai réussi un jour à réduire à 45 minutes une session d’estimation d’une équipe de 8 personnes qui durait d’habitude 1 journée entière, et qu’ils réalisaient une fois par mois. Je vous laisse faire le calcul des économies réalisées. De mon côté les remerciements des participants de ne plus avoir à subir cette journée infernale m’ont suffit.
CoProj, coPil, CoStrat, ComInvest, etc… Privilégiez la transparence et la visibilité à froid (emails, supports de communication) et ne participez à des comités que si des décisions importantes sont à prendre. Sinon traitez les petites décisions en point à point.
Développeurs, écoutez Uncle Bob et codez proprement avec Clean Code : Keep it simply stupid !

Antoine de Saint-Exupéry annonçait d’ailleurs le Lean et l’Agilité avant l’heure :

La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.

Investir

Comment ? Dépenser moins en investissant ? Mais qu’est-ce qu’il raconte ?

Et pourtant : investir au début et régulièrement permet d’économiser sur la durée.

Pas le temps d’industrialiser les tests, il faut qu’on produise de la valeur, c’est notre PO qui l’a dit.

Expliquez donc à votre PO que produire du code sans automatiser les tests aujourd’hui est plus rapide et moins coûteux, mais qu’il est probable qu’il devra repayer une toute nouvelle application dans 3 ans quand celle-ci sera impossible à maintenir.

Nous pouvons regrouper toutes ces pratiques d’automatisation (des tests, des déploiements, de l’infrastructure) sous le terme chapeau de DevOps (je préfère parler de BizDevOps). Ces pratiques et outils nous servent à faire des économies :

moins d’évaluation et de gestion des risques en amont car on teste plus tôt et on obtient rapidement les feedback des utilisateurs
moins de charges de recette manuelle qui ont tendance à augmenter de manière exponentielle avec le temps
moins de temps perdu à bricoler parce qu’on n’a pas à disposition les bonnes données ou l’environnement pour les tests de performances (coucou Infrastructure as code)

Sans oublier que BizDevOps, c’est avant tout un mode de fonctionnement qui favorise les interactions et la collaboration. Qui n’a jamais entendu une phrase du type : « Mon job c’est développeur, …peu importe ce qui arrive …je développe » ? Phrase qui annonce de bien mauvaises nouvelles dans quelques sprints…

Deuxième piste : produire plus de valeur

Prioriser

Cela fait plus de 10 ans que je travaille autour de l’agilité. Ce qui m’avait passionné dès le début, au-delà de l’amélioration des interactions et des relations humaines qui en découlent, c’est la priorisation par la valeur. Je ne sais pas combien j’ai fait d’ateliers avec des Product Owners (PO) pour les aider à appliquer ce principe si simple à énoncer, si difficile à mettre en œuvre.

Évidemment, aujourd’hui tout le monde est d’accord sur le principe de faire d’abord ce qui a le plus de valeur. Il y a 10 ou 20 ans, ce n’était pas si naturel, puisque de toute façon il fallait tout faire, alors pourquoi ne pas commencer par le plus facile, ou le plus difficile…

Avec mon équipe de coachs agiles, nous avons créé une école pour les PO d’une grande entreprise leader du e-commerce. Nous avons dédié un module entier d’½ journée à la valeur. Pas à la priorisation, mais à la représentation de la valeur. Car c’est un travail qui peut être extrêmement complexe. Il consiste à identifier les drivers ayant un impact sur la valeur et à les catégoriser : risques, valeur intrinsèque, valeur d’investissement, technologies…

En travaillant sur la priorisation du backlog, le processus de développement en agile permet donc, pour un coût constant, de livrer en premier des fonctionnalités qui génèrent plus de valeur.

Alistair Cockburn nous propose d’ailleurs la définition suivante :

“Agile is early delivery of Value and less bureaucracy”

Comprendre et mesurer

Pour produire plus de valeur, il faut probablement développer sa compréhension des utilisateurs et des clients.

Et pour aller plus loin que cette simple phrase, j’aime beaucoup la combinaison des 3 approches Design Thinking + Lean Startup + Agile :

Design Thinking ou l’approche centrée utilisateur vise à se mettre à la place du client/utilisateur pour bien comprendre quels sont ses problèmes.
Lean Startup permet de poser des hypothèses sur les solutions à mettre en oeuvre en face de ses problèmes, et de boucler très vite pour savoir si nos hypothèses sont bonnes, ou pas.
Le développement Agile permet d’organiser le processus de livraison des fonctionnalités de sorte que ce soit régulier (itératif) et incrémental en priorisant par la valeur (comme vu précédemment).

Si même le Gartner le dit…

La combinaison de ces 3 approches est pour moi indispensable dans la réussite d’un produit car on peut très facilement en arriver à développer vite et bien des fonctionnalités parfaitement inutiles. J’intègre tout cela dans tous mes accompagnements pour product owners et product managers.

Au final : lean et agile, la solution ?

Ce qui définit l’Agilité, c’est cette importance donnée à l’apport de valeur plus qu’à la réduction des coûts. Il y a bien sûr une recherche d’efficacité, mais surtout d’efficience.

Avec plusieurs années d’expérience derrière moi, une combinaison des 2 est probablement une bonne approche : optimiser au maximum ce qui va être répétitif (tests, déploiements…) et accélérer au maximum le processus de création de valeur (priorisation, less is more…).

Comme dans un bon cocktail, tout est question de dosage et de vision globale : pour avoir un système efficient, il se peut que certaines parties du système ne soient pas optimisées au maximum, générant de fait une capacité à innover et à créer plus de valeur.

Pour arriver à trouver ce bon dosage permettant de produire plus de valeur, plus vite et avec moins d’argent, vous avez probablement besoin d’une bonne équipe produit qui :

Comprend les problèmes réels de ses clients (avec un profil UX par exemple dans l’équipe)
Expérimente fréquemment des morceaux de solutions pour mieux comprendre son écosystème et valider ses hypothèses (avec le Lean Startup). Cela implique de systématiquement mesurer a posteriori de la livraison les indicateurs liés à ces hypothèses, chose qu’on a parfois tendance à oublier de faire
Développe son produit avec des principes agiles : en favorisant les interactions, en livrant fréquemment des fonctionnalités en production, en documentant le nécessaire et en étant ouvert à des changements fréquents (vous avez reconnu les 4 valeurs du Manifeste Agile ?)
Met en place un système de mesure de la performance et s’organise pour l’améliorer en continu (avec le Lean). Je me permets d’insister sur ce dernier point : la mise en place d’une véritable démarche d’amélioration continue est la base de l’optimisation d’un système. C’est également ce qui fait trop souvent défaut dans les implémentations Agiles qui prennent insuffisamment en compte le changement de mindset nécessaire

J’ai observé personnellement une équipe de 6 personnes (PO, UX, devs) produire en 6 semaines ce qu’une équipe de 12 n’avait pas réussi à finaliser en 6 mois.

Leur différence ? Probablement un peu plus d’expérience (et donc un TJM plus élevé coucou les fausses économies) et surtout une capacité à se poser les bonnes questions.

Rappelez-vous A. Einstein qui disait :

“Si j’avais une heure pour sauver le monde, je passerais 55 minutes à définir le problème et cinq minutes à trouver la solution.”

Attention je le répète : ceci n’est pas une solution miracle. Ca ne fonctionnera pas si votre organisation n’est pas collaborative, si vos métiers et vos IT ne savent pas se parler, si votre management met des bâtons dans les roues plutôt que d’aider les équipes de dev. Mais si vous prenez maintenant ce chemin, ce sera toujours mieux que la situation actuelle. C’est dans les situations de crise que l’Homme est le plus innovant.

Alors faites comme Indy : lancez-vous.