%TOC%

Financement

Je limite le propos de cette page aux TDs et aux orientations logicielles.

%PROBLEM-STATEMENT%

Le paradigme des équipes assemblées pour une longue période (voir DevOps %--% Longévité) pose différents problèmes aux organisations orientées projets. En effet, le mode projet présuppose le démantèlement de l'équipe (ou des équipes) une fois le projet réalisé alors que, bien souvent, l'équipe n'aura eu le temps que de s'occuper de la toute première version du projet en question, étape importante s'il en est, mais seulement la première étape%%: la construction.

En créant des équipes de longue durée, et des équipes d'équipes de longue durée, qui se consacrent à améliorer sans relâche les solutions construites et à les maintenir, l'approche traditionnelle du financement des initiatives est bouleversée.

En créant des équipes pluri-disciplaines qui déterminent elles-mêmes les caractéristiques des produits à imaginer, le rôle du Management évolue vers de nouvelles contrées où l'Humain devient la denrée la plus précieuse à chérir, qu'il soit à l'intérieur de l'organisation ou à l'exterieur. Le Management devient protecteur de l'autonomie , la cultive même, il devient le gardien du sens qu'il ne fournit pas comme une aumône mais plutôt comme un champ des possibles dont chacun doit se saisir pour y permettre l'expression de son propre épanouissement. Le Management se charge de donner les moyens de la maîtrise des sujets qu'il faut aborder pour que tout ceci puisse se déployer autrement qu'en déclaratif d'idéal. On en vient presque à se demander si, au fond, il s'agit même de fournir le financement du developpement de %proservs% ou s'il s'agit de financer la construction d'équipes, leur mode de fonctionnement, leur empathie, leurs interactions %...% et leurs résultats objectifs. Quoi qu'il en soit, là encore, c'est toute l'approche du financement qu'on vient chambouler.

Rappel

Le cycle de vie générique d'un produit ou d'un service est une courbe en cloche classique. Il comporte 4 grandes phases (Introduction%/%Lancement, Croissance, Maturité et Déclin) précédées de sa phase de construction%/%mise au point.

Cycle de vie générique d'un %proserv%
Cycle de vie générique d'un %proserv%

L'équipe %DevOps% existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation. Ce qui est vrai d'une équipe %DevOps% est tout aussi vrai, voire davantage, pour cette construction qui rassemble diverses équipes au sein d'un programme%%: une sorte d'équipe formée d'équipes.

Énoncé du problème

Le problème auquel on fait face c'est que les entreprises financent très souvent des projets et non des produits. Voici ce qu'elles financent (rose vs. vert) %...%

Financement Projet vs. financement %proserv%
Financement Projet vs. financement %proserv%

Comme le prévoit le modèle de %AUTHOR.Bruce Tuckman% depuis 1977[1] , et précisément pour cette raison, une fois le projet terminé l'équipe est démantelée.

Le financement en mode projet appelle au démantèlement de l'équipe
Le financement en mode projet appelle au démantèlement de l'équipe

%...% et c'est rigoureusement là que se situe le problème car on se trouve à démanteler une équipe au moment précis où elle en arrive à être performante et tout ce qui sera évolution future du %proserv% fera immanquablement face à l'obligation d'en repasser par les phases de forming et storming.

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%%:

De l'idée à la version 1.0 (1 cycle)
De l'idée à la version 1.0 (cycle)

%...% 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%% (MMPMinimum 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%%:

From MVP to Rollout (2 cycles)
From MVP to Rollout (2 cycles)

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%%!

Une période de 40 semaines, soit une grossesse%%![%...%] Ainsi, il était demandé de pouvoir financer 40 semaines de fonctionnement de chaque équipe.

Start %--% Stop %--% Start %--% Stop, etc.

Comme nous venons de le voir, si l'entreprise n'en vient pas à financer un %proserv%, 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 %AUTHOR.Backman% %%:

Le problème du Start-Stop-Start-Stop illustré%%: chaque goutte est une fuite de ressources
Le problème du Start-Stop-Start-Stop illustré%%: chaque goutte est une fuite de ressources

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%%:

Éviter les transitions inutiles
Éviter les transitions inutiles

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, %PERSON.Josep Maria Bartomeu%, demander à son entraîneur, %PERSON.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 %PERSON.Lionel Messi% pour plusieurs années, pareil pour %PERSON.Griezmann%, pour %PERSON.Sergio Busquets%, %PERSON.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.%...%

La formation d'une équipe de foot; ses ajustements successifs dans le temps%%: un processus qui se répète.
La formation d'une équipe de foot; ses ajustements successifs dans le temps%%: un processus qui se répète.

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).

Nouveau type de financement

Il résulte des développements fournis ci-avant que l'orientation du financement sur base des projets n'est pas le mode de financement le plus avisé, non pas qu'il soit injustifiable ni inapproprié dans une série de circonstances, mais tout simplement parce qu'il s'accommode mal du nouveau paradigme lié à l'établissement d'équipes assemblées sur le long terme, un paradigme convoqué régulièrement en matière de Transformations Digitales ou Agiles. Pour une série d'autres circonstances, le financement de projets reste le plus idoine, justement quand on a affaire à des projets.

Le changement de mode de financement est difficile à mettre en place car il bouscule le fonctionnement de l'entreprise au travers des trois couches%%: Aspirations, Intégration et Usine. C'est un des défis des Transformations Digitales qu'il faut aborder par une conduite du changement progressive et néanmoins rigoureuse.

L'argumentation passe par la prise en compte de l'émergence de l'économie de la connaissance, par la juste prise de conscience de la multiplication de coûts qui ne se transforment jamais en valeur activable, par l'allongement des délais, par la frustration des travailleurs de la connaissance qui en viennent à vouloir échapper à ce qu'ils considèrent être absurde, etc.

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 %proserv%, 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.

Une proposition d'horizon de financement; ce qui importe n'est pas ligne de temps, purement indicative.
Une proposition d'horizon de financement; ce qui importe n'est pas ligne de temps, purement indicative.

La lumière est toujours verte sauf quand %...% elle devient rouge, et elle peut devenir rouge à tout moment.

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 %proserv% 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 %AUTHOR.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 %proserv%. Ce financement épouse le cycle de vie du %proserv% 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.

%LVD% 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.

Les 3 couches (ou niveaux)%%: Aspirations, Intégration, Usine.
Les 3 couches (ou niveaux)%%: Aspirations, Intégration, Usine.

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 %LVD% 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%%:

De la demande à la construction en passant par l'acceptation et le financement. Vue Kanban.
De la demande à la construction en passant par l'acceptation et le financement. Vue Kanban.

É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 %proservs% dont elle a la charge.

Un %proserv% 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 %TDs%, 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 %TD% 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%%:

Kata de la %TD% : une manière de braver l'inconnu de manière ordonnée.
Kata de la %TD% : une manière de braver l'inconnu de manière ordonnée (durées indicatives)

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.

%LINKS%
( ! ) Fatal error: Uncaught Error: Class 'trql\tag\Tag' not found in D:\websites\lvid.org\www\httpdocs\content\funding.html on line 715
( ! ) Error: Class 'trql\tag\Tag' not found in D:\websites\lvid.org\www\httpdocs\content\funding.html on line 715
Call Stack
#TimeMemoryFunctionLocation
10.0007358800{main}( )...\index.html:0
20.0012359360include_once( 'D:\websites\lvid.org\www\httpdocs\index.html' )...\index.html:2
30.0027455624include_once( 'D:\websites\lvid.org\www\httpdocs\template\lvid.html' )...\index.html:2
40.04232824304getFileContent( )...\lvid.html:251
50.04402908744include_once( 'D:\websites\lvid.org\www\httpdocs\content\funding.html' )...\lvid.html:353