Comment commencer?

• 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

• 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

Les enseignements

• 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

• 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

• 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