Dans une organisation qui se veut Agile (et il y en a maintenant beaucoup), faut-il séparer la DSI de la direction Produit? Voilà une question qui m'a occupée ces dernières années et sur laquelle je commence à me faire une opinion
Services séparés
Si les deux directions sont séparées, cela a l'avantage d'avoir une égalité des pouvoirs entre les besoins business et la technique. C'est souvent la raison évoquée par une direction générale pour installer ce genre d'organisation. Et l'argument est bon. Mais quelles en sont les conséquences?
- Tout d'abord il y a une différence dans le traitement de l'information: parceque que responsable verra son responsable de manière séparée puis lors de comités commun. Mais toutes les informations ne sont alors plus forcément partagées au même niveau
- Qui fait la roadmap?
- A mon avis nécessairement le produit: c'est eux qui portent la vision, écrivent les US. Biensûr la vélocité est maitrisé par la technique mais si votre Scrum master fait son travail alors elle est stable ou presque permettant au PO de prévoir le contenu de ses sprints à l'avance
- L'adoption de la méthode: il faut s'assurer que l'ensemble des deux directions comprennent et appliquent Scrum correctement. Autrement avec un coach dans l'organisation ou si le responsable des deux directions a de bonnes connaissances en Agile ça peu fonctionner mais c'est rare. Bien souvent, de mon expérience, les deux directions n'ont pas le même niveau de maturité sur la méthode et on trouve souvent soit des problèmes de fonctionnement qui sont inhérents à l'organisation dans son ensemble, soit un volonté de faire autrement qu'en agile (soit pour vouloir tout contrôler, soit pour faire des plannings). Et comme personne dans l'organisation n'est suffisamment haut placé pour uniformiser ces compétences... un conflit néé entre Produit et IT et alors c'est la fin
Car il faut le rappeler, Scrum a été fait pour naturellement embarqué ceux qui élaborent les besoins fonctionnels soient directement membre de l'équipe qui réalise afin de favoriser la proximité des deux. A l'enver du Cycle en V dans lequel on sépare d'un côté la partie technique (Maitrise d'oeuvre) et la partie fonctionnelle (Maitrise d'ouvrage).
Par conséquent et pour les raisons évoquées ci-dessous, une organisation ou les deux directions sont séparées sera, par nature, plus proche d'un cycle en V que d'une équipe Agile
Quelle organisation choisir?
La seule organisation que j'ai vraiment vu fonctionner correctement dans mon expérience est avec une direction unifiée. Plusieurs solutions s'offrent à vous selon la taille de l'entreprise
Pour une organisation dotée d'un IT de plus de 50 personnes
Une bonne solution qui a beaucoup été employée dans des startup incubées dans des groupes est la création d'une direction du digitale qui regroupe au moins IT et Produit mais qui, selon le contexte, peut également embarquer le marketing, du design ou autre
- Cette direction du digitale peut être organisée en SAFe si la taille des équipes est très importante mais là aussi attention à ne pas reconstruire un Cycle en V
Dans tous les cas des questions de personnes vont très vite se poser: qui dirige les PO? qui dirige la partie technique? Etc. SAFe a l'avantage d'organiser un peu tous ces modes de fonctionnement ce qui évite d'être trop dépendant d'une décision arbitraire qui serait unilatérale (via notamment différent comités dédiés).
Par ailleurs, une bonne connaissance mais surtout compréhension de la méthode est absolument nécessaire chez ces managers sans quoi cela produira le même problème qu'avec des directions séparées et on aura juste ajouté un étage à la fusée donc en gros ce sera pire.
Pour des organisations avec un IT de moins de 50 personnes
Dans ces entreprises, une direction avec le DSI à la tête des PO et des équipes techniques. C'est une organisation qui fonctionnait (peut être encore) chez RueDuCommerce et qui avait l'avantage de permettre une prise de décision plus rapide (il y a un étage de management en moins).
Dans ce cas le DSI va se retrouver responsable et du contenu produit et de la vitesse de développement vu qu'il encadre les deux équipes. Ca le rend de facto responsable du delivery. Cela aura des effets vertueux comme améliorer l'excellence technique présente dans l'équipe. Mais attention, un subtile équilibre entre les deux est nécessaire. Une compréhension de la méthode est également nécessaire pour lui-même ET pour ses responsables. Cette organisation ne peut pas fonctionner si une direction générale a une attente équivalente à celle d'un cycle en V (coût fixe, délais fixe, budget fixe). Ca ne fonctionnera qu'a condition d'être en mesure de faire intervenir tout le monde dans le suivi du backlog.
La pression sur le DSI est plus forte vu qu'il est responsable de toute la réalisation. A mon sens c'est plutôt un bonne nouvelle (à condition de le supporter biensûr) car cela permet d'avoir une vision plus claire car unifiée chez une seule personne qui aura ainsi moins de mal à la diffuser auprès des équipes
Attention cependant:
- Il faut que le DSI soit suffisamment orienté business pour ne pas trop favoriser la technique. Donc pas un profile de passioné geek qui code encore. Plutôt une personne avec plus de recule et qui comprend également les besoin business. D'un autre côté il faut aussi quelqu'un avec un solide background technique afin de ne pas se faire balader par les équipes techniques, donner des orientations d'architecture, faire les bons choix, avoir une connaissance des technologies en cours.
- Cela représente énormément de travail de diriger des équipes produits et technique. Il faut que ces dernières soient bien structurées et capable de fonctionner seule.
- Selon la taille, avoir un DSI adjoint ou une personne avec un rôle équivalent est en général un bon moyen de sortir de l'ornière si le temps ne permet pas de mettre en place ce type d'organisation.