Thanks to Benoît Laplante for pointing this reference document to the Valeur(s) & Management LinkedIn group where we share about corporate improvement methods !
But first thanks to Dr Nicolas Figay from Airbus for his article about « What’s the Difference? Agile vs Scrum vs Waterfall vs Kanban » which will certainly help a lot of people confronted with these IT buzzwords (especially the non-IT like me …) ! If you want to understand better what is behind these up-to-date ways of designing IT solutions, just read it !
I appreciate people helping others understand what’s behind hype methods with simple words (probably so that I understand them ;-). Our readers know this is precisely the idea behind V&M, with a specific approach : focusing on what methods share, more than their differences. The V&M book authors discovered that many a specific mindset / paradigm allowing to implement ‘system thinking’, by simply focusing on :
- 1° « what is it for? » to define real needs,
- 2° « what is enough ? » to save resources,
- 3° « work WITH the stakeholders » to answer these 2 questions.
Obviously, Agile and Scrum share this focus on working with users to serve their needs and avoid unuseful time and efforts. Lean also. But we know of other methods and tools used in other domains (purchasing, product/services design …) as well as IT projects (e.g. in business analysis or requirements management) that can improve A LOT :
- the expression of needs : Which user know and tell their needs ? How to avoid/manage changing needs ?
- the management of needs : How to manage incomplete expressions and/or ‘Christmas wish lists’ ? How to link users needs, systems requirement, solution features, component characteristics, … and time and costs ? How to manage ‘irrational’ requirements ?
- the checking of REAL user needs : Probably the most important and difficult part of all ?
- the earliest expression of needs of ALL stakeholders : Not only users, but all people which will have a word to say in validating the solution ! How to transform resistance to change into building on stakeholders motivations ?
- the pointing out of cost/time inducers : Which needs are/would lead to over-dimensioning the solution ? Is it worth ? Are all resources really useful ?
- the generation of disruptive creativity : How to discover solutions existing in completely different worlds ? How to help suppliers innovate for you ?
- the choice of the best solution(s) : How to make all stakeholders decide together on the optimal solution(s) ? How to select the best solution(s) ? (s) to insist that the optimal solution often is different for different stakeholders, so on avoiding unuseful standardisation, which is the major cost of overcost I have met in 20 years of value(s) creation experience !
Just like Nicolas Figay points out in this article by pointing out ‘when’ these tools better apply, let us create synergies between methods, more than ‘chapels’ ?
Permaliens
Amanda Athuraliya, Communication Specialist at Creately, proposes to add a libnk to one of her articles. Of course ! This is what she wrote :
« I actually wrote a very similar article recently with tons of research and actionable advice that I thought might be very useful to your readers. Just wondering if you might be interested in updating your piece to include my link.
I’ll let you be the judge though, check it out!
https://creately.com/blog/diagrams/what-is-scrum-methodology-scrum-process/
What do you think? »
Permaliens
Je ne comprend pas comment on peut entreprendre de comparer une série de principes directeurs de développement (AGILE) avec une de ses méthodes de mise en oeuvre (SCRUM) et encore moins avec d’autres principes transverses comme KANBAN qui peuvent s’appliquer à n’importe quoi. Ces différents référentiels sont intégralement mixables (d’où SCRUMBAN et AGILEBAN)… Comment peut-on classer SCRUM, qui est la méthode agile la plus répandue et AGILE, qui en est la maison-mère ? A la limite, comparer SCRUM à XTREM Programming ou à DSDM, ça aurait du sens, mais là ?…
Cette compilation est juste l’occasion de placer les avantages des méthodes agiles, dans leurs différentes déclinaisons, par rapport à la démarche WATERFALL
Par ailleurs, si les avantages des méthodes agiles sont abondamment cités (et ils sont bien réels), quelques inconvénients sont omis, comme la très grande difficulté de contractualiser ce type de démarche avec un fournisseur externe, qui peut très bien ne pas avoir le même agenda que le maître d’ouvrage et tirer parti de l’ouverture extrême du système (incertitudes sur le produit final, sur la date finale et sur le coût final, pas moins) et, à l’inverse, sur les risques liés à l’attribution précoce (avant toute définition complète du besoin, qui est élaborée « en allant ») du développement à des ressources externes, dont les compétences sont limitées, voire orientées. Si votre équipe ne maîtrise pas le langage JAVA, par exemple, quelle chance avez-vous que le développement soit fait en JAVA ? Aucune, même si c’est la meilleure solution pour votre cas de figure.
Autre point passé un peu sous silence, la difficulté chronique, voire atavique d’obtenir une documentation complète est bien citée dans l’article, mais ses conséquences sur la sécurité, la robustesse et la maintenabilité ne sont pas du tout évoquées…
Dernier point enfin, les fonctions transversales d’un SI, qui ne sont obtenues que par l’addition des résultats d’un grand nombre de « Workpackages » ne sont pas vraiment faciles à découper en « Timeboxes », pas plus que ce qui est relatif à l’infrastructure de l’ensemble, avec ses fonctions techniques et de support ne peut être décrit en terme de « livrables opérationnels » immédiats.
Pour conclure, cet article ne pointe pas les vrais critères de choix entre méthodes agiles, et méthodes plus classiques (qui peuvent parfaitement utiliser le Kanban et quelques outils agiles, mais à partir d’une philosophie différente).
Aux deux extrémités du spectre, il me semble que l’on pourrait dire que les projets de développement de produits à courte durée de vie, vite périmés, et relativement légers, comme les applications smartphone part exemple, peuvent parfaitement faire l’objet de ces démarches, alors que les gros systèmes complexes à gros enjeux sécuritaires et beaucoup d’interfaces le peuvent beaucoup moins.
AGILE a été conçu en réaction aux analyses lourdes et exhaustives du type MERISE et aux planifications linéaires du type WATERFALL, mais l’association de l’analyse fonctionnelle et du CYCLE EN V (non cité dans l’article) a très largement assoupli ces rigidités.
En fait, je ne suis d’accord avec cet article que sur un point de sa conclusion, ce sont les attendus et le contexte de chaque projet qui doivent guider le choix des outils méthodologiques, et pas l’application d’une démarche routinière ou d’un choix préétabli. Sauf qu’il faut élargir beaucoup le panorama des possibilités, et ne pas présenter comme alternatives une méthode et ses principes fondateurs…