Dessine-moi un CTO

Pas de réponse tranchée dans ce billet, mais des pistes à explorer...

Ford vs Toyota

• Le modèle tayloriste a assuré à Henri Ford le succès que l'on sait dans l'industrie naissante de l'automobile.
• La méthode Toyota a par contre permis aux entreprises qui l'ont adopté de dépasser leurs concurrentes adeptes du taylorismes.

Pour quoi ?

• Le modèle tayloriste est conçu pour réaliser une produit standardisé, voir unique (la Ford T), avec des structures de production ne nécessitant pas une main d’œuvre qualifiée. Le travailleur est généralement recruté pour la seule force de ses bras.
• Le système Toyota favorise au contraire l'adaptation, en se focalisant à l'origine sur l'optimisation du temps de changement d'outil. Dans ce contexte, l'intelligence individuelle et collective des opérateurs est au contraire fortement sollicitée.

Je vous laisse deviner à quel système ressemble le plus le développement logiciel...

Loi de Conway

« les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. »
— M. Conway

Dit autrement :

“If you have four groups working on a compiler, you'll get a 4-pass compiler”

Faut-il réorganiser votre entreprise ?

"Les entreprises ont recours à la réorganisation comme à un remède miracle au lieu de diagnostiquer leurs maux"
— Peter Drucker

Découpage horizontal vs découpage vertical

• Le découpage horizontal organise les équipes suivant une logique technologique (frontend, backend, mobile, etc).
• Le découpage vertical oganise les équipes selon une logique produit (1 équipe = 1 produit ou 1 gamme).

Dans cet article, Thiga liste les antipatterns, ainsi que les forces et faiblesses associées à ces typologies : 4 grands modèles d'organisation produit.

Cas de l'entreprise à produit unique
Si je suis Spotify ou Deezer, quel modèle me permettra d'accompagner au mieux ma croissance ?
Component team vs feature team — Que choisir ?
Le framework LeSS pourra vous aider à faire un choix et à le mettre en œuvre.

Et Scrum là-dedans
Pour faire simple :
1 produit = 1 Product Owner = 1 à 9 équipes de développement (Scrum + Nexus).

Cas de l'entreprise à produit unique et projets multiples
C'est le cas par exemple d'un éditeur de logiciel B2B : chaque client doit être accompagné individuellement pour l'intégration, le paramétrage, la formation et le déploiement de la solution.

Le plus mauvais choix : des équipes écartelées entre les projets
Avec une organisation purement technique des équipes, on se retrouve souvent à jouer aux petits trains. Les clients stratégiques passent devant les autres, comme le TGV passe avant les TER en cas de retard. Avec à la clé un bad buzz chez les clients TER.
L'origine du mal se trouve dans la parallélisation des projets. Et vous la payez au prix double :

• non seulement vous payez le prix de la gestion complexe des plannings ;
• mais en plus, vous payez le prix du context switching chez les équipes.

A la clé : démotivation des équipes, clients énervés, stress, équipes poussées à la faute du fait du stress et des retards permanents.

Pistes pour améliorer le delivery
Selon le contexte, on peut notamment essayer de :

• gérer certains clients en mode projet (rassemble dans la même pièce toutes les compétences nécessaires) : permet d'éviter que les clients stratégiques perçoivent les effets de notre organisation "startp & stop";
• gérer le portfolio projets en mode Kanban avec un Work In Progress de 1 pour chaque équipe : soulage les équipes et améliore le delivery en évitant le context switching;
• découper finement les incréments du portfolio, pour obtenir un temps de cycle faible : chaque semaine chaque équipe sert au moins 1 client. Fluidifie le delivery.
• sprints très courts (1 jour à 2 semaines) : pour fluidifier le delivery, une fois qu'on a réalisé un découpage fin. Permet à chaque équipe de livrer les clients 1 à 1. Célébrer chaque livraison permet de donner aux équipes un feedback motivant.

Cas de l'entreprise avec plusieurs produits
Dans ce contexte, aller vers un découpage horizontal me semble globalement aller contre l'orientation produit nécessaire.
Cependant, lorsque l'expertise nécessaires à certaines couches techniques est très élevée, les équipes pluri-disciplinaires peuvent manquer d'autonomie. On choisit souvent de mettre sur pied quelques équipes qui mutualiseront les expertises nécessaires (data, infra...). Ces équipes deviennent naturellement des goulots d'étranglement.

Pour conserver un delivery global fluide, il est donc nécessaire de conserver du "slack" dans notre système en ne saturant pas l'emploi du temps de ces équipes. Il est nécessaire de conserver des marges confortables à leur niveau.

Dans le système Toyota, l'optimisation des ressources s'obtient en protégeant ce bottleneck grâce à du stock en entrée. Ainsi cette équipe sera toujours au plus près de 100% d'efficacité. Par contre, notre delivery sera entièrement dépendant du rythme de cette équipe.

Globalement, conserver un logiciel en état de livraison permanent et livrer fréquemment, seront des éléments clés pour conserver une réelle visibilité dans le portfolio... et des clients heureux !