Financement

Durée de la construction vs. modèle de Tuckman

Si on s'oriente, comme le font la plupart des équipes agiles, vers la création d'un produit avec une forme de processus d'idéation qui précède la véritable construction, nous dégageons la vue suivante :

… l'idéation est un processus dont on essaye de sortir le plus rapidement possible; on en limite le financement / mise de fonds à maximum 8 semaines. Dans le schéma qui précède, l'idéation est présentée comme l'horizon de découverte (Discovery Horizon). Ensuite, on se met en position de démarrer une construction standardisée / industrialisée (on quitte le mode idéation) ce qui est une période assez variable d'organisation à organisation — Metamorphosis dans le schéma du dessus. Enfin, on entame le véritable travail afin de pouvoir mettre sur le marché une version publique  (MMP — Minimum Marketable Product). On peut donc se baser sur une durée d'environ 21 semaines pour la période de construction (pour des initiatives d'une certaine ampleur, et avec 1 seul cycle de mise sur le marché).

En quel délai une équipe passe-t-elle de la phase Forming à Performing ? C'est très variable évidemment ! On a même vu que certaines équipes ne sortaient jamais de la phase de Storming. De l'observation de projets normaux, ni dans l'extrémité positive, ni dans l'extrémité négative, il ressort que la période de Forming dure en général de 1 à 2 mois, que la phase de Storming dure de 1 à 6 mois, qu'il faut entre 6 mois et 1 an pour la phase de Norming, on en est souvent en moyenne à une durée globale qui oscille en 7 et 12 mois, soit entre 30 et 52 semaines.

Le problème est donc le suivant : en moyenne on arrive à démanteler une équipe projet souvent plus vite qu'on peut la faire sortir de la phase de Storming. M'occupant d'un incubateur digital pour une grosse banque belge, en qualité de Head of Scale-Up j'avais formulé la durée minimale d'incubation (exposition aux methodes agiles) en les termes suivants : idéation (8 semaines), cycle #1 de construction (16 semaines, ± 4 mois) et cycle #2 de construction (aussi 16 semaines), soit un total de 8 + 16 + 16 = 40 semaines. En voici le schéma :

La proposition a été adoptée par l'Incubateur Digital et a été utilisée pour calculer l'onbording d'équipes afin de ne pas dépasser la capacité d'accueil maximale. Il permettait aux équipes de dépasser (habituellement) la phase de Storming et il leur permettait de connaître l'expérience de la mise en production plusieurs fois : lors du premier cycle, on les "obligeait" à effectuer une mise en production au moins 1 fois, tandis que dans le cycle 2, on les exhortait à effectuer des mises en production plus régulières, ce que vous voyez illustré dans le pipeline de déploiement : v 1.0, v. 1.5 et v 2.0. Ainsi, il était demandé de pouvoir isoler les équipes de la partie de l'organisation d'où elles provenaient et de financer 40 semaines de leur fonctionnement. Ce type de financement échappait déjà, en partie du moins, au financement mode projet mais nous étions encore loin d'une solution globale qui eut permis de financer de long- lasting teams !

Start — Stop — Start — Stop, etc.

Comme nous venons de le voir, si l'entreprise n'en vient pas à financer un produit / service, ou mieux … une équipe, chaque évolution revient à démarrer un nouveau projet, mais aussi à clôturer le précédent. Ce ne sont pas des opérations neutres financièrement; leur poids dépend de la gouvernance en place. Dans des environnements Prince 2, il faut se livrer à une série d'activités comme les Mandate, Brief et autre Project Initiation Document qu'il faut non seulement rédiger mais également faire approuver par différents comités. Chaque démarrage et fin intermédiaires représente un surcoût comparé au financement d'une équipe assemblée sur le plus long terme, sans même parler de l'impact induit par la phase de Storming du modèle de Backman  :

Toute la question des long-lasting teams est d'éviter les coûts inutiles liés aux multiples courbes d'apprentissage, liés à la répétition des phases de Storming, liés à la rédaction de rapports à la valeur ajoutée douteuse, liés aux délais incompressibles entre chaque démantèlement et démarrage, … Les long-lasting teams évitent les transitions inutiles. Laissez-nous continuer, crient les Agilistes :

Comme une équipe de foot ^[2] …

Si nous entrevoyions nos équipes comme des équipes de sport, nous verrions le problème sous un angle complètement différent. Imaginez le président du club de Barcelone, Josep Maria Bartomeu, demander à son entraîneur, Ronald Koeman, d'assembler une nouvelle équipe à chaque match de championnat. Cela nous paraîtrait absurde.

Nous savons tous comment procèdent les clubs de foot : ils se constituent un noyau et puisent dans ce noyau au fil des besoins auxquels il va falloir répondre. Ils créent des long-lasting teams ! On signe Lionel Messi pour plusieurs années, pareil pour Griezmann, pour Sergio Busquets, Frenkie de Jong, etc. Certains joueurs partent, même en cours de saison, d'autres arrivent pour renforcer le noyau. Tout cela est entendu … mais on ne vire pas toute l'équipe.…

C'est ce paradigme-là que je recommande d'appliquer. Je ne suis pas le seul à l'évoquer. SAFe (© Scaled Agile, Inc.), un framework longtemps décrié mais qui a réussi à s'imposer comme le standard de facto de l'agilité @scale, en parle en long et en large sur son site web (ex. Agile Teams).

Une proposition; pas un dogme

Il importe peu que l'horizon soit large et (très) lointain. Je présente ici un principe d'alternative au financement en mode projet et non une règle inviolable. Je pose néanmoins comme contraintes fortes (1) la nécessité de financer une équipe et non un projet, (2) d'avoir le temps de faire de l'équipe un groupe soudé et homogène, et (3) la volonté de gommer les coûts cachés.

Ce qui compte avant tout c'est de bien ancrer la responsabilité générale du démarrage : lorsque le Go est donné pour construire un produit / service, s'ensuivent une série de conséquences dont le financement de long terme de l'équipe (ou des équipes) qui sera/seront assemblée(s) pour construire la solution mais aussi pour la maintenir et la faire évoluer.

Une fois le Go donné on prend tous conscience qu'on a donné un accord formel pour lancer le train. On ne lui imposera pas, à chaque arrêt en gare, de devoir demander l'autorisation de pouvoir continuer son parcours. Le conducteur du train sait quelle est sa destination et considérera que la lampe de trafic est toujours verte par défaut. Il sait aussi qu'en fonction de facteurs qui sont au-delà de son contrôle, le trafic peut être interrompu ou qu'il peut être détourné vers une autre destination. Le signal peut passer au rouge à tout moment ce qui donne au management toute la latitude d'intervenir s'il le juge opportun.

Dans l'illustration ci-dessus, je propose de fontionner avec une forme d'idéation dont on limite l'enjeu à 4 semaines. L'organisation décidera elle-même de ce qui lui est acceptable. Pour autant, le principe reste le même : l'diéation est limitée dans le temps et si elle ne débouche pas sur un concept de produit / service qui convienne à toutes les parties, tout s'arrête.

Si un MVP d'idéation est dégagé (les plans du MVP), on doit assembler les personnes qui ont les meilleures aptitudes à construire le MVP. C'est un processus qui prend un peu de temps et qui dépend pour beaucoup de la disponibilité de ceux qu'on envisage de rassembler en une équipe. C'est ce que le schéma du dessus décrit dans la phase de métamorphose.

Ensuite, je présente des cycles de 13 semaines en ce que cette durée est parfaitement synchronisée avec la notion de trimestre. Pour autant il n'est absolument pas question d'attendre le début d'un trimestre dans l'année pour commencer les activités. Dès qu'on est prêt, on est prêt ! Encore une fois, l'organisation choisira la durée qui semble adaptée à sa situation. Un point d'attention cependant : prenez garde à l'effet Storming décrit par Tuckman, surtout pour les équipes nouvelles.

Le financement est alloué au soutien de l'équipe (et investissements nécessaires). C'est donc plus une équipe (ou des équipes) qu'on finance qu'un produit / service. Ce financement épouse le cycle de vie du produit / service qu'on se propose de mettre au point, a priori … infini.

Un budget déterministe : pas d'inflation ou de déflation soudaine !

Présenté comme tel, le Management risque de considérer qu'il signe un chèque en blanc.

En réalité, il n'y a rien de tel. D'abord, l'idéation est strictement limitée. Ensuite, en vertu du principe La lumière est toujours verte sauf quand elle vire au rouge, et elle peut virer à tout moment, le Management a de quoi mettre le train sur une voie de garage, voire de l'arrêter complètement. Enfin, il y a une autre sécurité pour le Management : le fonctionnement en équipes de taille fixe (couplé à un horizon découpé en blocs délimités dans le temps — timeboxing). À fonctionner avec des équipes assemblées sur le long terme et avec grosso modo les mêmes compositions, en profils et nombre, sans recours à des périodes soudaines, ni de ramp-up, ni de ramp-down, il est aisé de budgéter le travail d'une équipe agile (hors investissements). Vous adapterez la formule à votre situation, mais grosso modo, 1 cycle de 13 semaines, avec 7 personnes coûte : 7 x 13 x 5 x 700 € = 318.500 €. C'est clair, efficace et direct. C'est tellement simple que vous pouvez faire ce calcul en pleine réunion avec le tarif journalier moyen qui s'applique à votre cas ! Une année coûte 1.274.000 € pour une équipe. 10 équipes occupées simultanément ? 12.740.000 € ! C'est purement arithmétique, d'un niveau d'école primaire. Parfaitement déterministe. Suivre le budget devient simplissime : il suffit d'appliquer un burndown chart basique. Tout problème budgétaire disparaît comme par enchantement.

Ces 3 garde-fous sont autant de leviers qui rassurent le Management qui sait à tout moment quel est le niveau des engagements financiers. Les mécanismes lui sont donnés pour garder le contrôle à tout moment et il dispose de budgets déterministes. Une situation au final très positive qui le rassérène.

Place du financement

En matière d'organisation software, les initiatives Informatiques peuvent se résumer à un modèle établi en 3 niveaux :

1. Un niveau «supérieur» où se prennent les décisions de lancer les initiatives et de monitorer celles qui sont actives
2. Un niveau «inférieur» où les solutions sont construites
3. Un niveau «intermédiaire» où les solutions individuelles construites sont assemblées pour former des solutions plus larges

Par exemple, quand l'organisation en vient à se doter d'une colonne vertébrale digitale, le niveau «supérieur» est celui qui décide de la validité de l'initiative et qui lui accorde le budget nécessaire. Le niveau «inférieur» est celui qui, au travers d'équipes différentes met au point l'infrastructure nécessaire, crée l'ESB, crée les services et microservices, met en place le monitoring, … toutes solutions distinctes mais qui doivent être assemblées pour générer la valeur attendue (et contribuer à la mission de l'entreprise) et le niveau «intermédiaire» est ce niveau où justement toutes les parties séparées sont assemblées et testées pour former la colonne vertébrale en question.

L(i)VID modélise donc l'organisation en ces 3 niveaux : la couche Aspirations (le niveau «supérieur»), la couche Intégration (le niveau «intermédiaire») et la couche Usine (le niveau «inférieur»).

Sans surprise, le financement des initiatives se décide au niveau de la couche supérieure, la couche Aspirations.

La couche Aspirations — terme générique que j'emploie pour désigner les initiatives, les idées, les projets, les demandes, … — est le théâtre d'une guerre sans merci que se livrent toutes les aspirations, et les femmes et les hommes qui les soutiennent, pour obtenir leur droit à exister, c'est-à-dire gagner leur financement. Les aspirations se battent ainsi entre elles à coup de Business Cases et on attend des Executives qu'ils décident quelles aspirations leur semblent soutenir le mieux la mission de l'organisation et auxquelles on attribuera une partie des ressources dont on dispose.

Puisque L(i)VID recommande le financement d'une équipe (ou d'équipes) et que ce financement suive le cycle de vie du produit/service confié à l'équipe en question, il en découle que le financement qui est demandé est celui d'une équipe long-terme. On ne recommande pas le financement d'un projet, ni en fait d'un produit, mais bien d'une équipe dont la tâche sera d'imaginer le produit/service et ensuite de le maintenir et faire évoluer.

Idéation + construction

Dans le modèle présenté plus haut, je distingue 2 temps : l'idéation (quel est le bon produit/service à créer et quelles en sont les caractéristiques dominantes) et construction (développer le produit/service dont a accouché l'étape d'idéation). Je propose d'accorder 4 semaines à l'idéation et 32 semaines à la construction. Pour la simplicité de l'exposé, je fais l'impasse sur la (normalement) courte période de métamorphose.

L'idéation est un processus qui est une forme de limitation de l'enjeu. Si en 4 semaines, on n'arrive pas à dégager les contours du produit/service, on arrête les frais : la construction n'aura pas lieu. Si l'idéation est ponctuée de manière positive, la construction est lancée.

Ce qui est donc demandé aux Executives c'est d'octroyer un financement minimum de 36 semaines pendant lesquelles on devra être capable de concevoir le produit/service, le construire, le déployer, le mettre en service, le maintenir et le faire évoluer, tout cela en étant capable de dépasser la phase de Storming pour les équipes nouvellement formées.

Le processus se présente comme suit :

Équipe et cycle de vie ou … 36 semaines, voire plus

Une équipe existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation. Sa mission suit l'évolution du cycle de vie des produits / services dont elle a la charge.

Un produit / service on lui souhaite de pouvoir exister pendant de nombreuses années et d'avoir une phase de maturité la plus longue possible car c'est là que le ratio profits / coûts est le plus avantageux.. Ainsi, si on ne demande officiellement que le financement de 36 semaines de fonctionnement (± 70 % d'une année), par une acceptation les Executives reconnaissent néanmoins qu'il faudra fournir les moyens d'existence d'un plus long terme. Ma recommandation est de financer l'équipe de sa création jusqu'à la fin de l'année afin de garder un processus budgétaire simple.

Le financement des aspirations de (très) longue durée

Il est de ces aspirations qu'il n'est pas possible de construire sur la base de cycles rapides. Chacun peut en donner de multiples exemples : on ne construit pas un Airbus A380 en 36 semaines, on ne construit pas Windows en 36 semaines, on ne construit pas une colonne vertébrale en 36 semaines.

Le schéma de financement proposé dans ces cas-là est inadapté dans sa formulation détaillée; pas nécessairement dans son principe général. En tout état de cause, il me faut lever un petit drapeau d'attention.

Puisque je déroule du texte qui met en scène les Transformations Digitales, pourquoi ne pas s'intéresser à l'aspiration du démarrage d'une Transformation Digitale ? Voilà bien une initiative qui s'inscrit dans la durée.

Une Transformation Digitale une tâche d'ampleur qui s'insinue dans tous les interstices de l'organisation. De par son ampleur, les organisations ont tendance à imaginer un programme aux vastes proportions pour encadrer cette initiative. C'est précisément à cet endroit qu'il faut frapper. L'organisation, et ses femmes et hommes, doivent être capables de déterminer les objectifs constituants qui vont permettre de bâtir les étages au fur et à mesure.

il est tout à fait possible de fonctionner par bonds successifs. Chaque bond doit avoir une valeur, une utilité pour un groupe cible. Cette question de valeur et d'utilité est un débat qui mène à diverses controverses, souvent stériles selon moi. Si chaque bond est téléguidé par un pour qui et un pourquoi nous disposons de tout ce qui est nécessaire pour envisager le bond à réaliser. Les autres questions sont purement circonstancielles. Le comment est une découverte permanente comme l'illustre d'ailleurs le Toyota Kata :

Comme exposé, les questions du public cible (le pour qui) et du pourquoi sont suffisantes pour entamer les travaux liés au prochain bond qui devrait rester dans l'horizon d'un cycle ou de 2 cycles maximum. Il n'y a d'ailleurs pas d'obligation à avoir des cycles de durée fixe, mais il s'agit là d'un tout autre débat où je crains d'entrer en conflit avec quelques religieux. En revanche, la méthode impose de disposer de métriques utiles pour pouvoir juger en toute objectivité si le but fixé à été atteint ^[3]

Il decoule de ce qui vient d'être exposé que le financement / funding des aspirations d'une certaine ampleur peut être envisagé comme présenté dans son principe, avec des adapations spécifiques pour les données détaillées.