Vers Scrum/Kanban/Scrumban et au delà !
Ah les fameux frameworks agile, ils sont partout ! Tout le monde les pratique et les utilise à tort et à travers ! Et non, comme le dit si bien mon collègue Johan, “Agile is (not) dead”…
Mais finalement, vous savez me dire pourquoi vous utilisez Scrum plutôt que Kanban ?
Et peut être que vous ne savez même pas que vous pratiquez un Scrumbut mais pas un “vrai” Scrum ^^… C’est même possible que le framework que vous utilisez ne soit pas celui qui vous va le mieux… pour votre entreprise ou votre projet d’ailleurs.
Bon allez, trêves de bavardages, faisons le point sur tous ces frameworks !
Un retour aux sources
Le manifeste agile rédigé en 2001 (ça nous rajeunit pas ^^) met en avant 4 grandes valeurs pour améliorer le développement de logiciel (à la base de la base :P).
Valorisons :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
http://agilemanifesto.org/iso/fr/manifesto.html
« Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. »
En effet, dès les années 90, la gestion de projet classique et son merveilleux effet tunnel avait déjà commencé à montrer ses limites, les projets informatiques devenant de plus en plus complexes, les méthodes devaient s’assouplir et évoluer.
Un mindset avant tout
L’agilité repose donc sur un état d’esprit découlant des 4 valeurs décrites ci dessus mais aussi des 12 principes du manifeste :
- Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
- Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
- Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
- Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
- La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
- Un logiciel opérationnel est la principale mesure d’avancement.
- Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
- Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.
- La simplicité, c’est-à-dire l’art de minimiser la quantité de travail inutile, est essentielle.
- Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
- À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
Une philosophie plutôt qu’une pratique : l’agilité exige donc des organisations qu’elles améliorent leur manière d’être efficace.
Petit aparté “Maturité” : Deux indicateurs utiles pour attester de la maturité d’une organisation (mais on sort un peu du cadre de l’article ^^) :
- L’efficacité, mesure la capacité d’une organisation à atteindre ses objectifs, peu importe le coût
- L’efficience, mesure l’amélioration de l’efficacité
Pour ma part, l’agilité est l’application des accords toltèques et du bushido tout en gardant en tête les lois de la productivité ! C’est donc un peu une religion appliquée à l’entreprise…
Pour en savoir plus sur le Mindset Agile, n’hésitez pas à lire le livre “Adoptez le mindset agile” de HaIm Mamou, coach agile chez SOAT, très complet ! http://www.asprom.com/application/SOAT.pdf
La pyramide agile
Puisqu’un schéma vaut mille mot, voilà comment positionner nos fameux frameworks et méthodes qui nous intéressent aujourd’hui !
Cette pyramide permet de rappeler que pour réussir votre transformation agile, il faut tout d’abord passer par la compréhension du mindset agile…
Ensuite, les valeurs puis les principes permettront aux équipes de bien intégrer les plus values de chaque framework (ou même, pour les équipes matures, de créer le leur… :) )
Enfin, les équipes pourront choisir les pratiques qui viendront alimenter le framework ou la méthode choisie.
Ce sont des étapes d’acculturation agile très importantes pour les équipes :
- les fondements
- les intérêts
- les méthodes
Les frameworks agile
Nous allons ici en détailler 3 différents, qui sont les plus utilisés actuellement. D’autres frameworks et méthodes existent, par exemple, SAFe, XP ou Less…
Etant Bewizyienne et agile, je ne vous ferais pas l’affront de faire avantages/inconvénients car le but n’est pas de trouver la “meilleure” méthode ! En effet, il n’y a pas de “meilleure” méthode, mais il y a celle qui convient à votre contexte ! Je vous propose de faire un tour d’horizon afin d’avoir bien en tête les définitions, les mots clés et pourquoi choisir tel ou tel framework.
SCRUM
Définition : Scrum(n) : Un cadre de travail (framework) au sein duquel les acteurs peuvent aborder des problèmes complexes et adaptatifs, en livrant de manière efficace et créative des produits de la plus grande valeur possible.
Source : Le guide du scrum
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf
En bref :
- Scrum est un framework agile pour le développement, la livraison et la maintenance de produits complexes.
- 3 piliers : Transparence, Inspection, Adaptation
- 5 valeurs : Engagement, Courage, Focus, Ouverture et Respect
- 3 rôles clés (scrum master, product owner, équipe de développement)
- 5 événements itératifs :
Le Sprint
Planification du Sprint (Sprint Planning)
Mêlée Quotidienne (Daily Scrum)
Revue de sprint (Sprint Review)
Rétrospective de Sprint (Sprint Retrospective)
- 3 artefacts classiques et 1 artefact de transparence :
Product backlog
Sprint backlog
Increment
Definition of done (artefact de transparence)
Pour finir : On dit souvent que Scrum est facile à comprendre (la dernière version du Scrum Guide fait 20 pages..) mais est difficile à mettre en oeuvre. Ce framework est idéal pour effectuer une “vraie” transformation agile, Scrum donne toutes les clés pour y arriver !
KANBAN
Définition : Kanban : Une méthodologie se basant sur l’approche Lean, permettant d’établir des flux opérationnels constants et ordonnés. Il est souvent associé à d’autres méthodes agiles, comme le SCRUM.
Source : Digital Guide par IONOS
https://www.ionos.fr/digitalguide/sites-internet/developpement-web/kanban/
En bref :
- Kanban est une méthodologie permettant d’augmenter sa productivité et la qualité du produit fini.
- Approche : Les tâches sont divisées en petites étapes à traiter les unes à la suite des autres. Le processus complet de l’analyse des tâches jusqu’à leur livraison au client est consultable par tous les participants, chacun prenant ses tâches depuis une file d’attente.
- Un slogan appliqué à Kanban : “Stop starting, start finishing !”
- 4 principes de base :
Commencer par ce que vous faites actuellement
Accepter d’appliquer les changements évolutifs et augmentés
Respecter le processus actuel, les rôles, les responsabilités et les titres
Leadership à tous les niveaux
- 5 pratiques centrales :
Visualiser
Limiter le nombre de tâches en cours
Gestion du flux
Rendre les normes de processus explicites
Utiliser des modèles pour reconnaître les opportunités d’amélioration
- Le tableau Kanban : Méthode visuelle avant tout, un tableau à trois colonnes permet de suivre l’achèvement des tâches
- 3 colonnes minimum :
Backlog : Tâches restants à effectuer
Work In Progress (En cours) : Tâches en cours de réalisation
Done (Terminé) : Tâches finalisées
- Hiérarchie des tâches : Une ligne horizontale traversant les trois colonnes est souvent créée en haut du tableau pour prioriser les tâches.
Pour finir : Simple d’utilisation, il peut être transposé à n’importe quel domaine. Sa mise en oeuvre étant elle aussi très simple, on comprend son succès et son appropriation. Kanban est la méthode idéale pour retrouver une organisation claire et surtout être très réactif !
SCRUMBAN
Définition : ScrumBan : Méthodologie de gestion de projets Agile basée à la fois sur les approches Scrum et Kanban.
Source : SKRIV
https://www.skriv.com/fr/blog/methode-scrumban
En bref :
- Origine : Scrumban est une méthodologie initialement conçue comme un moyen de passer de Scrum à Kanban.
- Approche : Scrumban est une hybridation entre Kanban et Scrum. L’ensemble des pratiques Kanban sont appliquées, en distillant quelques pratiques Scrum, telles que les rituels, les artefacts et les rôles. (On parle plutôt d’un Scrumbut, mais cela fera l’objet d’un autre article.)
- Pratiques :
Pas d’estimations, on compte uniquement les stories
Pas de sprint, on fonctionne en flux
Le flux représente précisément les activités nécessaires pour réaliser les stories
Pas de tâches, les stories suffisent
La planification se fait à la demande
Pour finir : Scrumban est donc un bon compromis entre Scrum et Kanban, de Scrum on conserve le rythme et les rôles clés et de Kanban, la méthode de gestion de flux tendus. Le support ou l’agilité à l’échelle sont confrontés à des contextes particulièrement adaptés à cette pratique.
Conduite du changement
Une logique de “transformation agile”, cela revient souvent pour des équipes projet à se tourner vers un framework. Un des plus connus si possible afin de se donner les meilleures chances d’y arriver ou tout simplement car tout le monde le fait. C’est sécurisant et facile. On ne prend que le mot “agile” de la “transformation agile” en somme.
Prenons un peu de recul, comme je le disais au début de cet article, la première phrase du manifeste agile est “Les individus et leurs interactions plus que les processus et les outils”.
Commencer par le choix d’un framework serait-il donc “anti-agile” ?
Je reformule : utiliser le bon framework ne fait pas de vous quelqu’un d’agile. La clé est la remise en question perpétuelle, en tant qu’individu mais aussi en tant qu’équipe.
Sortons un peu du contexte agile, nous serons tous d’accord pour dire que la remise en question doit être consentie et motivée pour qu’elle soit utile ! Mieux que cela, pour qu’un individu se remette en question de manière instinctive et que cela produise un changement profond, un immense travail sur soi doit s’opérer. Un part de psychologie doit être prise en compte. L’agilité n’est pas une fin en soi.
La question ultime est “Comment faire pour que mes collaborateurs, en tant qu’individu mais aussi en tant qu’équipe soient moteur de cette transformation ?”
Afin de réussir sa transformation agile, il faut tenir une réelle conduite du changement dans votre organisation, co-construite et non subie. La préoccupation humaine doit être au coeur du changement vers l’agilité.
Faites un tour du côté de l’Open Space Agility si ce sujet vous intéresse ou mieux : faites confiance à Bewizyu !
Au delà du projet ou du produit, nous vous accompagnons dans cette transformation agile pour vous aider à trouver la solution sur-mesure adaptée à votre contexte .
