Le 31 mars dernier s’est tenu le scrum day 2011, organisé par le French Scrum User Group. Plus de 25 sessions étaient programmées, il a donc fallu, pour les près de 500 personnes annoncées, faire des choix. Le titre de cet article est inspiré des conférences auxquelles j’ai assistées, où ce qui ressort est l’importance de l’humain dans la gestion des projets. Car si dans chaque session, le cadre Agile a été rappelé, l’accent a finalement été porté sur la ressource première : les collaborateurs. Au-delà des outils utilisés, ou non utilisés, comme pour Harvey Wheaton, qui nous a présenté son retour d’expérience sur l’intégration de l’agilité dans le monde du développement de jeux vidéo, et pour qui rien ne vaut l’affichage sur le mur, même pour le backlog (uniquement photographié, pas même mis sous Excel) : Rien ne sera efficacement réalisé sans une vraie adhésion des intervenants. Comme le rappelle Véronique messager (conférence « ScrumMasters, devenez le coach agile de votre équipe ») : « Les personnes font le succès du projet ». Sa session était orientée plus sur l’aspect psychologique que méthodologique de l’agile : recentrer le rôle du ScrumMaster sur son coté de faciliteur et de protection, devenant la personne qui permet à l’équipe et à chacun de ses membres de s’élever et à prendre confiance en ses capacités. « Confiance », voilà un autre des mots clés de la journée : confiance des membres de l’équipe entre eux, et vis-à-vis du ScrumMaster ; confiance du Product Owner vis-à-vis de l’équipe de réalisation, Confiance du client… Autant d’éléments primordiaux pour être en situation de réussite. Ainsi, lors de son retour d’expérience sur la mise en place d’un proxy PO, Bertrand Dour (conférence « Le product Owner « proxy » . Mise en place de l’agilité dans un environnement à forte culture « cycle en V ») nous expose les difficultés rencontrées quand cette confiance manque à un ou plusieurs niveaux. Dans le cas exposé, le sponsor pour la mise en place de l’agilité était très faible, le métier peut disponible et divisé en plusieurs entités « concurrentes ». La place du PO dans ce contexte n’a pas semblé aisée et, malgré les premiers résultats positifs et un bilan qui l’est tout autant, le climat n’est pas encore optimal pour un « mode agile » tel que décrit dans l’idéal par les intervenants de la journée. Ceci étant surement très liés aux habitudes ancrées de travail en cycle V. Dans tout domaine il est difficile d’admettre que ce que l’on a appris et appliqué depuis longtemps n’est peut-être pas la meilleure façon de faire. Là encore, on frôle des domaines bien éloigné de ce que l’on étudie dans les parcours « informatique ». Dans sa conférence intitulée « Quarante ans de crise, dix ans d’agilité », Laurent Bossavit, de[ l’Institut Agile|http://institut-agile.fr/], nous met face à ces paradoxes : aucune formation Agile existante actuellement, des jeunes diplômés qui doivent « désapprendre pour réapprendre » … Il présente l’Agile comme une évolution de « rupture ». C’est-à-dire comme un produit de niche, se développant à un moment où il n’est considéré comme adéquat par le public, et qui d’évolution en évolution fini par détrôner l’ancien produit phare, en entrainant sa chute (l’exposé est basé sur la comparaison avec le développement des appareils photos numérique, et la « mort » des appareils classiques). Ceci rend l’adhésion plus difficile encore… Et malgré ces discours « humanistes » il est peu probable, que dans des contextes commerciaux demandant toujours plus de rapidité, l’ensemble des conseils de la journée puissent être appliqués et suivi… A chacun d’y piocher ce qu’il peut pour avancer dans ce sens !
Tag - ScrumDay
vendredi 8 avril 2011
ScrumDay : tirer le meilleur de Scrum et Kanban => Scrumban ?
Par Anne Sophie le vendredi 8 avril 2011, 14:53
Pour entamer ma journée au ScrumDay, et parce que je n'avais pas encore pu
assouvir ma curiosité sur les principes Kanban, je me suis rendue à la
conférence Scrum et Kanban, tirer le meilleur des deux, animée par
Antoine Vernois, le renommé Claude Aubry et Fabrice Aimetti. Présentation
plutôt interactive avec passage de témoin entre les 3 animateurs, mais qui a
parfois manqué de peps. ROTI 3/5.
Le pitch : Scrum est la méthode agile la plus populaire. La
transition à Scrum représente souvent un changement radical pour certaines
organisations. Venant directement du Lean, le Kanban appliqué au développement
de logiciel s’affirme comme une pratique alternative intéressante, en
particulier pour les activités de support. La présentation, faite par les
traducteurs du minilivre de Kniberg et Skarin, montre comment tirer le meilleur
de Scrum et Kanban, selon le contexte.
Scrum et Kanban sont toutes les deux des méthodes Agiles, basées sur l'empirisme (mode itératif), Scrum étant plus cadré, Kanban plus ajustable. Chaque itération se décompose ainsi :
- Planifier (au plus près du début de Faire car il est facile d'estimer ce qui peut être fait dans la période immédiatement à venir),
- Faire (en projet informatique, Scrum s'adosse souvent à XP - eXtreme Programming)
- Livrer (avec revue de sprint),
- Améliorer le processus (Kaizen, Inspection et Adaptation : feedback et rétrospective)
...et reprendre au début.
Les différences majeures entre les deux méthodes sont :
- d'abord la fréquence différente des actions listées
ci-dessus :
quand Scrum impose un enchainement de l'ensemble de ces tâches, Kanban
permettra de planifier chaque action à des fréquences différentes (et qui
resteraient logiques, ex : livrer chaque semaine, planifier tous les 15
jours, rétrospective tous les mois)
- ensuite la gestion du périmètre du sprint :
Scrum aurait tendance à vouloir se conformer au périmètre initial du
planning, tandis que Kanban permettrait le remplacement d'une tâche par une
autre (si équivalente en terme de complexité et si non entamée) en cours
d'itération et selon la priorisation
- - puis la gestion du taskboard :
réinitialisé à chaque itération Scrum via le planning game, il est en Kanban
plus simplement conservé et alimenté au fil de l'eau. Cependant, pour conserver
un volume "à faire" stable par itération, en Kanban, des règles de limitation
de l'en-cours sont mises en place pour que le stock de chaque état d'en-cours
soit fluide et ne risque pas de devenir un point de blocage. On en profite pour
rappeler que les tâches doivent traitées intégralement (état "done").
La gestion des perturbations :
Nos 3 animateurs conseillent Scrum pour une équipe projet qui est ainsi,en
cours d'itération, à l'abri de toute perturbation extérieure (impactant la
prochaine itération), tout en recommandant plutot Kanban pour les équipes de
support ou opérationnelles : la gestion des perturbations est prévue
(impact immédiat).
Dans le cas d'une équipe gérant plusieurs projets, le taskboard est unifié. Des
codes couleur ou des couloirs peuvent être mis en place, et les sprints
successifs seront :
- en Scrum, composés de tâches d'un seul projet, pour éviter les perturbations liées au switch de projet/de produit
- en Kanban, composés à l'envi, mais de façon équilibrée, de tâches d'un seul
ou de plusieurs projets selon les priorités.
Le parallèle entre ces deux méthodes finit par nous mener à la conclusion
logique : il faut adopter la méthode choisie à la réalité du
projet.
Antoine Vernois, Claude Aubry et Fabrice Aimetti concluent par ces quelques assertions :
Soyez agiles pour la mise en oeuvre du projet
Essayez les choses par vous même
Ne soyez pas trop dogmatiques
Soyez et restez Agiles