On entend souvent dire que l’Agilité est facile à comprendre et difficile à mettre en place. Nous le voyons couramment lors de nos interactions avec nos clients, nous n’avons jamais connu de situation dans laquelle des frameworks Agiles comme Scrum (le plus populaire) peuvent être suivis à la lettre. Selon nos observations, cela se produit parce que, la plupart du temps, l’agilité est considérée comme une formule magique de résolution de problèmes par les chefs de projet, les équipes de développement de produits ou les initiatives d’innovation. De plus, l’agilité est devenue si populaire ces dernières années que les entreprises pensent qu’elle peut être appliquée dans n’importe quel contexte.
L’empirisme pour résoudre des problèmes complexes
Alors, pour démystifier cela, il faut revenir à l’une des bases de l’agilité: l’empirisme. Cette notion s’applique depuis longtemps dans des contextes dans lesquels le but est la découverte. L’application la plus commune de l’empirisme est la méthode scientifique. Vous faites de l’observation, et vous formulez une hypothèse. Puis vous faites des tests et finalement, vous recueillez vos apprentissages. C’est une des choses que l’agilité propose, dans ses premiers objectifs, pour les contextes de gestion de produit complexes.
Inspiré du modèle Cynefin, il est importante de faire avant une identification consciente des caractéristiques de notre environnement. Ce faisant, il participe à une clarification du contexte et nous pouvons en retour mieux comprendre quelles attitudes, décisions et actions mettre en oeuvre pour obtenir le meilleur résultat. Alors, dans des situations dans lesquelles il y a trop d’éléments inconnus, comme par exemple le manque de clarté par rapport à un problème, les ressources dont nous avons besoin pour mener l’initiative, ou même les détails des actions à prendre pour l’exécution du projet, nous avons besoin d’aller par cycles de découverte, ce qui va nous permettre de dérisquer nos démarches tout en validant les informations au fur et à mesure que nous avançons. Au contraire, lorsque nous sommes dans un contexte compliqué, nous avons quelques informations définies qui permettent de rendre la planification plus simple. Tel est le cas des projets dans lesquels nous savons déjà ce que nous allons développer: nous avons identifié quelques ressources et nous n’avons pas besoin de découvrir l’impact vers le client.
Source : Publicis Sapient
Les principes de l’agilité
Au delà de l’empirisme et de l’approche itérative expérimentale, l’agilité est un état d’esprit qui se base sur quatre principes (le manifeste Agile):
- Les individus et leurs interactions, plus que les processus et les outils
- Des logiciels (produits) opérationnels, plus qu’une documentation exhaustive
- La collaboration avec les clients, plus que la négociation contractuelle
- L’adaptation au changement, plus que le suivi d’un plan
(Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.)
Ces principes sont tellement souples qu’ils peuvent être inclus dans n’importe quel contexte de travail, et c’est la raison pour laquelle les équipes ont de la difficulté à mettre en pratique l’agilité. Pour ce faire, il y a des cadres de travail qui expliquent ce que vous devez faire: rôles et responsabilités, rendez-vous, artefacts de travail, etc. Mais ces cadres de travail ne prennent pas en compte que l’actualité, qui peut être trop exigeante en ce qui concerne la performance de l’équipe (livrables), les besoins du marché et les ressources disponibles.
Alors, est-ce que l’agilité est pour vous? Est-ce possible de l’appliquer dans votre entreprise ou dans votre contexte? La bonne nouvelle c’est que vous pouvez le faire, vous devez être Agile vous-même et essayer de trouver votre propre cadre de travail. Nous appelons cela un cadre de travail Hybride qui s’inspire de plusieurs méthodologies de gestion de projet dont l’Agilité.
Pourquoi l’approche Agile-Hybride ?
L’intérêt de l’approche Agile-Hybride de la gestion de projet est de choisir la méthodologie la plus appropriée pour chaque équipe, selon son contexte en partie compliqué et en partie complexe. Elle peut être très différente des autres équipes, même au sein d’une même organisation.
Il existe de bonnes raisons rationnelles et validées pour utiliser un mode de fonctionnement Hybride, mais il faut bien les connaître et comprendre que ce n’est pas parce que nous n’apprécions pas un framework ou l’autre. Tout part du degré de contexte compliqué et/ou complexe. Il faut toujours s’en rappeler.
Alors, dans un cadre de travail Hybride, il est normal de trouver un backlog qui contient des récits qui ne sont pas nécessairement liés à un incrément produit, à une équipe de Product Owners ou à plusieurs objectifs dans un seul Sprint. Si vous êtes méticuleux, cela peut vous paraître choquant, mais c’est la vraie vie. Qu’est-ce que serait l’agilité, si elle-même ne peut pas se transformer pour mieux servir aux équipes?