Posté par jc-Qualitystreet le 11 février 2010
On me demande souvent quels éléments placer sur le radiateur d’informations du projet, de l’équipe. Le Taskboard (voire le Kanban Board, c’est à la mode) est une réponse évidente mais pas suffisante…
Version détaillée
Version simple
Souvent négligée (et on pourrait se demander pourquoi …), la liste des obstacles est l’un de ces éléments clés, l’outil indispensable de notre dispositif agile, au service de l‘Equipe et du ScrumMaster.
COMMENT ? VOUS NE L’AFFICHEZ PAS ENCORE SUR VOTRE MUR !
Pourtant, la liste des obstacles est Essentielle pour l’EQUIPE
Rappelez-vous la 3ème question du Daily Scrum : « qu’est ce qui t’empêche de faire ton travail ? », la liste des obstacles rend visible les éventuels blocages émis par les membres de l’équipe.
Le dire c’est bien, traiter le problème c’est mieux ! Et sentir qu’on s’occupe de lever ces obstacles, ça fait du bien.
Voilà quelques bienfaits du management visuel.
Pourtant la liste des obstacles est Essentielle pour le ScrumMaster (« chef de projet Agile »)
Garant du Process Scrum, facilitateur et protecteur de l’équipe, le rôle du ScrumMaster est justement de dégager les obstacles qui surgissent et entravent le travail de l’équipe. Son But : faire en sorte que la liste des obstacles redevienne vierge. Dans ce sens, elle est un très bel outil d’information et communication ; et surtout la preuve que le ScrumMaster (en particulier) et l’Equipe se battent pour le projet.
Au final la liste des obstacles est indissociable des valeurs agiles
Communication, Courage, Feedback, Simplicité : afficher la liste des obstacles, c’est un peu tout ça, c’est avoir l’esprit Agile. Et jouer la transparence, la rendre visible en permanence, la revisiter au quotidien n’est pas anodin !
Posté par jc-Qualitystreet le 6 février 2010
Et le premier ouvrage en français dédié à Scrum. Je fais donc partie de ces privilégiés qui ont eu le plaisir de dévorer en avant première le livre SCRUM : Le guide pratique de la méthode agile la plus populaire
Je n’ai pas été déçu, et je suis prêt à parier que vous ne le serez pas non plus, que vous débutiez dans l’agilité ou que vous soyez un praticien Scrum expérimenté.
L’ouvrage est très complet et se lit très facilement, en douceur, … le style est clair, simple, le discours bien rôdé. Car de mon côté, j’avais pas mal d’attentes sur ce livre SCRUM…
Des exigences obligatoires … LARGEMENT SATISFAITES
Claude revient évidemment sur les fondements de l’Agilité puis détaille l’ensemble du process Scrum : des 3 rôles (ScrumMaster, product Owner, Equipe) aux principaux artefacts (backlog de produit…), des cérémoniaux SCRUM (daily Scrum, Retrospective…) aux activités de planification et d’estimation agiles. De la justesse, de la pédagogie, de l’expérience : c’est parfait.
Des attentes exprimées … CONFIRMEES
L’adoption de Scrum en contexte, la transition agile, la gestion de projet Agile outillée avec IceScrum voire même Scrum en France sont des sujets attendus que Claude aborde régulièrement en conférences. L’auteur les développe avec brio, et nous fournit un contenu de qualité.
Les heureuses Surprises … BIEN REELLES
La signification du fini (Definition of Done), de la Vision aux User stories ou encore les tests d’acceptation sont des sujets qui me tiennent à cœur, et les vraies problématiques des équipes Agiles qui veulent avancer. Claude donne une place de choix à ces questions dans son livre, et nous apporte sa vision pleine de pertinence et d’ouverture. Personnellement, je vous conseille donc vivement ces chapitres 11, 13 et 14.
Conclusion :
Ais-je encore besoin de vous inviter à vous le procurer de toute urgence ? (Sortie le 10 février)
Note : Ces 3 types d’exigences, on les retrouve dans le modèle de Kano….
Posté par jc-Qualitystreet le 5 février 2010
Les coachs Agiles apprécient les acronymes … c’est vrai qu’ils permettent de faire passer simplement quelques messages clés auprès des équipes.
Alors vous m’entendrez souvent au cours de mes missions de coaching insister sur :
Le backlog de produit, c’est en résumé la liste des exigences du produit ou plus exactement la liste de tous les éléments sources de valeur qui vont nécessiter du travail de l’équipe pour réaliser le produit. On y trouve donc essentiellement des User Stories mais aussi des élément plus techniques voire des défauts détéctés .
Le backlog de produit est un des 3 artefacts SCRUM, sous la responsabilité du Product Owner, c’est l’élément central de tout notre dispositif agile. Il se construit (se priorise et s’estime collectivement) en général dans le Sprint 0.
Alors, qu’est ce qui caractérise notre backlog de produit ? Il est DEEP tout simplement :
- D = Détaillé de manière appropriée (le backlog contient des éléments au bon niveau de granularité : suffisamment petits, détaillés et compréhensibles pour ceux devant être réalisés dans les sprints qui arrivent)
- E = Estimé (chaque élément du backlog est estimé de manière relative, les uns par rapport aux autres; une estimation menée collectivement par l’équipe: c’est le Planning Poker)
- E = Evolutif (le backlog n’est pas figé; il émerge dans le sprint 0 mais change au fur et à mesure de l’avancement du projet: ajout, retrait, changement de priorités)
- P= Priorisé (les éléments du backlog sont priorisés: du plus important au moins important; rappelez-vous l’objectif est de livrer le plus de valeur (top priorité) le plus tôt possible)
Simple, non ?
Posté par jc-Qualitystreet le 13 novembre 2009
Noel approche et les enfants le savent, du coup voilà à quoi j’ai eu droit le weekend dernier…
Mes enfants : « Papa … papa … pour Noel on fait le jeu des post it »
Moi : « D’accord les enfants mais cette fois on va faire un petit peu différemment … »
Car depuis ce billet « Des priorités pour le Père Noel », j’ai bien évidemment eu le temps d’améliorer le process 
, même si côté contraintes, c’est toujours plus ou moins la même chose :
- Le temps du Père Noel est compté
- Son traineau n’est pas extensible
- Les délais sont serrés
- La date de livraison ne peut pas bouger
- Le Père Noel a un grand nombre d’enfants à satisfaire
En outre, mes enfants, en bons Product Owner qu’ils sont, ont compris qu’ils ne pouvaient pas tout avoir (même s’ils en veulent toujours plus), et que le fait d’avoir été sage (ou non) pouvait « potentiellement » avoir un impact sur ce qu’ils allaient recevoir… d’où la nécessité pour eux de fixer des priorités !
SCRUM / XP depuis… la maison !
Ou comment nous fixons des priorités pour la lettre au Père Noel
Temps 1 (Optimisé) : Brainstorming et collecte des données
Lecture passionnée depuis quelques semaines, et recherche intensive dans plusieurs sources, interview du petit frère et découpage des cadeaux potentiels.
Temps 2 : Initialisation du (ou des) Backlog(s)
Les images sont découpées : une enveloppe pour chaque enfant. Je colle chaque image cadeau sur 1 post it. 1 cadeau par Post it.
Le backlog est alors initié.
Temps 3 : Priorisation du (ou des) Backlog(s)
Les post it sont posés sur le sol. J’ai demandé à mes enfants de les classer par ordre de préférence « à la file indienne » : en haut, ceux dont ils ont le plus envie, les plus importants pour eux …
…..
….
Temps 4 : Affichage du (ou des) Backlog(s)
Les post it sont priorisés sur le sol. Il nous restait à trouver un petit coin de mur ou de porte pour les mettre à la verticale (management visuel…). Un peu de patafix et le tour est joué.
Pour la grande (pas trés raisonnable):
Pour le petit frère (beaucoup plus raisonnable …):
BILAN: On a passé un bon moment et les enfants sont contents
Ma femme et moi nous chargeons de l’estimation en points-euros :)
Posté par jc-Qualitystreet le 24 septembre 2009
Mais pas seulement…
Entre 1994 et 2009, le taux de réussite des projets IT est passé de 16% à 32 % (selon les dernières statistiques, et le dernier Chaos report).
Ok c’est mieux, mais toujours et vraiment pas terrible…
Petit retour en arrière, en 2006, le Standish Group revenait sur ces projets qui marchent en analysant les facteurs de réussite. Pour la première fois, l’agilité était citée … d’ailleurs Jim Johnson (Standish Group) en faisait l’éloge dans une interview sur InfoQ
TOP 5 des Facteurs de Succès (2006)
- IMPLICATION DES UTILISATEURS FINAUX
- Soutien de la direction
- Objectifs Business clairs
- Périmètre de projet optimal
- PROCESS AGILE
Chaque élément est important, et je suis ravi (comme tant d’autres qui prêchent pour leur paroisse…) de retrouver aussi bien placés dans la liste des éléments qui me tiennent à cœur. Mais la richesse d’un projet IT, et surtout les clés de sa réussite résident avant tout dans la juste association, l’habile combinaison, des bonnes pratiques et des méthodes. Combiner pour voir les choses différemment, combiner pour faire la différence et donner plus de valeur, combiner pour déclencher l’étincelle… et FAIRE QUE CELA MARCHE VRAIMENT.
Ma conviction est simple :
un cadre Scrum + le Lean Thinking et ses outils + des pratiques XP (toujours extrêmes en 2009 ? ) + l’Experience Utilisateur en fil rouge + une stratégie de Testing appropriée (Agile testing quadrants de Brian Marick) … Le TOUT EN CONTEXTE, AVEC DES EQUIPES MOTIVEES
= SUCCES !
