Posté par jc-Qualitystreet le 7 mars 2010
L’adoption de l’agilité induit du changement, et le plus souvent un CHOC CULTUREL majeur pour les organisations qui auront tendance au départ à nier ou à minimiser son impact…
Il y a les Valeurs, les Principes et les PRATIQUES AGILES (scrum, xp …) listées ci-dessous

Les Valeurs se déclinent en Principes qui se concrétisent en Pratiques
Le discours des coach Agile sur le rapport Valeurs-Pratiques peut paraître ambivalent car au quotidien, nous travaillons beaucoup sur le mise en œuvre progressive et en contexte de ces pratiques Agiles. Au moment des bilans, c’est aussi celles-ci que nous examinons de prés…
Pourtant aucune ambigüité : les pratiques sont au service des valeurs qu’elles représentent. A chaque pratique sa valeur (les 4 de l’Agile Manifesto et les 5 XP) : à nous de ne pas perdre de vue ce lien et de revenir sans cesse au travers de notre coaching à ce socle commun de toutes les Méthodes Agiles.
Et au fait, quelles sont-elles ces pratiques dites Agiles ?
Voici ma petite liste des pratiques agiles. Evidemment sur un projet, et comme le dit fort justement Claude Aubry dans son livre de référence, ces pratiques agiles ne suffisent pas, et doivent être complétées de pratiques issues d’autres disciplines, en particulier Ergonomie / Expérience Utilisateur et Ingénierie des exigences, dont l’efficacité n’est plus à prouver ….
- Vision du produit
- Roadmap (Plan “high level” de plusieurs versions) & Release plan (Plan de la version en cours)
- Daily Scrum
- Demo de fin de sprint
- Planification de sprint
- Rétrospective
- Estimation collective (planning poker)
- Taskboard (et Kanban Board)
- Liste des obstacles
- Agile Risk Board (gestion agile des risques)
- Radiateur d’informations
- Sprints courts et « timeboxés »
- Backlog de produit
- Backlog de sprint
- Definition du Done
- BurnDown chart (base tâches en heures)
- BurnUp chart (base vélocité en points)
- ScrumMaster dédié
- Client / Product Owner sur site
- Equipe cross fonctionnelle
- Equipe colocalisée
- Standards de développement
- User Stories
- Programmation en binôme
- Conception simple
- Refactoring
- Propriété collective du code
- Intégration continue
- Livraison fréquente (d’une partie du produit)
- Tests Unitaires
- TDD (Développement piloté par les tests)
- TDR (Développement piloté par les exigences)
- Tests de recette (à chaque sprint)
- Automatisation des tests
Bon, ça reste ouvert …
Posté par jc-Qualitystreet le 19 février 2010
Le principe n’est pas neuf et nous vient des équipes Google qui l’expérimentent depuis quelques années : « agile projects in the wild ! » L’idée d’origine toute simple est de permettre à une personne de se porter volontaire pour travailler dans une équipe Agile afin de se faire une idée de la façon dont ça se passe, et de se familiariser avec les valeurs, principes et pratiques clés de l’agilité.
Le Safari Agile dans un chantier de transformation agile …
Dans un chantier de transformation agile (c’est à dire l’adoption des méthodes de développement agiles au sein d’une organisation) pour lequel les dimensions changement et apprentissage sont cruciales, l’idée prend tout son sens ; d’ailleurs dans ce type de missions, je propose à mes clients deux formules pour ces safaris :
- la formule petit déjeuner
- la formule club
LA FORMULE “PETIT DÉJEUNER”
Point Fort : « le lien Communautaire »
Cible : Les équipes Agiles
Buts : Transformation - Capitalisation - Apprentissage collectif
Une formule simple et efficace très adaptée aux organisations engagées dans quelques projets pilotes dans un contexte de transition (même si les autres s’y retrouveront aussi) et aux organisations multi site dont les plateaux sont à distance les uns des autres.
L’équipe, ScrumMaster et Product Owner du projet X rendent visite à l’équipe du projet Y, et échangent avec elle sur son environnement de travail. Deux bonnes heures, parfois un peu plus, tout d’abord pour faire connaissance (parfois) et surtout pour échanger dans la convivialité autour de quelques croissants et autres boissons chaudes, sur les pratiques de chacun.
Pas de programme évidemment mais un léger travail de facilitation et des Product Owner qui peuvent commencer par présenter la vision de leur projet avant de laisser la place aux discussions informelles sur les valeurs de l’agilité, les bénéfices observés et les façons de faire : ce qui marche, ce qui marche moins, ce qu’on veut essayer très prochainement ou les obstacles auxquels chacun doit faire face. Le radiateur d’informations et l’écran sur lequel peuvent se jouer des démos sont des passages obligés …devant lesquels se tiennent beaucoup de discussions.
Au sprint suivant, on inverse les rôles, et on rend l’invitation. L’équipe qui recevait se rend dans l’environnement de travail de la seconde équipe.
Encore une fois, pour une organisation qui démarre dans l’agilité, ce type de RDV est essentiel. En plus d’être un bon moment de détente, plutôt sympa, c’est un premier pas vers la capitalisation et la pose des premières pierres pour de futures communautés agiles transversales.
LA FORMULE “SAFARI CLUB”
Point Fort : « Implique-moi et je comprendrai »
Cible : Des personnes ne connaissant pas l’Agilité
Buts : Apprentissage individuel - Changement - Ancrage de l’Agilité
La formule “Club”, à savoir le safari agile grandeur nature, adresse des cibles et des objectifs différents. Elle vise plutôt les organisations déjà bien avancées dans leur transformation agile ou celles qui déroulent depuis un certain temps des projets Agiles, avec une certaine maturité et une certaine réussite. Les avantages de ce dispositif sont multiples :
- Faire monter rapidement en compétences des collaborateurs
- Partager en douceur les valeurs de l’agilité
- Semer les graines de l’agilité dans l’organisation
- Jouer la carte de l’ouverture et de la transparence
Le point de départ de cette formule de Safari Agile demeure toujours le volontariat : une personne émet le souhait de découvrir l’agilité, d’apprendre de nouvelles pratiques. Charge ensuite à l’organisation de lui trouver le bon projet, l’équipe qui va l’accueillir, pour une période déterminée (et plus si affinités …).
L’acte volontaire est un critère essentiel, gage du bon déroulement de l’opération. Avec « une personne motivée travaillant au sein d’une équipe motivée, et impliquée concrètement » … la suite est toujours positive à partir du moment où les objectifs sont clairs (niveau individuel, équipe et organisation) et que l’effort d’intégration est compté et anticipé sur le projet qui accueille.
L’apprentissage par la pratique … rien de tel pour progresser !
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” de Claude. 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 13 janvier 2010
Les valeurs Agiles sont des incontournables des introductions et formations à l‘Agilité, à juste titre, même si leur signification, leur impact et leur caractère ô combien essentiel ne sont pas immédiatement perçus …
Pourtant la transformation agile réussie d’une organisation me semble nécessiter un choc culturel représenté justement par l’adhésion aux 4 valeurs de l’Agile Manifesto …
Pourtant une équipe ne me semble Agile que quand elle performe sur les 5 valeurs Agiles (issues d’XP) !
Toutes ces valeurs, qui se recoupent ou se complètent, vous y reviendrez donc un jour ou l’autre, alors pour vous simplifier la vie, je vous propose de les redécouvrir dans cet article.
Evidemment vous pouvez vous positionner collectivement et régulièrement sur ces valeurs (l’« Agile radar » est un très bon exercice), vous pouvez les afficher, les discuter dans une rétrospective ou mettre le focus sur l’une d’entre elles après un Daily Scrum ou autour d’un café…
« Implique-moi et je comprendrai » (un élément clé du coaching agile) … Le plus important reste toutefois de les vivre au quotidien sur vos projets !
Alors faites du SCRUM, faites de l’XP ou du Lean mais surtout SOYEZ AGILE en toutes circonstances!
Les 4 valeurs de l’Agile Manifesto:
Les 5 valeurs Agiles (issues d’XP):
avec en italique, ce qu’elles représentent selon moi.
C’est d’abord se parler et savoir écouter
C’est privilégier le face à face au sein de l’équipe et avec le Client
C’est travailler ensemble, en équipe, du début à la fin du projet
C’est se dire les choses avec transparence, à tout moment
C’est se dire la vérité sur l’avancement du projet, sur les estimations produites
C’est s’engager individuellement et collectivement sur ce qu’on fait
C’est solliciter des retours le plus tôt et le plus souvent possible : du client ; de l’équipe ; du produit
C’est faire une demo plus formelle à chaque fin d’itération
C’est tenir compte de ces feedback et s’adapter en continu
C’est privilégier la solution la plus simple pour atteindre ses objectifs.
C’est favoriser des interfaces et interactions simples pour l’utilisateur
C’est juste ce qu’il faut de process, d’outils et de documentation
C’est fondamentalement respecter les personnes
C’est respecter les expertises et le travail de chacun.
C’est respecter les valeurs et le process agile
Comme on peut le constater, les 12 principes du Manifeste Agile ne sont de toute façon pas très loin : Valeurs- Principes - Pratiques …c’est un tout !