Organisation des équipes

1. Introduction

Écrire ce livre sans parler de l’essentiel, à savoir les humains, leurs interactions et le travail d’équipe, aurait été un non-sens. Certains penseront d’ailleurs que le chapitre arrive un peu tard. Cependant, nous avons souhaité au préalable développer le fil rouge des éléments techniques et méthodologiques qui contraignent l’organisation lorsqu’il s’agit de délivrer un produit sur un modèle SaaS. Il faut savoir rester humble lorsqu’il s’agit de parler d’organisation ; notre constat est en effet qu’il n’y a pas d’organisation d’équipe plus idéale qu’une autre, tant qu’il y a une cohérence et une synergie entre l’organisation et la raison d’être de l’Entreprise. Encore faut-il bien connaître et partager les éléments constitutifs de cette raison d’être. Or, ces dernières années et, en particulier dans l’industrie du SaaS, on peut constater que de grands bouleversements, parmi ceux décrits précédemment, sont venus modifier en profondeur les modèles organisationnels établis.

Ces transformations voulues ou subies sont toujours et plus que jamais d’actualité. Si nous regardons l’évolution sur les quinze dernières années on peut citer l’adoption massive de l’Agilité, l’arrivée de DevOps, la montée en puissance du Cloud, le passage du mode release au mode déploiement continu, la distribution en mode SaaS avec une disponibilité des services attendue à 99.99 %… pour ne pas dire 100 %. Ces changements de paradigmes organisationnels et métiers ont induit une complexification exponentielle des systèmes qui a, à son tour, eu un impact direct sur l’organisation du travail et des équipes, rendant parfois difficile la distinction de la chaîne de responsabilité. Nous citerons dans cette idée le passage des monolithes aux microservices en passant par la case SOA (Service Oriented Architecture), l’arrivée de Serverless, les MOM (Message Oriented Middleware), l’Event-Sourcing, les machines virtuelles puis les conteneurs...

1. La nécessité d’un cadre à l’échelle

Si dans ses débuts, l’Agilité s’appliquait quasi uniquement à des équipes R&D de taille réduite, ces dernières années ont vu l’avènement de l’Agilité à "l’échelle" et de nombreux Frameworks ont fait leur apparition comme Scrum of Scrum, LeSS, SAFe ou le modèle Spotify. Nous n’allons pas ici promouvoir le nôtre ni réaliser un choix définitif entre l’un ou l’autre. Nous allons néanmoins focaliser notre attention sur certains points de vigilance inhérents à cette montée en volume de l’Agilité et y apporter quelques solutions que nous avons pu expérimenter.

Tout d’abord, il est un fait que l’Agilité n’a pas été conçue "by design" pour des équipes de plus de 10 personnes, ni pour des systèmes de plusieurs millions de lignes de code. Plus précisément, si ces principes (ou piliers) restent issus de bon sens et applicables partout, ce sont plutôt les Frameworks habituels comme Scrum/Kanban ou ScrumBan qui, appliqués à la lettre, ne résistent pas longtemps aux organisations de plus de 30 personnes. Et c’est ce constat qui a donné naissance aux adaptations ou surcouches citées plus haut.

La mise à l’échelle de l’Agilité génère inévitablement un ensemble d’injonctions paradoxales au sein des équipes R&D, avec lesquelles il va falloir jongler en permanence et en réalité trouver des compromis. Cette mise à l’échelle est souvent pointée du doigt par certains coachs Agile qui restent centrés sur un modèle centré sur chaque équipe. Pour autant, ce seul focus ne nous paraît pas suffisant, car l’addition de cinq équipes Agile en bonne forme ne garantit pas un ensemble consistant. De plus, il ne faut pas tomber dans la facilité de faire porter à la mise à l’échelle la responsabilité d’une mauvaise agilité si celle-ci n’est déjà pas appliquée correctement au niveau unitaire...

1. L’importance du recrutement

Le marché du SaaS est un marché sans frontière et donc une compétition mondiale ; c’est encore plus vrai avec l’avènement du télétravail qui devient même pour certains acteurs le seul mode de travail. Comme dans toute industrie, la qualité de la matière première aura un fort impact sur le produit final. Et ici la matière première n’est autre que l’humain.

Pour ces raisons le processus de recrutement doit être parfaitement huilé et en phase avec les objectifs de l’entreprise afin de soutenir sa croissance et non la ralentir. Le recrutement est en effet un puissant démultiplicateur de croissance de l’équipe ; il agit telle une cheminée d’aspiration qui élève le niveau d’une équipe R&D mois après mois, année après année. Lorsqu’il est bien maîtrisé, il devient même un enjeu d’image pour un acteur SaaS.

2. Définir les postes

Il est essentiel dans tout processus de recrutement d’aligner, avant tout, les parties prenantes sur la fiche de poste et les compétences recherchées. Écrire un briefing un peu comme sur le modèle de la fiche persona et s’exercer au préalable en binôme avec le service RH est une bonne pratique. Il s’agit ainsi de transmettre au service RH des éléments de psychologie des profils recherchés qui vont les aider dans un premier temps à détecter les bons signaux et rendre cette première étape efficace. Le manager technique pourra aussi transmettre les bons mots clés ou les parcours types sur lesquels l’équipe RH pourra porter une attention particulière et être capable d’identifier le profil technique. À l’inverse, l’équipe RH peut donner des éléments de décision utiles au manager, en particulier sur les Softs Skills.

Chaque poste ouvert doit donner lieu à une fiche de poste, qui doit être accessible et partagée à toute la société, à commencer par les équipiers eux-mêmes. Ceux-ci peuvent ainsi se projeter sur la dynamique de recrutement, et surtout influer dessus....

1. Introduction

Les projets informatiques sont avant tout une affaire humaine où l’équipe est le bien le plus précieux. Dans notre industrie, la matière première est à 90 % de la matière grise. Partir du bon pied avec un nouveau collaborateur est fondamental dans les organisations Agile, à la fois pour lui-même et pour l’équipe. La capacité d’un projet informatique à intégrer rapidement et efficacement soit un nouveau système, soit un nouvel équipier est un indicateur de santé d’une grande acuité, peut-être même le plus pertinent de tous. Au-delà du plaisir que procure l’accueil d’un nouvel équipier, une véritable équipe SaaS peut (et doit) avantageusement tirer parti de cette phase pour éprouver ses processus et les améliorer. Il convient donc d’y apporter une attention particulière.

Nos différentes expériences ces dernières années ont démontré cette constante : un "ramp-up" long (et donc douloureux) pour un nouvel équipier dans un projet informatique est quasi systématiquement un signal d’alarme sur la qualité du produit, la qualité de code, des processus ou la vie de l’équipe tout simplement. La vitesse d’autonomisation d’un collaborateur peut ainsi aller de quelques jours à plusieurs mois. Dans ce dernier cas, bien souvent, les équipes en place parfaitement conscientes de cet état se retranchent derrière l’excuse d’un produit "complexe" d’un point de vue métier ou technique.

Cette forme de renoncement est un signal qui doit être combattu au quotidien par un travail de fond sur l’architecture comme vu au chapitre Patterns d’Architecture logicielle pour le SaaS, mais ce n’est pas suffisant. Nous pensons que toute l’organisation d’une entreprise, du management à l’ensemble des équipes, doit traiter et valoriser son processus d’Onboarding avec le plus grand soin et que ce moment peut être générateur de valeur, mobilisateur et motivant.

2. Onboarding

a. Processus général

L’étape d’Onboarding doit impérativement...