Introduction aux Méthodes Agiles

Les méthodes agiles, vous connaissez ? Ce sont, à l’origine, des méthodes de gestion de projet informatique permettant le pilotage du changement. Plus que cela, l’agilité est devenu un véritable d’état d’esprit, voire de changement culturel. Les méthodes agiles se sont, au fur et à mesure, enrichies d’autres approches, en les adoptant ou les assimilant, pour proposer aujourd’hui tout un écosystème agile pour une organisation plus fluide, plus humaine, plus libérée. Nous vous proposons une introduction aux méthodes agiles et un tour d’horizon de son écosystème.

Bienvenue à bord !

Le Manifeste agile

Retour aux sources. Dans les années 90, pour réagir aux méthodes non adaptées de gestion de projet informatique, de nouvelles approches émergent : les méthodes dites légères : Scrum, Extreme programming (XP), pour ne citer que celles que nous connaissons aujourd’hui en France. Début des années 2000, les leaders de ces méthodes se retrouvent et signent le Manifeste Agile, véritable déclaration de l’agilité : reposant sur 4 valeurs et 12 principes. Les méthodes agiles voient le jour, avec quelques concepts clés:

• L’utilisateur revient au cœur du projet
• L’humain également avec l’esprit d’équipe, la communication et la collaboration
• Un focus sur la simplicité, l’efficacité, l’intelligence collective.
• Une adaptation aux changements et un pilotage basé sur du concret.

Méthodes agiles, un changement de paradigme

Ces méthodes acceptent la réalité des projets informatiques : il est très difficile, voire impossible de prédire et donc de planifier de manière exhaustive tout un projet. Et ce, pour différentes raisons, de définition du besoin, de communication, de complexité métier et technique… Alors plutôt que de lutter contre cet état de fait, ou de se voiler la face derrière des contrats forfaitaires, ils vont transformer ce problème en opportunité ! Les projets ne sont généralement pas prédictibles, soit, il ne sert à rien de perdre trop de temps à planifier dans le détail l’intégralité d’un projet et de s’efforcer de suivre un plan irréaliste :

60% des changements d’un projet informatique arrivent pendant la phase de développement.

Au lieu de cela, nous allons définir un cadre (besoins, budget, planning) macroscopique et nous allons piloter le projet à l’intérieur de ce cadre pour l’optimiser, en priorisant, supprimant, modifiant ou ajoutant les fonctionnalités, tant que l’on répond aux besoins exprimés. Les ajustements se font au niveau de la solution, de ses fonctionnalités. Ce changement a beaucoup d’implications : Il va falloir se doter d’une méthode et d’une organisation qui permettent ce pilotage, c’est à dire sachant s’adapter aux changements en cours de route, et plutôt rapidement ! C’est aussi accepter que l’on ne maîtrise pas l’ensemble du projet dans le détail.

L’approche traditionnelle

L’hypothèse de l’approche traditionnelle est que le besoin de l’utilisateur est bien compris et que la solution qu’on lui propose est la bonne. Sur cette base, tout est figé au démarrage d’un projet. Pour optimiser la valeur ajoutée sur le coût du projet, la solution étant fixée, on cherche à réduire le coût d’exécution du projet. Cela passe par la spécialisation des profils, l’économie d’échelle pour chaque phase, … Et cela à marche bien tant que les changements sont peu impactant.

L’approche Agile

L’hypothèse des méthodes agiles est un peu différente : on suppose toujours que le besoin de l’utilisateur est bien compris, mais la solution qu’on lui propose est-elle la bonne ? Nous allons valider cela au plus tôt avec les utilisateurs, et finaliser la solution ensemble, éventuellement par de la co-construction. L’optimisation du projet se base alors sur la création de valeur ajoutée. La valeur ajoutée est celle perçue par l’utilisateur que ce soit un gain de productivité, d’ergonomie, de simplicité, d’accessibilité… Le changement en cours de route est une opportunité pour créer un peu plus de valeur ajoutée que prévue, cela a un coût. L’hypothèse de l’agilité, pour qu’elle soit pérenne, est que le surcoût de l’approche itérative est moins important que la valeur ajoutée qu’elle créée.

64% des fonctionnalités d’un logiciel ne sont pas ou rarement utilisées… Il est temps que cela change !

Eviter de développer ces fonctionnalités, pourtant prévues au début d’un projet, permet un gain bien plus important que de revenir sur une fonctionnalité déjà développée.

Objectifs des méthodes agiles

Les objectifs sont multiples, certains focalisent sur un meilleur produit, d’autres une réussite du projet, beaucoup sur un recentrage sur l’humain et l’intelligence collective. Le top 3 des objectifs est :

• Savoir gérer les changements de priorité
• Réduire les délais, pour principalement améliorer le Time To Market
• Augmenter la qualité du produit pour un meilleur usage

Organisation d’une équipe Agile

Pour répondre à cela, les approches agiles proposent une conception itérative, une livraison incrémentale, sur des cycles courts de quelques semaines, généralement contraint par le temps, appelés des sprints. Pour que cela marche, les équipes sont plutôt petites, et pluridisciplinaires, c’est-à-dire, ayant toutes les compétences et connaissances en interne pour transformer une demande en une solution. La grande différence avec l’approche traditionnelle est que ces équipes sont auto-organisées. Elles s’engagent sur un objectif pour le sprint, puis font ce qu’il faut pour atteindre cet objectif. Il n’y a plus de chef de projet a proprement parlé, le micro management, entre autres, est délégué à l’équipe elle-même. Cela soulève la question de la posture managériale et de la place d’un manager agile ?

Une approche empirique

Toutes ces méthodes reposent sur les individus qui les utilisent. On parle de collaboration, de respect, de transparence, de rythme soutenable. Bien comprendre l’état d’esprit de ces approches, l’être agile, plus que le faire agile, est primordial. Car les méthodes agiles reposent sur une approche empirique. Ce ne sont pas des méthodes sur étagère complètement décrites. Ce sont des cadres à l’intérieur desquels vous allez faire votre implémentation de l’agilité compte tenu de votre contexte, de votre maturité, de vos contraintes. D’autre part, votre implémentation agile va naturellement évoluer au cours du temps.

L’écosystème Agile/Lean

L’extreme Programming (XP)

XP est une des méthodes agiles de la première heure. Elle est plus connue pour ses pratiques d’ingénierie logicielle que pour la partie gestion de projet, qu’elle porte pourtant. Complémentaire à Scrum, voire indispensable pour une bonne partie de ses pratiques, elle permet de mettre l’accent sur la qualité de ce que l’on produit. XP, permet de maîtriser la dette technique du code au fil du temps et donc garder un code très évolutif.

XP : maîtriser la qualité de la production de code et la dette technique

Les pratiques les plus connues sont le pair programming, la conception émergente, le test driven development (TDD, coder les tests avant le code), le refactoring, la revue de code, l’intégration continue (voire déploiement continu)…

Cette méthode est plutôt à destination des développeurs, des testeurs, des architectes.

Scrum, la méthode agile la plus utilisée

Scrum est une méthode de gestion de projet agile. Elle n’adresse pas la question des pratiques de développement en tant que tel, mais plus l’organisation, le cadre, le pilotage, les rôles et responsabilités. Elle permet de maîtriser la production de l’équipe dans un environnement incertain, en pilotant par la valeur.

Scrum : maîtriser la production de l’équipe dans un environnement incertain

On trouve une planification à plusieurs niveaux : de la roadmap  au pilotage de la release, au sprint. Un sprint est une itération, contrainte par le temps, généralement quelques semaines, avec un objectif. L’équipe doit répondre à cet objectif avec un incrément du produit logiciel, démontrable. Les décisions sont prises par l’équipe au jour le jour au cours de la mêlée (d’où le nom de Scrum, la mêlée au rugby) ; Ainsi que la planification, les estimations et l’amélioration continue qui sont collectives et  régulières, à chaque sprint. On y trouve les rôles de Product Owner, de Scrum Master. Scrum est disruptif : du jour au lendemain, l’organisation projet change, les rôles également. Les chefs de projet et managers ont quelque fois du mal à se projeter dans la nouvelle organisation, bien qu’ils aient toujours leur place.

Cette méthode est à destination de toute l’équipe, mais intéresse tout particulièrement les managers, les responsables produit, les responsables d’équipe.

Et les autres méthodes

Kanban, une approche plus au fil de l’eau

Mais voilà, si l’on n’a pas de projet mais plutôt un flux de demandes, d’affaires, de petits projets ? Comment être agile, dans ce cas de forte incertitude ? C’est dans ce contexte que se positionne la méthode Kanban : maîtriser le flux de travail en améliorant le processus pour réduire les délais, l’encours. L’objectif est d’aller vers du flux tiré.

Kanban : maîtriser le flux de travail en améliorant le processus

Kanban ne fait pas partie des méthodes agiles directement car elle ne suit pas complètement les valeurs du Manifeste Agile. Et pourtant, elle apporte tous les bénéfices de l’agilité mais de manière plus douce, plus évolutive. C’est pour cela, que le Kanban trouve sa place dans l’écosystème agile, et est souvent assimilée aux méthodes agiles.

Cette méthode est à destination des managers, des agents du changement et de l’amélioration continue, sont inclus les scrum masters, coaches agiles.

Le Lean IT et Lean Software development

Le Lean IT fait partie de l’écosystème Agile, et inversement. Sans faire partie des méthodes agiles, elles font bon ménage. Il permet d’améliorer la performance par la résolution de problèmes, portés par ceux qui font le travail. On commence souvent par le Lean IT pour aider les équipes de supports. En tant que démarche d’amélioration continue, on l’utilisera dans un second temps sur la partie réalisation avec Scrum ou Kanban pour avoir une équipe performante.

Lean : améliorer la performance par la résolution de problèmes

Les principes du Lean IT :

1. Éliminer les sources de gaspillage
2. Favoriser l’apprentissage
3. Reporter les décisions
4. Livrer vite
5. Respecter les personnes et impliquer l’intelligence collective
6. Construire la qualité intrinsèque
7. Optimiser le système dans son ensemble

Le Kanban est au départ un outil du Lean. Kanban pour l’IT est devenue une méthode à part entière qui fait le lien entre l’agilité et le Lean.

Le Lean IT, tout comme le Kanban, est à destination des managers et agents du changement et de l’amélioration continue, et toute l'équipe.

Software Craftmanship

Ce mouvement permet de réaffirmer que le développement logiciel est une activité artisanale, loin de l’usine logicielle et qui ne se résume pas à produire des lignes de code. C’est du XP relooké, sans que cela soit péjoratif. Il existe un manifeste du Software Craftmanship. Il ne suffit pas que le logiciel fonctionne, encore faut-il que le code produit soit de qualité.

Ce mouvement intéressera plus particulièrement les développeurs.

DevOps

Scrum repose sur le principe d’une équipe pluridisciplinaire, nous l’avons vu. Cela n’est pas toujours possible. Il est souvent difficile d’avoir la partie exploitation présente dans une équipe Scrum. Or la réussite d’un produit ne se fait pas seulement lors de la conception mais également au cours de son exploitation. Mettre en collaboration ces deux équipes au plus tôt dans le projet, voilà l’objectif du mouvement DevOps, fluidifier les échanges du développement à l’exploitation, apporter les pratiques et les outils pour cela. DevOps et Kanban ensemble ont notamment contribué à passer de l’intégration continue au déploiement continu (plusieurs fois par jour en production potentiellement), au plaisir des startups du web.

DevOps intéressera plus particulièrement développeurs et exploitants/opérations.

Méthode Lean startup

L’incertitude avec la méthode Lean startup ne se situe plus au niveau de la solution, comme avec Scrum, mais au niveau du besoin lui-même ! On ne travaille avec un Product Backlog, la liste des fonctionnalités potentielles d’un produit, mais directement avec le business model du produit. On n’itère plus, on pivote, on change des éléments structurants du business model si celui-ci s’avère non viable.

Lean Startup : processus de recherche d’un business model viable et scalable dans un environnement incertain

Le Lean Startup est un savant mélange de Customer Development, de méthodes agiles et de Lean. L’agilité permet un optimum local sur une solution, avec le Lean startup on va chercher un optimum global sur le business model.

Cette méthode est à destination des managers, marketing, directeur et chef produit, Product Owner ; mais également coach agile pour amener l’agilité côté métier.

Entreprise libérée

Le graal ! A tort on parle d’agilité pour les entreprises ou les entrepreneurs. C’est plus un changement l’organisation hiérarchique par de l’holacratie, une mise en autonomie de tous les salariés. Ce que l’on libère, c’est le potentiel de chacun, et notamment du carcan administratif, technocrate, … Ce n’est pas une approche agile, Il faut plutôt voir que les méthodes agiles vont s’y sentir bien à l’aise et vont apporter des réponses concrètes à une approche encore un peu conceptuelle, mais de bon sens.

Liberté + responsabilité = bonheur + performance

Cette approche s’adresse bien sûr aux dirigeants, ce sont eux qui doivent décider de libérer leur entreprise.

Et un ensemble d’autres approches

Le Design thinking, pour se focaliser sur l’expérience utilisateur dans des environnements complexes. Des pratiques pour l’innovation et de brainstorming collectifs, Innovation games et game storming, utiliser principalement par les Product Owners avec les utilisateurs, les parties prenantes pour innover sur les produits. Pour les managers, le management 3.0 permet de devenir un manager leader et apprendre à naviguer dans un monde plein de changements et d’incertitudes. Et pour le business, il y a Beyond Budgeting, pour que l’organisation face elle aussi un pas vers l’agilité en arrêtant de faire des budgets annuels ou semi annuels, bridant les changements. Pourquoi ne pas utiliser des budgets incrémentaux. Plus fondamentalement, il s’agit de ne plus piloter une entreprise par le budget mais en remettant la stratégie de l’entreprise aux commandes. Du bon sens toujours. L’écosystème des méthodes agiles ne cessent d’évoluer et de s’enrichir des pratiques et principes que l’on trouve maintenant en dehors du développement logiciel.

L’agilité hors contexte logiciel

Peut-on utiliser les méthodes agiles en dehors du monde logiciel ? Oui c’est possible !

Approche Scrum

Scrum est utilisable dans d’autres contextes que le développement logiciel mais à certaines conditions : avoir une notion de projet et une équipe, dédiée à ce projet. Sans ces deux points, certaines pratiques de Scrum peuvent être intéressantes mais l’ensemble est moins pertinent. Nous avons réalisé des approches Scrum pour des répondre à des appels d’offre, écrire des spécifications, accompagnés des transformations d’organisation.

Approche Kanban

Le Kanban n’est pas spécifique au développement logiciel, il marche dès lors que l’on a un processus de travail à peu près répétable (ce n’est pas le chaos !) et que l’on a un flux de travail. Nous le mettons en œuvre de plus en plus en milieu industriel, avec la partie bureau d’études que ce soit pour concevoir des robots ou automates, des piscines, des camping-cars… On parle plus de pilotage de flux d’affaires, mais les principes sont ceux du Kanban.