Ces termes sont si fréquemment utilisés (et mal utilisés) que leur impact peut être perdu, mais comprendre comment chaque approche fonctionne (et pourquoi leur combinaison est si puissante) est essentiel pour créer de meilleurs logiciels, plus rapidement.
Cet article décompose chaque approche, utilise des analogies du monde réel et explore pourquoi la combinaison des deux est plus efficace que l’une ou l’autre seule.
Qu’est-ce que le développement itératif ?
Un processus itératif progresse par le raffinement.
Une approche itérative du travail commence par une version approximative d’une fonctionnalité ou d’un produit, puis l’améliore grâce à des cycles répétés, chacun se rapprochant peu à peu de la forme finale.
Par exemple, un sculpteur qui aborde le travail de manière itérative peut commencer par sculpter grossièrement un bloc de pierre. À chaque passage, il affine la forme, ajoutant des détails, lissant les bords et s’améliorant continuellement jusqu’à ce que la sculpture atteigne sa forme finale. La sculpture n’est pas terminée tant que l’ensemble de la pièce n’est pas terminé.
Qu’est-ce que le développement incrémental ?
Un processus incrémental permet de créer et de livrer des fonctionnalités et des produits en plusieurs parties. Chaque élément, ou incrément, représente un sous-ensemble complet de fonctionnalités.
Les incréments peuvent être petits ou grands. L’objectif est de terminer chaque incrément de fonctionnalité dans son intégralité avant de passer au suivant, sans qu’il soit nécessaire de revenir en arrière et de repasser sur ce travail plus tard. Chaque incrément terminé peut être livré seul.
Pour en revenir à l’analogie de la sculpture, un sculpteur incrémental choisirait un élément de la sculpture et se concentrerait sur celui-ci jusqu’à ce qu’il soit terminé. Il peut choisir de petits incréments (d’abord le nez, puis les yeux, puis la bouche, et ainsi de suite) ou de grands incréments (tête, torse, jambes puis bras). Cependant, quelle que soit la taille de l’incrément, le sculpteur incrémental tenterait de terminer le travail de cet incrément aussi complètement que possible avant de passer à autre chose.
Les équipes agiles combinent incrémental et itératif.
Le développement agile combine les deux approches pour obtenir le meilleur des deux mondes :
C’est itératif parce que le plan est que chaque pièce soit affinée et améliorée au fil du temps.
C’est incrémental car des logiciels fonctionnels utilisables sont livrés tout au long du projet.
Cette combinaison permet aux équipes d’apporter de la valeur dès le début, d’obtenir des retours et de s’adapter.
La vidéo ci-dessous montre comment le comédien Jerry Seinfeld aborde son travail d’une manière à la fois incrémentale et itérative.
Exemple concret : Création d’une application de rencontres.
Imaginez que vous développez un site de rencontres. Voici comment chaque approche fonctionnerait.
Purement itératif
Vous construisez et bénéficiez d’un peu de toutes les fonctionnalités : Profils, recherche, chat, etc.
Vous revenez en arrière et améliorez chacun d’entre eux au cours de plusieurs cycles.
Au fil du temps, l’ensemble du système est perfectionné puis, finalement, livré.
Purement incrémental
Vous créez et fournissez une version parfaite de la fonction de gestion des profils. Vous ne commencez rien d’autre avant que ce soit terminé.
Vous construisez et livrez une version parfaite d’une deuxième zone, disons la recherche. Vous passez ensuite à la suivante.
Chaque fonctionnalité est parfaite avant le début de la suivante.
Itératif + Incrémental (Agile)
Vous commencez avec une version de base du profil utilisateur, vous la livrez. Vous obtenez des commentaires.
Vous ajoutez la possibilité d’ajouter une image au profil de l’utilisateur et de fournir une version de base de la fonctionnalité de recherche. Vous obtenez à nouveau des commentaires.
Vous réorganisez les champs sur le profil utilisateur pour améliorer l’expérience utilisateur. Vous ajoutez des filtres à la fonctionnalité de recherche. Vous créez un schéma de la fonction de chat. Vous obtenez davantage de commentaires.
Les sprints suivants peuvent inclure des améliorations apportées aux fonctionnalités précédentes et des versions de nouvelles fonctionnalités utilisables. Ou les deux.
Une approche agile permet des mises en production précoces, des expérimentations à faible risque et des corrections de cap fréquentes, caractéristiques des équipes performantes.
L’agilité est itérative et incrémentale
Ni le développement incrémental ni le développement itératif n’apportent à eux seuls beaucoup de valeur. Mais ensemble, ils forment la colonne vertébrale de l’agilité.
L’itération aide les équipes à affiner et à s’adapter. L’incrémental garantit une progression constante et une création de valeur. Combinés, ils permettent d’obtenir de l’agilité, de la réactivité et des résultats concrets.
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le management de projet hybride vient de connaître son heure de gloire !
Le Project Management Institute Pulse of the Profession® 2024 déclare que l’approche hybride (32 %) est maintenant la deuxième approche la plus couramment utilisée. L’approche prédictive (44 %) détient toujours une avance considérable. Et l’utilisation d’Agile(26 %) perd 2 points.
Avant de nous enthousiasmer, le rapport sur l’état de l’agilité (State of Agile Report) identifie différentes tendances. et ses répondants préfèrent l’agilité (70 %) à l’hybride (47 %) et à l’approche prédictive Waterfall (35 %).
Derrière cette annonce
Plusieurs facteurs peuvent être à l’origine de ces tendances récentes :
Agile et Waterfall sont les angles du continuum de management de projet, et l’hybride en est le vaste milieu. La plupart des organisations ne pratiquent ni l’agilité pure ni l’approche prédictive ; L’hybride est donc une description plus exacte.
L’intérêt pour les hybrides est nouveau et augmente rapidement. Le format de l’ examen PMP a changé en janvier 2020. Dans le nouveau test, 27 % des questions étaient hybrides et 23 % agiles. Cela a déclenché une explosion du trafic de recherche Google pour le « management de projet hybride ».
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes
Agile a peut-être « heurté le mur ». L’agilité est fondamentalement un état d’esprit, pas une méthodologie. Les principaux défis de l’adoption de l’agilité sont organisationnels et culturels. Le rapport sur l’état de la culture Agile montre que seuls 10 % des leaders font preuve des qualités souhaitées.
La palette d’approches de projet
La profession de manager de projet se décrivait historiquement en termes discrets. Waterfall avait une emprise quasi monopolistique jusqu’à l’avènement de l’agilité. La profession est alors entrée dans un monde bipolaire : agilistes contre traditionalistes.
En réalité, le management de projet est désordonné. On peut le décrire comme « la cathédrale versus le bazar ». Les développeurs de cadres de travail parlent dans les termes absolutistes de la cathédrale, tandis que les managers de projet mélangent les pratiques comme on le voit dans un bazar.
Hybride nous permet de donner un nom à ce mélange de la vaste palette de couleurs. Prédictif, agile et Lean/Kanban peuvent être considérés comme les pointes d’un triangle avec un éventail presque infini d’options.
Le spectre des approches peut être étiqueté comme suit :
Prédictif. L’approche traditionnelle, prédictive et très structurée ;
Agile (Scrum). Une approche adaptative avec des équipes autonomes et auto-organisées ;
Lean/Kanban. Des principes axés sur les valeurs et les flux qui peuvent être intégrés dans toutes les approches ;
Hybride-prédictif. Des structures principalement traditionnelles avec des pratiques agiles intégrées ; et
Hybride-agile. Une approche adaptative tempérée par les contraintes traditionnelles.
Relisez ce billet : « Que signifie vraiment ‘en cascade’ (Waterfall) dans le management de projet ? Comment les gens utilisent-ils cette expression ? »
Prédictif
Winston Royce a décrit pour la première fois l’approche waterfallen 1971 comme une méthodologie de développement logiciel basée sur son expérience de la construction de systèmes pour les engins spatiaux. Il a défini une série d’étapes en cascade allant de la collecte des besoins aux opérations de déploiement.
relisez ce billet sur les bénéfices de l’approche Waterfall (‘en cascade’)
L’établissement précoce des exigences et des spécifications de conception est une caractéristique essentielle des projets prédictifs. Cette approche est utilisée dans la construction et les efforts similaires où le coût du changement est élevé. Les projets ont souvent des passages de phase rigides pour confirmer la viabilité et l’exhaustivité avant de passer à l’étape suivante.
Les équipes de projet travaillent sur leurs composants individuels et intègrent et testent périodiquement leur travail. Le rôle principal du manager de projet est de coordonner et de superviser les efforts de ces équipes alignées sur le plan fonctionnel. Une collaboration inter-équipes limitée est nécessaire.
L’engagement des parties prenantes est plus important au début du projet, lorsque les exigences sont collectées et analysées. Tout au long du cycle de développement, il y aura des réunions et des revues périodiques de l’état d’avancement. Il faut souvent des années avant que les parties prenantes ne voient le produit fini.
Agile (Scrum)
L’agilité est un état d’esprit, pas une méthodologie. De multiples cadres de travail frameworks (Scrum, eXtreme Programming, DSDM, Scaled Agile (SAFe), Disciplined Agile, etc.) permettent aux équipes de fournir de la valeur plus rapidement et de manière plus prévisible. Les cadres de travail ne sont pas monolithiques et représentent un éventail d’approches et de pratiques.
Scrum est la méthodologie la plus couramment utilisée et ancre cet angle du triangle. Scrum décrivait à l’origine comment développer un nouveau produit et a ensuite été adopté pour des projets logiciels complexes par Jeff Sutherland et Ken Schwaber.
Plusieurs vidéos intéressantes sur Scrum en langue anglaise
Royce s’est rendu compte que les cycles de test tardifs et les délais de livraison prolongés de l’approche prédictive waterfall posaient un risque important. Scrum atténue ces risques grâce à son approche itérative et incrémentielle. Les cycles de développement sont généralement limités à 2 semaines, après quoi les parties prenantes fournissent des retours. Le retour d’information est utilisé pour adapter et ajuster le produit et éviter le piège du « je le saurai quand je le verrai ».
Les équipes Scrum sont petites (moins de 10), auto-organisées et exploitent les énergies créatives des travailleurs du savoir. Le manager de projet de type « commande et contrôle » est remplacé par le scrum master serviteur, dont le rôle principal est d’aider l’équipe à mûrir. Le Product Owner est un membre à part entière de l’équipe et représente la voix du client.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Lean/Kanban
Le Lean et le Kanban sont un ensemble de principes et de pratiques, datant des années 1950, développés à l’origine par Toyota. Le Lean se concentre sur la création de valeur et l’élimination du gaspillage. Kanban est une sous-pratique Lean qui se concentre sur la création et la gestion de flux.
Tableau Kanban pour tâches et projets avec Christian Hohmann
Lean/Kanban est la troisième extrémité du triangle. Bien qu’ils soient souvent associés à l’agilité, leurs pratiques sont universelles. Ceci est fondamental pour la plupart des frameworks agiles, et les équipes agiles très matures se concentrent souvent sur le flux (Kanban). Dans Disciplined Agile, le Lean est défini comme un cycle de vie autonome. SAFe 6.0 sépare l’équipe Kanban de son approche Scrum.
Hybride-Prédictif
L’hybride-prédictif suit principalement la structure linéaire waterfall et intègre des pratiques de type agile. La structure conception-construction-test-déploiement prend en charge efficacement de nombreux types de projets. Cependant, les approches purement prédictives peuvent être rigides et reposer sur l’hypothèse forte que la solution peut être définie dès le début du projet.
Avez-vous déjà lu ce billet : Qu’est-ce que Agile Hybride en réalité ?
Les équipes logicielles ont commencé à utiliser des approches en « waterfall modifié » dans les années 1970, bien avant l’avènement de l’agilité. Ils ont utilisé des approches itératives et progressives pour mobiliser les intervenants. Des sessions de prototypage et de conception d’applications conjointes (JAD) ont permis aux utilisateurs et aux développeurs de collaborer sur la solution.
Même la construction, qui est le bastion de l’approche en cascade, a adopté l’hybride. Traditionnellement, la conception et la construction sont des activités spécialisées et séparées. Les firmes d’architecture et d’ingénierie créent des plans et des devis qui sont ensuite exécutés par les entreprises de construction. Cependant, la conception-construction combine ces deux activités en un seul contrat exécuté par une seule entreprise. Cette approche améliore la collaboration, la coordination et la communication. Les avantages sont des cycles de développement plus courts, des coûts réduits, moins d’erreurs et une responsabilité claire.
L’approche prédictive-hybride peut être décrite comme penchant davantage vers la structure waterfall et intégrant des pratiques agiles. Il existe plusieurs modes d’utilisation. L’un est un projet structuré qui utilise des techniques agiles telles que des stand-ups quotidiens, une documentation minimale suffisante et un engagement fréquent des parties prenantes. Un autre modèle est la conception initiale de haut niveau avec un développement itératif et/ou une livraison incrémentielle.
Hybride-Agile
De nombreuses organisations prétendant être agiles utilisent probablement une approche hybride-agile. Elles suivent un modèle de type Scrum et utilisent de nombreuses pratiques agiles. Cependant, des contraintes empêchent l’adoption de l’état d’esprit agile. Ces limites sont souvent liées à la culture, à la structure et à la nature du travail de l’organisation.
Les grandes entreprises bureaucratiques, les agences gouvernementales et les organisations à faible maturité agile correspondent à ce modèle. Elles peuvent suivre de nombreuses pratiques de Scrum ; Cependant, elles font face à de nombreux défis, notamment :
Le contenu du projet est fixe et la solution complète est livrée à la fin du projet.
Les parties prenantes ne participent pas activement aux démonstrations progressives du produit et des tests d’acceptation approfondis par les utilisateurs sont effectués à la fin.
Les équipes ne sont pas habilitées à prendre des décisions. Les décisions sont prises par la direction ou par un comité.
Les équipes ne sont pas établies depuis longtemps et les membres sont affectés à plusieurs projets.
Le Product Owner vient de l’équipe technique et ne représente pas pleinement la voix du client.
“PMI”, the PMI logo, “PMP”, “PMBOK”, “PM Network”, “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).
Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets
Le manque de transparence cause des malentendus et des conflits.
Cependant, générer de la transparence a un coût.
Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.
Plusieurs des techniques les plus communes pour générer de la transparence
#1 – Le Contrat
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
#2 – Un Plan construit conjointement
Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres. La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur des risques et communiquer les dépendances en temps réel.
Matchware est partenaire de DantotsuPM
#3 – Des Cérémonies communes
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
#4 – Des Ateliers de mûrissement des exigences et de design
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
#5 – Des Modèles de design
L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.
Facile ET difficile à la fois
une plus grande transparence comme base de relations et de travail
Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.
partagez ce billet avec vos amis, collègues et relations professionnelles
– Les Scrum Masters avec une formation formelle Scrum et des certifications Agile ont des salaires plus élevés que les autres.
– Les tendances d’adoption montrent que 7 % continuent à utiliser l’approche Waterfall tandis que 11 % sont matures dans leur adoption Agile; les participants restants (donc la très large majorité) commencent ou sont en croissance d’usage.
– Les salaires des femmes Scrum Masters tendent à être plus élevés que ceux de leurs contreparties masculines.
“Le but de ce rapport est defournir de l’information aux Scrum Masters qui les aidera à en apprendre davantage sur le Scrum Master et les tendances des communauté Agiles. Scrum.org s’est associé avec Age of Product dans cette initiative pour fournir à la communauté des Scrum Masters des données pour partager une compréhension qui les aidera à diriger leurs carrières et continuer de s’améliorer.”
Vidéo de 1 heure en anglais qui détaille les résultats de cette enquête.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».
Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.
Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.
A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…
« Itératif » par rapport à « Incrémental » par rapport à « Agile »
Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …
Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».
« Mélangé » (Blended) versus « Hybride »
Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.
Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.
En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ». Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.
Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :
Mélangé = Agile + Agile = Meilleur Agile
Mais en ce qui concerne le reste d’entre nous simples mortels ?
Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?
Et bien, dans ces cas, vous devriez considérer « l’Hybride »
L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.
Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un plan simple serait “une Approche Hybride”.
Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:
L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens
Quand devrions-nous utiliser des approches Hybrides ?
Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.
Voici deux scénarios :
1. Hybride comme Adéquat en fonction du but
Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.
2. Hybride comme Transition-vers-Agile
Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.
Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.
CertYou est partenaire de DantotsuPM
Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Curieusement, l’auteur reste très dichotomique et ne considère pas dans ce billet une approche hybride entre les deux mondes adaptatif et prédictif mais son retour sur la genèse de la méthode Waterfall me parait intéressant à partager avec vous.
What Does ‘Waterfall’ Really Mean? How Do People Use That Word?
Y avez-vous jamais réfléchi ? Cette expression est souvent utilisée en comparaison de ‘Agile’ mais les gens savent-ils ce qu’ils font quand ils comparent ‘Agile’ à ‘en cascade’ ? Je pense que le mot ‘Waterfall’ est un des mots les plus abusés dans la langue anglaise (et le mot ‘Agile’ n’arrive pas loin derrière).
Quand les gens parlent de ‘Agile’ et ‘en cascade’, il semble qu’ils comparent deux méthodologies très spécifiques et bien définies qui sont les opposés binaires et mutuellement exclusifs l’un de l’autre. Cependant, quand vous fouillez dans ce que signifient vraiment les mots ‘Waterfall’ et ’Agile’, vous découvrez vite que c’est une comparaison très imprécise et prône à erreurs.
Que signifie vraiment ‘en cascade’ dans le management de projet ?
À proprement parler, le mot ‘ Waterfall ‘ a été à l’origine défini en 1970 par docteur Winston Royce dans son papier très célèbre :
Il a décrit un modèle qui consiste en ordonnancer un projet en phases où les livrables d’une phase coulent dans la phase suivante et qui donne quelque chose comme ceci :
Il l’a appelé ‘en cascade’ parce que les résultats d’une phase s’écoulent naturellement dans la phase suivante comme l’eau dans une ‘cascade’.
A quoi ressemblait la Vie avant ‘en cascade’ ?
Pour mieux comprendre, il est utile de voir à quoi ressemblait la vie avant ‘en cascade’ et quels problèmes cette méthode essayait de résoudre. Ce qui a précédé ‘en cascade’ était beaucoup d’efforts de développement mal organisés avec peu ou pas de structure, discipline et planification. Certains des problèmes principaux avec ces approches étaient :
Comme les projets grossissaient en termes de portée et de complexité avec de plus grands nombres de développeurs, il est vite devenu apparent qu’une approche plus planifiée et structurée était essentielle pour coordonner le travail de grosses équipes de développement
L’autre problème principal était une prévisibilité très limitée tant sur les dépenses que les délais des projets de développement informatique. Il y avait de fréquents en très importants dépassements de coûts et de délais et les commanditaires ont exigé un certain niveau de prévisibilité.
Pour ces raisons, quand l’approche ‘en cascade’ a été définie à l’origine, c’était une grande amélioration que de passer de pratiquement aucune méthodologie du tout à un processus très bien défini :
“Un plan d’ensemble” pour coordonner le travail de multiples développeurs ainsi que l’intégration de leur travail avec d’autres ressources essentielles en dehors des immédiates équipes de développement
Un mécanisme pour gagner un certain niveau de contrôle de la portée du logiciel (de son contenu ou périmètre) pour obtenir plus de prévisibilité des dépenses et des délais.
Beaucoup de personnes plus jeunes n’apprécient pas aujourd’hui cette historique et critiquent juste la méthode ‘en cascade’ comme étant mauvaise sans comprendre les problèmes qu’elle a été créée pour adresser.
relisez ce billet sur les bénéfices de ‘en cascade’
Quels étaient certains des problèmes avec l’approche de originale ‘en cascade’ ?
Comme dans beaucoup de choses, il y a un effet de « balancier » et, quand l’approche a été initialement mise en œuvre, il y avait le sorte d’une sur-correction dans de nombreux cas. Le balancier est passé dans beaucoup de projets de presque aucun contrôle ni discipline à un contrôle très rigide et très rigoureux. La pratique commune quand le processus ‘en cascade’ a été défini à l’origine en 1970 était un processus de documentation très intensif et un sur-contrôle où vous ne pouviez pas quitter une phase tant que toute la documentation exigée pour prouver que tout le travail demandé pour cette phase avait été achevé, passé en revue et approuvé.
C’était un processus très pénible et qui avait un certain nombre de problèmes que même le Dr. Royce a reconnus en 1970 quand il a défini le processus. Certains des problèmes les plus sérieux étaient :
L’utilisateur final du logiciel ne voyait pas normalement aucun logiciel avant que tout le développement et les tests ne soient complets et à ce moment-là, il était très difficile, sinon impossible, d’apporter quelques changements significatifs.
L’accent sur le contrôle du contenu rendait le processus très inflexible et résistant aux changements qui pourraient être nécessaires pour répondre aux besoins des utilisateurs et des objectifs business dans un environnement incertain.
En conséquence, il y a eu beaucoup de situations où le projet peut avoir respecté le coût et les délais, mais échoué à fournir un niveau suffisant de valeur business.
Un autre problème principal était que le lourd accent sur la documentation exigée pour les revues et les approbations rendait le processus tout entier bureaucratique et pas très efficace côté coûts.
Comment ‘en cascade’ s’est-elle développée pour Résoudre Ces Problèmes ?
Avant que Agile ne se répande, beaucoup de variations sur le modèle original ‘en cascade’ et d’autres modèles plus itératifs ont été développées et utilisées pour créer une approche plus adaptative et résoudre certains de ces problèmes. Un exemple était le Processus Unifié Rationnel (Rational Unified Process RUP) dont les origines peuvent être retracées jusqu’en 1996 et 1997. RUP a proposé une approche de développement itérative pour résoudre certains des problèmes de l’approche ‘en cascade’. RUP et les variations de RUP comme Enterprise Unified Process (EUP) sont devenus très populaires à la fin des années 1990 et au début d’années 2000.
En conséquence, si vous regardez ce que les gens ont fait en pratique pendant les 15 à 20 dernières années, il y a eu prolifération d’une large gamme de beaucoup de modèles différents (dont certains ont une ressemblance très limitée au modèle original ‘ Waterfall ‘ défini en 1970). Les gens les caractérisent toujours tous de ‘en cascade’ comme si c’était une méthodologie spécifique, unique et bien définie appelée ‘en cascade’ et ce n’est pas vraiment le cas. De la façon dont le mot ‘Waterfall’ est utilisé en pratique, il se réfère en réalité à une large gamme de méthodologies différentes.
Quelle est une façon plus précise de décrire ‘Agile’ versus ‘En cascade’ ?
Le dénominateur commun de toutes les méthodologies que les gens appellent ‘en cascade’ est qu’ils soulignent un certain niveau de planification en amont et de contrôle pour essayer de réaliser la prévisibilité sur le contenu du projet, des dépenses et des échéances. C’est pourquoi, je pense que « dirigé par un plan » est une description plus précise et objective de ce que les gens veulent vraiment dire quand ils disent ‘en cascade’.
Le mot ‘Agile’ est aussi utilisé de manière floue. Nous savons tous que ‘Agile’ n’est pas une méthodologie spécifique bien que beaucoup de personnes assimilent ‘Agile’ avec Scrum :
Scrum n’est pas vraiment une méthodologie spécifique, c’est vraiment une structure destinée à être adaptable à une large gamme de situations
Agile n’est pas vraiment l’équivalent de Scrum. Il y a d’autres méthodologies Agile comme Kanban
Il est assez facile de voir que le mot ‘Agile’ est aussi utilisé très largement pour qualifier une méthodologie spécifique et bien définie quand ce n’est pas le cas. Le dénominateur commun des méthodologies que les gens appellent ‘Agile’ consiste en ce qu’elles sont flexibles et adaptatives et soulignent la créativité et l’innovation dans un environnement incertain plutôt que la planification et le contrôle pour une prévisibilité avec des niveaux moindres de certitude. C’est pourquoi, je préfère utiliser le mot « adaptatif » au lieu du mot ‘Agile’ lors de la comparaison avec ‘en cascade’ (dirigé par un plan).
Pourquoi comparer « Dirigé par un plan » et « Adaptatif » est-il plus précis et objectif ?
Voici pourquoi je préfère utiliser une comparaison entre « Adaptatif » et « Dirigé par un plan » plutôt que ‘Agile’ versus ‘en cascade’ :
C’est plus précis
« Dirigé par un plan » n’implique pas de méthodologie spécifique. C’est une caractéristique d’une large gamme de méthodologies ce qui je pense décrit plus exactement ce dont parlent les gens.
C’est plus objectif
Le mot ‘Waterfall’ associe des tas de connotations très négatives car il ramène au modèle original ‘Waterfall’ défini en 1970 et ce que les gens appellent ‘en cascade’ peut aujourd’hui avoir peu de ressemblance avec l’original de 1970. L’expression « Dirigé par un plan » ne traine aucun de ces bagages négatifs.
Quand les gens dans la communauté Agile comparent ‘Agile’ et ‘en cascade’, c’est d’habitude dans le contexte Agile est bon et ‘en cascade’ mauvais et ce n’est ni vraiment précis ni objectif. Dire « ‘Agile’ est meilleure que ‘en cascade’ » s’apparente à dire “une voiture est meilleure qu’un bateau”.
Les deux ont des avantages et des inconvénients selon l’environnement dans lequel vous évoluez:
Une approche ‘dirigée par un plan‘ donne à son meilleur dans les projets qui ont un faible niveau d’incertitude et exigent un fort niveau de prévisibilité
Une approche adaptative marche mieux dans les projets qui ont un niveau élevé d’incertitude et exigent un focus sur la créativité et l’innovation pour trouver une solution optimum plutôt qu’une orientation sur la planification et le contrôle pour atteindre la prévisibilité
En bref
livre sur Amazon
Je ne pense pas avoir la moindre chance de faire en sorte que les gens cessent d’utiliser la comparaison ‘Agile’ versus ‘en cascade’ qui est trop largement utilisée. Je l’utilise même moi-même parfois parce que c’est une façon commode et simple de décrire quelque chose qui est en réalité beaucoup plus complexe. J’espère juste que les gens comprennent combien c’est une simplification excessive et à quel point ce peut être imprécis et trompeur.
L’auteur de ce billet, Chuck Cobb est l’auteur du livre « The Project Manager’s Guide to Mastering Agile » et il a développé un cours appelé “Learn the Truth About Agile Versus Waterfall” qui fournit plus de détail pour aider les gens à voir ces approches depuis une nouvelle perspective comme complémentaires l’une à l’autre plutôt que en compétition : Free Agile versus Waterfall course
N’hésitez pas à poster vos commentaires sur ce livre, ce cours et/ou ce billet…
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans cet article, l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et Agile.
Serhiy Kharytonov
Selon Serhiy Kharytonov, le choix entre les méthodes « en cascade », RUP (rational unified process) et agile, dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dispersion géographique de l’équipe.
Une combinaison des trois méthodes selon les moments du cycle de développement pourrait être une bonne approche.
Cet article qui date pourtant de presque dix ans reste étonnamment actuel.
Utilisez vous d’autres critères de choix de votre approche de développement?
Waterfall, RUP et Agile : quelle est la bonne méthode de développement logiciel pour vous?
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mix de stratégies de développement logiciel afin de répondre aux besoins spécifiques de votre projet.
Malgré les signes de reprise dans l’économie, une réalité persiste dans le développement logiciel: La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible.
Pour atteindre ces objectifs apparemment contradictoires, les développeurs cherchent à rationaliser la production avec des processus rapides et efficaces qui peuvent donner au client ce qu’il veut en un laps de temps le plus court possible.
Ces constantes et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel souvent appelées le modèle Waterfall / « en cascade », vers des modèles plus itératifs et progressifs tels que « Rational Unified Process » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que les processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, leurs incovénients et leurs environnements de projet favoris.
Au bout du compte, la meilleure méthode ou le meilleur mix de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, votre culture business et votre propre environnement de développement.
Waterfall / « En cascade »
La programmation « en cascade » est un processus fortement structuré qui compte fortement sur une planification initiale et un ensemble d’étapes séquentielles, prescrites qui découlent l’une de l’autre comme l’eau dans une une cascade. Chaque étape a typiquement sa propre équipe d’experts et jalons soigneusement préparés à l’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles. On appelle aussi souvent cette approche le cycle en « V ».
Typiquement les étapes dans le développement « en cascade » sont :
Recueil des besoins et rédaction du cahier des charges
Analyse fonctionnelle
Développement du code
Intégration
Test et mise au point
Installation
Maintenance
Ceci peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que le « Waterfall » demande simplement trop longtemps et manque de la flexibilité, ou de l’agilité, requise pour le marché logiciel actuel avec son environnement de développement en constant mouvement. Les projets qui suivent la méthode « en cascade » prennent typiquement des mois ou des années et quand ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut alors être des corrections onéreuses explosant le budget initial.
RUP (rational unified process)
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin de répondre au changement et introduit de l’adaptabilité pendant le processus de développement.
Comme la « cascade », RUP a une série de phases et des jalons qui découlent l’un de l’autre :
L’initiation, où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
La construction, où le logiciel est construit et testé et la documentation de support est produite.
La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.
RUP définit en détail les rôles et les activités de membres de l’équipe et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que de grandes quantités de documentations requises pour chaque étape « Waterfall ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de guides, modèles, outils et autres articles pour s’assurer qu’ils partagent les mêmes langages et perspectives sur le projet.
Alors que cela apparaît de prime abord similaire au développement « en cascade », la plus grande différence du RUP est son approche de développement itérative, qui construit le produit en plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin, de l’architecture et l’exploration de différentes idées, alors que les itérations ultérieures essayent d’assembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours utilisateurs.
RUP adresse bon nombre des critiques du développement « Waterfall » et c’est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » les développements dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide ni adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial et là où l’on s’attend à des mises à jour fréquentes et des compléments rapides de fonctionnalités.
Agile
Tandis que « Waterfall » et RUP penchent vers la prédictibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, dont XP et SCRUM, et tous s’efforcent de mettre une version du produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent les fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes périodes de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme en « Waterfall » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre d’équipes composées de nombreux experts, le processus de développement Agile est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La constante collaboration en face à face est l’objectif, avec le représentant du client comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à l’approche « Waterfall » et même RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement des besoins et réponses aux challenges amenés par la compétition, qui sont les raisons de tant de partisans.
Certaines sociétés sont fréquemment citées comme ayant utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont apporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, l’approche a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rend le processus difficile à adapter à l’externalisation des développements, à des situations où clients et développeurs sont géographiquement éloignés, ou aux clients qui n’ont tout simplement pas les compétences, les ressources ou le focus nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas aux clients qui veulent des contrats avec des évaluations fermes et définitives et des échéanciers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec de très nombreuses parties prenantes aux besoins différents et néglige de prendre en compte le besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec le « Waterfall » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
CertYou est partenaire de DantotsuPM
Le meilleur de chaque monde
Si Agile, RUP et des modèles « en cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret des développements logiciels réussis est de comprendre les trois processus dans le détail et de sélectionner les parties de chacun qui conviennent le mieux à leurs livrables et environnements spécifiques. Donc, être agile dans l’approche même du choix du processus, en regardant sans cesse ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux aux circonstances actuelles.
Par exemple, si vous développez du logiciel « Software as a Service » SaaS dans un marché fortement concurrentiel, vous ferez probablement le meilleur choix en penchant vers des méthodologies Agile. Le SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour y ajouter ou en changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateurs changeants, vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou autres systèmes qui exigent un haut degré de design et de certitude, alors il semble logique de commencer par du »Waterfall ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui vont être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière sur le recueil des besoins, la définition du périmètre et du contenu au tout début, ainsi que des standards de parcours et d’interface utilisateur.
Quel est le meilleur de chaque approche que vous puissiez utiliser sur votre projet ?
Les développeurs peuvent tout de même utiliser des techniques Agile pour présenter des prototypes fréquents et des modules successifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de la société (selon que ces équipes soient plus ou moins habituées à une telle collaboration). Quand la distance géographique est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’externalisation du développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contacts de suivi que possible pour votre projet.
Choisir de partir sur des équipes auto-organisées ou une approche plus directive (« top-down ») de management dépend aussi du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leadership qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins lors des itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et tous les environnements, ni même pour un seul.
C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement.
Bref, en choisissant entre Agile, RUP et « Waterfall », adaptez le processus à vos besoins, plutôt que de chercher à adapter votre projet au processus !
partagez ce billet avec vos amis, collègues et relations professionnelles
les articles les plus lus sur DantotsuPM de Juin 2017
Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !
Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.
certaines relations peuvent être particulièrement frustrantes !
Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.
PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.
La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.
Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.
Amy Thompson
Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?
J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.
Partenaire de DantotsuPM
Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.
L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)
partagez ce billet avec vos amis, collègues et relations professionnelles
Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.
The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!
But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:
o How will these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?
o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches? This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.
o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?
o How will you avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?
The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »
This presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.
The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:
Jack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle! »
Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:
As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods. These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.
Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we place more value to the items on the left.
The Agile approach should be considered rather as a philosophy of development
In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e. not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.
The Agility is good but to control it is even better …
– The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)
– The Lean Approach coming from the industry may not be implemented in all contexts
– The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation
– We must select the right AGILE tools best suited to the company
– A pragmatic coaching is a key success factor
– The dogmatism must be forgotten
– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).
Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.
Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!
Christine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years. Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships. . Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.
Marc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking. Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.
Sylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase). Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva. Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.
Bonus video : « Agile: An Introduction »
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.
Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?
Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.
Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?
Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.
Vider son esprit par rapport à construire les besoins de manière itérative
Dans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.
Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.
Cependant, là se trouvent les défis :
Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.
Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum
En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.
Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.
Ici, les défis sont :
Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.
Fin de développement par rapport à démonstration de sprint
Les démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.
Les défis de cette approche :
Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.
Les projets au temps passé et dépenses contre coût fixe
La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.
Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.
article précédent sur assistons-nous à la fin des contrats « classiques »?
Voici Pourquoi:
Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.
Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.
Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Itératif + Incrémental (Agile)
DantotsuPM.com 