Méthodes Agiles - Agilité appliquée à l'industrie
Soyez en phase avec vos objectifs sans perdre de temps sur les procédures longues et coûteuses
L'agilité n'est pas réservée à l'informatique, il existe une agilité en dehors du sofware et on peut l'apprendre.
Les concepts et outils Agiles sont issus de l'informatique mais les pratiques Agiles sont maintenant disponibles pour tous les métiers : des services innovants, aux industries lourdes.
La nécessité d’accroître la productivité, théorisée par Taylor puis mise en place par Ford dans les années 30, a formalisé le travail à la chaîne, le planning Gantt et le cycle en V. Ensuite, la volonté de maîtriser la qualité, structurée dès les années 70 par des ISO ou 6 Sigma, a amené l’amélioration continue et l'organisation matricielle.
On constate malheureusement que ces approches ne suffisent plus pour certains projets :
Agile dans le dictionnaire : adjectif
Sens 1 : Dont les mouvements sont souples et rapides. Synonyme : adroit
Sens 2 : Qui comprend vite [Figuré]. Synonyme : vif
Cette page est exclusivement dédiée à l'application des méthodes Agiles en industrie, comprenez « hors de son champs d'application traditionnel : le développement logiciel ».
Phases amonts des projets concrets et physiques (hors logiciel) ou de recherche
Équipes R&D / R&T, multi-projets, pluri-disciplinaires
Projets multi-sites complexes ou innovants
Si vos projets sont à l’heure et dans le budgets, et si les équipes sont motivées : pas besoin de l’Agilité.
Plannings faux dès le 1er jour
Des retards de plusieurs mois découverts vers la fin du projet
La mise en place (ou la tentation) de gestion de projets plus strictes mais finalement néfastes
Dates tenues principalement par des petites équipes d’artistes ou de pompiers « à l’arrache » (une date butoir et zéro reporting)
Talents qui ne veulent pas qu’on leur dise comment faire leur travail, ni être contrôlés
Des équipes noyées par le nombre de projets et leurs priorités, les changements toujours urgents
Des productions ou des processus avec de belles technologies mais peu d’idées neuves
Des idées qui arrivent trop tard dans le projet pour être mise en œuvre
Des échecs dans la gestion de projets traditionelle…
différenciez les projets classiques des projets pouvant bénéficier de l’Agilité, les apports et les moyens à mettre en œuvre pour devenir une entreprise Agile (en commençant par une équipe pilote ?).
La gestion de projet est une démarche visant à organiser, du début à la fin, le bon déroulement d’un projet. En début de projet, le premier réflexe est d’essayer de tout prévoir :
la description de ce qu’on va livrer
comment on va le faire
les problèmes qui peuvent intervenir, la façon de les résoudre
la date de chaque évènement en intégrant une marge d’erreur calculée à l’avance
La gestion, dite du « cycle en V », est parfaitement adaptée à cette approche ultra prédictive : on prévoit tout, on fait un Gantt Chart (planning) et la liste des choses à faire (WBS) puis on peut commencer.
Les avantages de ce modèle prédictif sont attractifs : C’est simple à contractualiser et on met l’équipe en face de ses responsabilités. Elle devra assumer toute erreur d’évaluation et corriger tout problème non prévu initialement. Management et client adorent cela (mais ne se trompent-ils pas sur ce qui est vraiment bon pour le projet, l’équipe, et pour EUX ?)
Tout prévoir dès le début, tout anticiper… est séduisant mais est-ce possible et souhaitable ?
Gestion des risques : « L’ours que tu vois n’est pas celui qui te mangera » disaient les anciens. Parfois, tenter de tout prévoir à l’avance a ses limites et pour citer Darwin : « Les espèces qui survivent ne sont pas les espèces les plus fortes ni les plus intelligentes mais celles qui s'adaptent le mieux aux changements. ». Devrions-nous tenter une approche plus souple et plus efficace des risques ? Devenir agile ?
Pour certains projets, lister la totalité de ce qu’il y a à faire dès le 1er jour n’est pas simple, c’est parfois même impossible.
Ces projets ne sont pas gérés de façon optimum avec une approche traditionnelle de gestion de projets.
On pourrait « tout » gérer avec Agile mais ce serait une erreur car la gestion conventionnelle (cycle en V) est souvent optimum, par exemple dans des productions répétitives. Focalisons-nous sur les projets que la gestion prédictive ne peut pas traiter : les projets non prédictifs donc des projets qu’on ne peut pas parfaitement définir le 1er jour :
Développement de produits ou services innovants
Projets créatifs et innovants (R&D, bureau d’études, recherche…)
Projets complexes (qu’une seule personne ne peut pas englober seule à cause de sa complexité : multi sites, pluriculturelle, métiers imbriqués…).
Pour ces projets, l’Agilité va apporter la flexibilité et la démarche nécessaire pour se focaliser sur l’objectif à atteindre (par exemple une nouvelle expérience utilisateur), plutôt que sur les choses à faire.
Incrémental (recommencer le même cycle)
Itératif (ajouter)
Itératif incrémental (mixé avec une gestion des risques éclairée)
Le développement itératif incrémental est généralement représenté par des spirales ou des cercles. Cela représente bien le rythme mais n'indique pas que le projet à un début et une fin. Nous revisitons la représentation (mais surtout le fond) pour une série de petits cycles en V. C'est le cycle en VvvvWvvvWvvvWvvvWvvvV. Le premier V est la mise en place du projet, le dernier V est la livraison finale. Les pics durant le projet (ou W) sont des moments spécifiques au projet (intégration avec d'autres groupes, démo client ou salon...) Chaque itération est un mini cycle en V adapté à l'Agilité, le projet entier devient Agile.
Vous trouverez l’historique de l’Agilité sur Wikipédia, voyons plutôt un angle qui explique que l’Agilité soit sortie de l’industrie logicielle.
L’Agilité n’est pas une invention théorique mais la formalisation de pratiques constatées dans des équipes auto-organisées dès les années 80. Pascal Jarry, fondateur de SolidCreativity (après avoir passé 20 ans à manager des projets de jeux vidéo en 3 langues sur 3 continents), se rappelle : « On échangeait avec d’autres managers lors de conférences internationales. On avait tous le même problème : nos équipes avaient grossi et en tentant de professionnaliser la démarche nous avions détruit la créativité, la motivation et l’efficacité. Ajouter plus de rigueur au mauvais endroit, comme le suggérait le cycle en V par exemple, nous faisait aller droit dans le mur. Les uns et les autres, nous échangions alors des bonnes pratiques puis on se revoyait. Des thèses sont ensuite sorties puis des livres, on essayait, on adaptait… Nous avions toujours été agiles mais nous étions devenus Agilistes. ».
Les concepts et outils de l'Agilité viennent à l'origine de l'informatique mais SolidCreativity met cette formation exclusive sur l'Agilité à disposition de tous les métiers créatifs et secteurs innovants.
En parallèle de ces démarches : Lean par exemple
Il y a une foultitude de démarches prévues pour améliorer la gestion de projets. Lean, par exemple a des similarités avec Agile (management visuel…) puisqu'ils partagent un ancêtre commun ; certains les confondent même. Il faut se rappeler cependant que Lean est une démarche visant à améliorer des actions prévues voire répétitives : on Lean un processus de production. Lean est donc parfaitement adapté pour améliorer les projets gérés avec le cycle en V mais Lean est moins adapté aux projets innovants.
Si on ne fait pas du Lean sur tout, on ne fait pas du Agile sur tout non plus ! Dès 2002 SolidCreativity a pourtant commencé à étudié la transposition de la méthode Agile Scrum (100% orientée logiciel) vers l’industrie. Notre conclusion est que même Scrum peut être utilisée avec certaines conditions :
Il faut que le projet s’y prête (innovant, R&D…). Condition absolue, ce ne doit pas être un projet ronron, déjà fait 100 fois.
Le domaine importe peu (industrie lourde, recherche, journalisme…)
Il faut faire l’effort de s’y mettre mais on ne le regrette pas
Pour l’organisme qui accompagne l’entreprise :
Il faut avoir compris l’Agilité et ne pas s’en tenir au dogme. Il faut savoir conserver des parties importantes et adapter les autres
Il faut un effort de langage, que nous avons résolu, pour transposer l’Agilité vers d’autres domaines d’expertise
Avec les équipes, il faut un énorme effort pédagogique (que nous avons fait) pour présenter les concepts de l’Agilité et espérer sortir vivant
L’agilité ne se limite pas à Scrum, il faut proposer une réelle approche Agile et pas seulement des outils (artefacts / réunions).
On constate que l’Agilité sort de l’informatique et s’étend efficacement à d’autres types de projets, comme le confirme une étude de l’institut Forrester de 2013 :
“Agile is not only used in several of the world’s leading companies now but is being applied in areas beyond software development. (…/…) some companies are applying Agile to areas within the organization such as, portfolio management, project management, vendor management, contracting, etc.”
Des sociétés comme Google, Apple ou Microsoft sont Agiles, bien entendu, mais aussi certains services de Peugeot ou Airbus par exemple. Voici le témoignage d'Airbus sur des projets Agiles qu'ils appellent SPRINT : Lire l'article de l'Express
Tout les points de ce tableau comparatif doivent normalement être introduits un à un, dans le dialogue ; les concepts de l’Agilité ne sont généralement pas compris ni acceptés à la première lecture. Ni par la direction, ni par les équipes… c’est très DIFFERENT de ce qu'on fait habituellement.
| Apports d’une gestion Agile | Problèmes que cela corrige |
|---|---|
Management visuel en temps réel |
Reporting uniquement administratif |
Atteinte d’objectifs partagés |
Dépilement de choses à faire, sans vision de l'objectif |
Une gestion des risques adaptée aux projets complexes et innovants, mobilisante |
Une gestion des risques menant exclusivement à l’immobilisme |
Gestion de jalons (milestones) en itératif incrémental (cycles d'amélioration du résultat mais aussi de la méthode de travail) |
Cycle en V, même pour des projets inadaptés, favorisant l’hésitation et la culpabilité |
Gestion de projet auto-adaptative visant une constante amélioration |
Gestion de projet figée, même si elle ne convient pas et donne de mauvais résultats |
Equipe auto-organisée et motivée |
Personnes dépendantes de leur manager |
Gestion de projet adaptée au projet, qui pourra devenir ISO |
Gestion de projet standard ISO, même si elle est inefficace et non adaptée |
Responsabilisation motivante de l’équipe |
Sous exploitation des potentiels |
Détection des problèmes au plus tôt et solutions collectives |
Détection tardive des problèmes et recherche des coupables |
Et aussi, une adaptation aux équipes modernes : |
Gestion théorique idéalisée mais incomprise : |
Des études sérieuses et largement documentées ont été faites pour mesurer les apports des méthodes Agiles sur les projets et équipes, nous parlerons de productivité, des coûts et de la motivation.
4 études mesurent un gain en productivité grâce à l'Agilité
Un gain en productivité de 16% (QSMA*)
82% constatent un gain en productivité (DDJ*)
23% disent que la productivité s’est beaucoup améliorée (VO*)
Selon l’université de Calgary*, l’Agilité réduit de 2/3 le recours aux heures supplémentaires.
Une réduction des coûts est aussi mesurée dans 2 études :
32% citent une amélioration, 5% citent une amélioration significative (DDJ*)
30% citent une amélioration, 8% citent une amélioration significative (VO*)
15 mois après avoir adopté l’Agilité, 86% des employés de SalesForce disent avoir « a good time » ou « a best time » au travail. Seulement 40% disaient cela avant. 92% recommandent maintenant l’Agilité.
*Sources
Livre sur les succès en développements logiciel : Succeeding with Agile
Alors que l’Agilité est la gestion de projet « par défaut » en développement logiciel, ce n’est pas le cas dans les autres domaines et il faut d’abord réfléchir au besoin d’Agilité en fonction :
Du type de projet
De la phase projet
Une fois que l’Agilité est préconisée, alors on peut réfléchir à son transfert vers le projet et l’équipe en question.
L'Agilité en informatique est normée par des vocables, des méthodes, des cycles, des procédures, des métiers, des outils... autant de choses qu'il a fallu comprendre et adapter pour une Agilité en dehors de l'informatique.
Il est compliqué, pour une personne qui conçoit un avion, d'entendre qu'Agile propose de livrer plusieurs avions, avec plusieurs niveaux de finitions. Dans l'esprit des concepteurs aéronautiques, un avion vole ou ne vole pas, mais on le livre jamais un demi avion.
Pourtant l'Agilité (dans un cycle de développement itératif incrémental) prévoit un développement et des livraisons de parties d'avions, alors comment faire ? Il faut opérer des changements de paradigme :
- Les livraisons ne sont pas uniquement faites au client final
- On peut livrer le cockpit alors qu'une autre équipe livre le train d'atterrissage, les 2 développements n'étant pas forcément synchronisés
- Oui, on peut "livrer" un cockpit par étapes, la première livraison pouvant être une maquette en carton. Entre la première maquette en carton et le cockpit final, et même l'avion, il y aura autant d'étapes suivant les préceptes Agiles.
L'itératif incrémental fonctionne sur des objets physiques et pas seulement sur du logiciel.
On peut par exemple :
Adapter la taille idéale de l'équipe à la réalité de l'entreprise
Gérer la diversité des métiers (pas que des programmeurs) et les impacts sur la planification
Accepter de changer le rythme des réunions
Intégrer le fait que des personnes sont partagées sur plusieurs projets à la fois
Favoriser le travail multi-sites plutôt que de promouvoir uniquement le rapprochement par plateau
...
Ces acteurs de l'Agilité pour l'industrie, qu'ils soient internes (membres de l'équipe étendue) ou externes (consultants, facilitateurs...) et que ce soit pendant le déploiement ou durant l'exploitation, ne doivent PAS être des ayatollahs de l'Agilité ou des experts certifiés Scrum master black belt turlututu. Ce n'est pas nécessaire et c'est même généralement néfaste.
Il ne faut pas que le dogme l'emporte sur l'écoute et l'adaptation : au domaine, à l'entreprise, à l'équipe, aux autres services, au rythme de production... Il faut qu'ils aient connu l'industrie et l'Agilité, qu'ils aient une forte capacité d'écoute et d'adaptation.
Les concepts et outils de l'Agilité viennent à l'origine de l'informatique mais SolidCreativity travaille depuis 2002 pour mettre l'Agilité à disposition de tous les métiers créatifs et secteurs innovants, les R&D.
Un déploiement en entreprise nécessite un accompagnement global et des formations ciblées.
Depuis la décision jusqu'au succès, l'entreprise pourra se faire accompagner pour toutes les étapes (audit, formation, suivi). Les accompagnateurs proposeront plusieurs indicateurs de suivi (équipe, projet, intégration de la méthode...).
Seul ou accompagnée, l'entreprise doit commencer par se questionner sur la nécessité, l'adéquation et l'envie de devenir Agile. C'est un changement important et un avis extérieur peut aider à y voir clair.
Parmi les questions :
Quelle est ma gestion actuelle de projets, me donne-t-elle satisfaction ?
Les équipes sont-elles satisfaites, le moral est-il au service du projet ?
Les projets que nous gérons sont-ils répétitifs ou innovants, l'Agilité est-elle possible ?
Si nous devions devenir Agile, cela concernerait-il toute l'entreprise ?
Quel projet pourrait être pilote ?
Après une formation, des outils adaptés (multi-sites ou non, papier ou informatique) pourront être mis en place mais ce n'est pas crucial et uniquement dépendant des bonnes pratiques Agiles installées.
Ce n'est pas l'outil qui rend l'entreprise Agile, c'est l'équipe formée et les pratiques adoptées.
Les équipes peuvent être formées dans un objectif évident d'autonomie. Une formation de 2 jours suffit si elle est suivie par un suivi lors des premiers pas et un accompagnement sur le terrain. SolidCreativity propose cette formation Agile ici.
Nouveau, pour les consultants ou les managers qui n'ont pas à gérer le projet mais veulent connaitre la pertinence et la qualité d'une gestion Agile, SolidCreativity propose une formation d'Audit en Agilité ici.