Scrum et Kanban sont dans un même bateau…

Les organisations que j’accompagne sont la plupart du temps organisées en silos. Certaines ont des organisations matricielles. Très exceptionnellement, elles sont organisées par ligne de produit. C’est cette dernière organisation qui se voit renforcer lors du passage à l’agilité. Les autres se font gentiment bousculer challenger lors d’une transition agile. S’il est tentant de penser alors à une organisation s’appuyant principalement sur le modèle Scrum, le One size fits all est rarement la bonne solution.

Une organisation orientée produit

L’agilité promeut la création de valeur pour l’utilisateur, grâce au produit ou service que l’on créé. Pour y arriver, on réunit toutes les bonnes personnes en une équipe pluridisciplinaire, c’est à dire ayant toutes les compétences pour prendre une demande et proposer une solution jusqu’en production. Pour constituer une telle équipe, il faut casser les barrières, managériales  ou culturelles, entre le métier et l’IT. C’est un des challenges auquel tout scrum master ou coach agile a été (largement) confronté. J’inclus dans ces équipes les activités de maintenance évolutives /correctives, support prod, … J’en parle un peu dans l’article Kanban contre le flux continu. Je n’inclus pas dans ces produits les projets transverses à l’organisation, type socles techniques, composants ou autres. J’en parlerais une autre fois.

Organisation multi produits

Plus il y aura de produits ou de familles de produits, plus on aura d’équipes Scrum définies. C’est bien sur plus compliqué que cela, selon la taille des équipes, le volume de travail lié aux divers produits, … Si les équipes sont trop importantes alors on créé plusieurs équipes avec du Scrum de Scrum ou des features teams. Vous pouvez regarder les vidéos de Spotify pour voir une organisation de ce type. Et puis, il peut y avoir des dépendances à gérer entre équipes, tout plein de difficultés que l’on connait. Cela s’appelle de la gestion de projet justement, de bien anticiper toutes ces contraintes.

Toutes les équipes passent en Scrum alors ?

En bref, non. C’est le sujet de cet article justement. Parce que l’on me pose encore trop souvent cette question. Oui, les équipes directement impliquées dans le produit passent en Scrum. Une fois dit cela, il reste à savoir comment s’organisent les autres équipes qui ne sont pas directement impliquées dans le produit. Généralement ce sont des équipes en support des équipes Scrum :

L’infra, les experts (dba, architectes, designers, ergonomes, …), mais également les achats (pour les serveurs, licences, consulting, …), les RH (par exemple pour le recrutement d’un nouvel équipier, formation, …) …

Ces équipes ne fonctionnent pas en Scrum, par nature : elles doivent être disponibles et réactives pour répondre au mieux aux équipes Scrum (qui font vivre l’organisation normalement). Généralement, ces équipes ne font pas et ne peuvent pas faire de gestion de projet en tant que tel (bien qu’on leur demande quelques fois de le faire, au moins pour du reporting, quel délice…). Sans faire de gestion de projet, elles y contribuent. Leur engagement est plus un engagement de service, de délai (réactivité). La capacité de ces équipes à proposer un délai fiable suite à une demande va grandement contribuer à une gestion de projet plus fiable au niveau des équipes Scrum. Travaillant plus au fil de l’eau, s’engageant sur ses délais, l’approche Kanban se trouve être plus adaptée à ces équipes. PS : les équipes Kanban peuvent être constituées de profils mixtes métier et IT. Je ne traite ici que le point de vue des équipes en support, généralement spécialisées.

Et le management dans tout cela ?

La description des équipes Scrum / Kanban est plutôt opérationnelle. Que deviennent les managers dans ce type d’organisations ? La transition à une organisation agile ne se fait pas du jour au lendemain. Les silos ne se lèvent pas comme cela. L’organisation opérationnelle produit et l’organisation administrative silos sont amenées à cohabiter. Selon la taille des équipes, un manager peut avoir certains collaborateurs d’une seule équipe Scrum, voire de plusieurs équipes Scrum. Ce dernier point est intéressant car l’équipier peut alors changer d’équipe sans changer de manager. C’est l’idée des chapters de Spotify. Le manager n’est plus directement lié à la partie opérationnelle. Et c’est cela qui pose problème en levant la vrai question du rôle de manager agile. Il y a bien sur des réponses à cela, notamment avec les communautés de pratiques. Dans tous les cas, il doit se débarrasser de sa casquette opérationnelle et redécouvrir la vraie nature du travail managérial, d’accompagnement de ses collaborateurs sur un autre terrain que l’opérationnel. Il reste tout de même celui qui met de l’huile dans les rouages en dehors des équipes.

Scrum et Kanban sont dans un même bateau…

En conclusion, dans une organisation, je constate qu’une réponse adaptée marche mieux qu’une réponse homogène en termes de méthode. Il ne faut pas hésiter à proposer aux équipes plusieurs manières de s’organiser plutôt que d’imposer une seule manière de faire. Car la réalité est que les contraintes différentes des équipes justifient des cadres méthodologiques différents.