La mise en place de l’agilité chez 24S.com a été une aventure particulière parceque mise en place dans un contexte singulier: en ne partant de rien. A l’époque où je suis rentré dans l’aventure, il y avait 4 salariés. En repartant de 24 Sèvres deux ans plus tard, il y avait un peu moins de 90 personnes.
Ce faisant, il n’y a au moins pas ou peu de résistance au changement, d’autant que les interlocuteurs étaient tous favorables à avancer dans une voie Agile.
Comment commencer?
C’est de loin le plus simple, en particulier dans ce contexte. Pour démarrer à cette époque, dès que l’équipe IT s’est un peu étoffée (6 personnes) nous avons commencer les rituels Scrum standard. Theodo, notre fournisseur de l’époque était spécialisée en la matière. Par conséquent, pas besoin de faire monter les gens en compétences, ils savaient déjà tous travailler en Agile. Cela nous a permis de pourvoir rapidement à la constitution des premières équipes avec Scrum Master, Product Owner et développeurs.
Nous grossissons ainsi pendant quelques mois jusqu’a aller à trois équipes et c’est à ce moment là que les premiers problèmes ont commencés à apparaitre:
- Grande difficulté à synchroniser les trois équipes
- Chacune d’entre elle travaille en silo, sans suffisamment communiquer avec les voisins
- Mauvaise visibilité sur la roadmap, backlogs incomplets, peu compréhensibles
Nous avons alors adapté notre façon de travaillé avec l’aide des Scrum Masters présents et notamment:
- Construction d’un board au niveau Epic qui serait suivi de manière hebdomadaire en présence des Stakeholders
- Introduction du Scrum de Scrum: toutes les semaines les Scrum Master se rassemblaient afin de se synchroniser
- La liste des Features long termes était revue (partiellement) en comité de direction
Clairement, c’est l’agilité à l’échelle qui a pêchée
Les enseignements
Ce mode de fonctionnement nous a dirigé pendant un an et demi jusqu’a la sortie du site. Plusieurs enseignement de cette période:
- Le Scrum de Scrum “standard” est très insuffisant pour synchroniser les équipes. Il faut plus d’informations, de travail en commun, de coordination entre l’ensemble des membres de l’équipe
- Les rôles de chacun n’étaient pas suffisamment clairs: dans mon esprit par exemple, la roadmap revenait de facto au PM étant donné que c’est à lui de gérer les priorités. Mais le DG de l’entreprise, fort de son expérience Cycle en V voulait une roadmap fournit par la DSI. S’en ai suivi un conflit: j’étais responsable de mettre dans le temps des priorités pour lesquelles je n’étais pas en accord ou pour lesquelles je n’avais pas les informations nécessaires. Par ailleurs, cela induit un autre biais: ce ne sont pas les sachants qui se prononcent. ERREUR! La roadmap doit émaner en termes d’estimation de ceux qui savent, c’est-à-dire les équipes et personne d’autre. Sinon on se ment à soit même.
- La vision Agile n’était, finalement, pas partagée par tous: spécifications écrites en sous-marin, incapacité à découper itérativement les sujets, incapacité à les clôturer, tentative de réintroduction cachée d’un Cycle en V, etc. Nous avons soufferts de beaucoup de manques dans la gestion du produit mais c’est très courant. Quasiment tous mes clients subissent ce problème. A mon sens, le meilleur moyen de régler ce point est d’établir un vrai équilibre des pouvoirs entre tout le monde. Et cela ne peu se faire qu’avec un décideur qui a une compréhension des deux parties: techniques et métier.
Ce que nous aurions pu faire différemment
A posteriori je me rend compte que nous avons reconstruit un mode de gestion proche de ce qui se fait en SAFe mais sans le savoir réellement (j’ai découvert ce framework à cette occasion). Et il nous manquait encore quelques ingrédients pour que ça fonctionne bien.
Notamment:
- Faire un PI PlanningLe PI Planning est l’exercice qui nous a sûrement le plus manqué rétrospectivement. Nous avions eu l’intuition de faire des réunions de groupe mais pas d’aller jusque là. Si nous avions fait cet exercice nous aurions régler le manque de visibilité, le manque de coordination et d’anticipation que nous avions
- Gérer le projet avec un tryptique ayant des pouvoirs similairesNous avons souffert également de la répartition des rôles sur le pilotage opérationnel: Un DSI (moi) rattaché au DG, un directeur produit rattaché au DG et un architecte rattaché à moi directement. Cette organisation était une erreur: le rattachement du DSI et du Directeur Produit directement au DG a créé un conflit qui n’a pas pu être réglé correctement. L’absence d’architecte dans le processus de décision a également pénaliser les priorisation d’un point de vue technique et fait grandir la dette.Une organisation basé sur 3 personnes (comme en SAFe) avec un responsable produit, un responsable technique et un responsable systémique est la meilleure façon d’avancer conjointement sans rentrer dans un guerre intestine et malsaine. Un seul de ces trois représentant devrait reporter au DG et ca doit être le réprésentant de la systémique (RTE en SAFE)
- DevOpsLe DevOps n’a pas été suffisamment considéré: ni par les stakeholders (qui ont considérés ça comme des techniciens sans intérêt), ni par les développeurs (qui ne voulaient pas reprendre la responsabilité des environnements et n’avaient pas tous les compétences pour).
- Des managers AgileMême s’il nous a été demandé de faire ce projet en Agile, les réflexes des dirigeants de l’entreprise étaient encore très ancrés dans le Cycle en V: contrôle des horaires, “on travail mieux sous la pression”, jugement à l’emporte pièce sur des estimations de travail à faire, remarques parfois cinglantes qui ne sont pas dans les valeurs de bienveillance, manque d’empathie également. Ce point n’a pas tué le projet mais il en a rendu la vie plus difficile. Le tout pour simplement répondre aux angoissent de personnes mal préparées et qui n’absorbe pas la pression mais la diffuse sur les équipes.Autrement dit, nous avons manqué de Servant Leader
En revanche, deux choses insufflées par le DG nous ont sauvées:
- Sortir des versions alpha (fermées au public) du site le plut tôt possible pour avoir un feedback client. C’est ce que nous avons fait et cela a vraiment sauvé le projet.
- Avoir une vision de ce que devait être le produit final