- \n
- 1986 – “The New New Product Development Game” Hirotaka Takeuchi et Ikujiro Nonaka publient un article dans la Harvard Business Review\u00a0qui est consid\u00e9r\u00e9 comme fondateur.<\/li>\n\n\n\n
- 1996 – SCRUM Jeff Sutherland et Ken Schwaber<\/li>\n\n\n\n
- 1999 – Extreme Programming Explained de Kent Beck.<\/li>\n\n\n\n
- 2001 – Le Manifeste pour le d\u00e9veloppement agile de logiciels => the \u201cagile manifesto\u201d<\/li>\n<\/ul>\n\n\n\n
Si au commencement l’agilit\u00e9 ne se concentrait que sur une \u00e9quipe, travaillant de fa\u00e7on autonome et en responsabilit\u00e9, sur un probl\u00e8me complexe donn\u00e9 pour concevoir, tester, coder, livrer et suivre sa solution logicielle. Tr\u00e9s rapidement la question s’est pos\u00e9e “comment faire quand on est plus qu’une seule \u00e9quipe?” \ud83e\uddd0<\/p>\n\n\n\n
- \n
- 2005 : Craig Larman et Bas Vodde commencent \u00e0 d\u00e9velopper et promouvoir LeSS (Large-Scale Scrum)<\/strong>, une extension\/\u00e9vol de Scrum pour des \u00e9quipes multiples travaillant sur le m\u00eame produit.<\/li>\n<\/ul>\n\n\n\n
2005 !! \ud83d\ude31 Il y a 20 ans !!!<\/p>\n\n\n\n
Puis tout s’enchaine et s’acc\u00e9l\u00e8re :<\/p>\n\n\n\n
- \n
- 2007 : Dean Leffingwell commence \u00e0 formaliser (et a publier) SAFe, visant \u00e0 appliquer les pratiques agiles \u00e0 des organisations \u00e0 grande \u00e9chelle.<\/li>\n\n\n\n
- 2007- Enterprise Kanban<\/strong> (ou Portfolio Kanban) par David J. Anderson.<\/li>\n\n\n\n
- 2011 – Publication de SAFe 1.0<\/strong> Dean Leffingwell et Drew Jemilo.<\/li>\n\n\n\n
- 2012 –\u00a0 Publication du livre blanc Scaling Agile @ Spotify,<\/strong> par Henrik Kniberg et Anders Ivarsson<\/li>\n\n\n\n
- 2012- Agile Fluency Model <\/strong>de Diana Larsen and James Shore<\/li>\n\n\n\n
- 2014 – Scrum@Scale<\/strong> – Jeff Sutherland.<\/li>\n\n\n\n
- 2014 – XScale<\/strong> par Peter Merel.<\/li>\n\n\n\n
- 2015 : Open Space Agility <\/strong>– par Daniel Mezick<\/li>\n\n\n\n
- 2015 – Choose Your WoW!,<\/strong> de Scott Ambler\u00a0 et Mark Lines pose les bases de Discipline Agile Delivery<\/li>\n\n\n\n
- 2015 – NEXUS <\/strong>– Ken Schwaber.<\/li>\n\n\n\n
- 2015 – FAST <\/strong>Agile de Ron Quartel.<\/li>\n<\/ul>\n\n\n\n
En 10 ans tout est pos\u00e9 ou presque. Que c’est-il pass\u00e9 depuis 2015 me demanderez-vous ? Pas grand chose<\/p>\n\n\n\n
- \n
- LeSS => LeSS Huge<\/li>\n\n\n\n
- Acquisition de Disciplined Agile par PMI<\/li>\n\n\n\n
- et surtout SAFe 1.0, SAFe 2.0, SAFe \u2026 SAFe 6.0 qui devient omnipr\u00e9sent et “leader du march\u00e9”<\/li>\n<\/ul>\n\n\n\n
Source : States of agile reports 2022<\/figcaption><\/figure>\n\n\n\n Mais cette id\u00e9e fausse que l’agilit\u00e9 \u00e0 l’\u00e9chelle est toute r\u00e9cente et vient de SAFe, n’est pas le seul mythe, et certains de ces croyances peuvent etre probl\u00e9matiques.<\/p>\n\n\n\n
Les mythes de l’agilit\u00e9 \u00e0 l’\u00e9chelle \ud83c\udfad<\/h2>\n\n\n\n
Mythe 1 : L’agilit\u00e9 \u00e0 l’\u00e9chelle signifie “simplement” ajouter plus d’\u00e9quipes<\/strong> Beaucoup pensent que pour \u00e9tendre l’agilit\u00e9, il suffit d’ajouter plus d’\u00e9quipes agiles.<\/p>\n\n\n\n
En r\u00e9alit\u00e9, scaler l’agilit\u00e9 n\u00e9cessite des changements organisationnels profonds, y compris dans la structure de gestion, la culture, et les processus. Ajouter plus d’\u00e9quipes sans adapter ces aspects conduit souvent \u00e0 des inefficacit\u00e9s et \u00e0 une complexit\u00e9 accrue.<\/p>\n\n\n\n
Mythe 2 : Un cadre universel fonctionne pour toutes les organisations<\/strong> Il existe une croyance que des cadres comme SAFe, LeSS ou m\u00eame “le mod\u00e8le Spotify” peuvent \u00eatre appliqu\u00e9s tels quels dans n’importe quelle organisation.<\/p>\n\n\n\n
En r\u00e9alit\u00e9, chaque organisation a des besoins uniques et ces cadres doivent \u00eatre adapt\u00e9s sp\u00e9cifiquement \u00e0 leur contexte et \u00e0 leur culture pour r\u00e9ussir<\/p>\n\n\n\n
Mythe 3 : Les \u00e9quipes autonomes n’ont pas besoin de Leadership<\/strong> Un autre mythe est que les \u00e9quipes autonomes fonctionnent sans aucun leadership.<\/p>\n\n\n\n
En r\u00e9alit\u00e9, un leadership actif et engag\u00e9 est crucial pour guider, soutenir et aligner les \u00e9quipes sur les objectifs strat\u00e9giques de l’organisation. Les leaders doivent \u00e9galement favoriser un environnement propice \u00e0 l’autonomie et \u00e0 l’innovation<\/p>\n\n\n\n
Mythe 4 : L’agilit\u00e9 \u00e0 l’\u00e9chelle se concentre uniquement sur les \u00e9quipes de D\u00e9veloppement => et donc sur le Delivery<\/strong><\/p>\n\n\n\n
En r\u00e9alit\u00e9, pour r\u00e9ussir, l’agilit\u00e9 doit \u00eatre adopt\u00e9e par l’ensemble de l’organisation, y compris les d\u00e9partements de marketing, de finance, de ressources humaines, et autres, afin de soutenir une approche v\u00e9ritablement agile et collaborative<\/p>\n\n\n\n
Par ailleurs restreindre le champ uniquement sur le Delivery en d\u00e9connectant des phases de Discovery ou Run, c’est c’exposer aux risques mortels de la Feature factory x 100 (une excellente fa\u00e7on de bruler votre argent)<\/p>\n\n\n\n
Mythe 5 : L’agilit\u00e9 \u00e0 l’\u00e9chelle est juste une mode<\/strong> Certains pensent que l’agilit\u00e9 \u00e0 l’\u00e9chelle est une tendance passag\u00e8re, ou une lubie de grosses entreprises pour se croire agile. On a d\u00e9ja vu plus haut que ce n’est pas r\u00e9cent comme questionnement, et il serait un peu insultant de croire que c’est l’agilit\u00e9 n’est pas envisageable pour les grands groupes ou les industriels.<\/p>\n\n\n\n
et bien s\u00fbr pour finir Mythe #6 : “agilit\u00e9 \u00e0 l’\u00e9chelle = transformation agile” avec un arri\u00e8re plan la croyance qu’un changement de culture et d’organisation peut se faire en 3 quarter en suivant une roadmap d’impl\u00e9mentation de votre framework pr\u00e9f\u00e9r\u00e9.<\/strong><\/p>\n\n\n\n
R\u00e9alit\u00e9 : Un cadre agile n’est pas une transformation, et faire \u00e9voluer une culture est un processus continu qui demande du temps, de la patience et de l’engagement.<\/p>\n\n\n\n
Les r\u00e9alit\u00e9s du terrain : retours d’exp\u00e9rience \ud83c\udf31<\/h2>\n\n\n\n
Lors de ma conf\u00e9rence \u00e0 l’Agile Tour Gen\u00e8ve 2024, j’ai partag\u00e9 plusieurs cas concrets d’impl\u00e9mentation de l’agilit\u00e9 \u00e0 l’\u00e9chelle :<\/p>\n\n\n\n
- \n
- LeSS (Large-Scale Scrum)<\/strong> chez un \u00e9diteur de logiciels en mode SaaS. L’adoption de LeSS a permis de r\u00e9duire les silos entre les \u00e9quipes. Cependant, la transition a \u00e9t\u00e9 difficile pour certain\u00b7e\u00b7s managers qui ont d\u00fb repenser leur r\u00f4le.<\/li>\n\n\n\n
- SAFe (Scaled Agile Framework)<\/strong> au sein du groupe AIRBUS, notement sur le projet SKYWISE, mais aussi sur des projets non IT (\u00e9lectrom\u00e9canique) ou en tant que v\u00e9hicule de transformation. Les r\u00e9sultats ont \u00e9t\u00e9 positifs en termes d’alignement strat\u00e9gique, de ramp up \/ ramp down rapide (r\u00e9silience) et de compatibilit\u00e9 culturelle avec la culture tr\u00e9s cadrante \/ process oriented de l’avionneur.<\/li>\n\n\n\n
- Open Space Agility <\/strong>au sein d’une banque, comme strater et catalyseur de transformation de la DSI puis par extension jusqu’aux M\u00e9tiers. Ce cadre tr\u00e9s l\u00e9ger et peu prescriptif a permis une grande flexibilit\u00e9 et a favoris\u00e9 l’innovation, mais a n\u00e9cessit\u00e9 un fort leadership pour “autoriser” le changement et maintenir la coh\u00e9sion.<\/li>\n\n\n\n
- “Mod\u00e8le Spotify”<\/strong> au sein de Spotify \ud83d\ude09<\/li>\n<\/ul>\n\n\n\n
- SAFe (Scaled Agile Framework)<\/strong> au sein du groupe AIRBUS, notement sur le projet SKYWISE, mais aussi sur des projets non IT (\u00e9lectrom\u00e9canique) ou en tant que v\u00e9hicule de transformation. Les r\u00e9sultats ont \u00e9t\u00e9 positifs en termes d’alignement strat\u00e9gique, de ramp up \/ ramp down rapide (r\u00e9silience) et de compatibilit\u00e9 culturelle avec la culture tr\u00e9s cadrante \/ process oriented de l’avionneur.<\/li>\n\n\n\n
- LeSS (Large-Scale Scrum)<\/strong> chez un \u00e9diteur de logiciels en mode SaaS. L’adoption de LeSS a permis de r\u00e9duire les silos entre les \u00e9quipes. Cependant, la transition a \u00e9t\u00e9 difficile pour certain\u00b7e\u00b7s managers qui ont d\u00fb repenser leur r\u00f4le.<\/li>\n\n\n\n
- 2011 – Publication de SAFe 1.0<\/strong> Dean Leffingwell et Drew Jemilo.<\/li>\n\n\n\n
- 2005 : Craig Larman et Bas Vodde commencent \u00e0 d\u00e9velopper et promouvoir LeSS (Large-Scale Scrum)<\/strong>, une extension\/\u00e9vol de Scrum pour des \u00e9quipes multiples travaillant sur le m\u00eame produit.<\/li>\n<\/ul>\n\n\n\n