Agilité hors logiciel : à quoi ça ressemble ?
Et bien… Ça marche !
C’est une question qui revient régulièrement. Peut-on utiliser l’agilité ou Scrum en dehors du monde du logiciel ? Dans ce cas, à quoi cela ressemble-t-il ? En quoi est-ce différent ?
Je vous propose de partager dans cet article quelques exemples classiques de mise en oeuvre de l’agilité en dehors du logiciel.
Les équipes qui ne construisent pas un produit : Kanban
Commençons tout d’abord par une catégorie un peu générale : des équipes qui ne construisent pas un produit.
Ainsi, on entend souvent parler de Marketing Agile ou de RH Agile. Le même peut être dit d’une équipe commerciale qui serait organisée de manière agile. Enfin, le cas peut-être le plus courant : une équipe de support client qui elle aussi serait organisée à la sauce agile.
Concrètement, à quoi ressemble le fonctionnement de ces équipes ? L’approche logique est d’utiliser Kanban pour modéliser les flux de travail, les rendre visibles et s’assurer de leur fluidité. Cela permet d’assez naturellement animer une équipe avec une mission commune, et cela aussi bien si les membres de cette équipes ont un profil similaire ou au contraire des rôles et compétences très différentes.
De telles équipes utilisent rarement Scrum, ou alors pas une version pure de Scrum mais une version adaptée. C’est assez logique : Scrum n’est pas adapté à ce type de contexte. Plus généralement, c’est le même problème qu’avec n’importe quelle Component Team, en charge d’une partie assez précise du travail à faire pour générer ou entretenir du business, et non pas d’un produit de bout en bout.
Le travail d’ingénierie : candidat parfait pour l’agilité
Prenons l’exemple de l’industrie. Le travail se décompose en deux grandes phases : la conception et la fabrication.
L’ingénieur intervient lors de la conception. Son rôle est de fournir une spécification détaillée qui permettra aux techniciens de procéder à la fabrication.
C’est en réalité exactement ce qui arrive dans le cadre du développement logiciel. Le développeur livre une spécification détaillée de la fabrication : c’est le code. La différence dans le cas du développement logiciel est la suivante : il n’y a pas de technicien pour se charger de la fabrication, ces derniers sont remplacés par des programmes et des ordinateurs.
Cette partie de conception, l’ingénierie, est de fait très propice à l’agilité. Comme pour le développeur logiciel, le livrable de l’ingénieur est dématérialisé : c’est la spécification détaillée de la fabrication.
Si cette approche de l’ingénierie semble contradictoire avec l’approche traditionnelle, de plus en plus d’entreprises injectent de plus en plus d’agilité dans leur processus d’ingénierie, avec succès.
Les Product Teams (les vraies)
Nous pouvons aussi parler des Product Teams — les vraies ! Celles qui sont réellement en charge d’un produit ou d’un sous-produit, avec :
- Une mission commune et orientée business
- Une responsabilité de bout en bout
- Toute les compétences nécessaire pour mener à bien cette mission
Ces équipes fonctionnent à merveille en agilité. En particulier, Scrum est pleinement adapté.
Dans ces équipes, nous pourrions trouver des experts qui ne font pas du logiciel, pleinement intégrés dans l’équipe.
Un exemple ? Pour le développement d’un logiciel juridique, on met un avocat dans l’équipe. Finalement, cet avocat, c’est le Business Analyst du domaine juridique.
À vrai dire, ce type d’équipe n’est pas à restreindre à la construction d’un logiciel. Cela fonctionne pour tout ! L’important c’est de construire un produit avec, encore une fois, une véritable responsabilité de bout en bout et avec toutes les compétences nécessaires.
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.
À bientôt 😊
