Posté par jc-Qualitystreet le 26 juin 2010
Certes mais est-ce suffisant ?
Définitivement NON !
Une fois, toutes les 3 semaines, le dernier jour du sprint, pour vous c’est peut être mieux qu’avant, mais c’est loin d’être suffisant.
Car le feedback c’est le cœur de l’Agilité, l’élément clé du dispositif Agile, celui qui évidemment va assurer l’avancement du projet mais aussi celui qui permet de toujours faire mieux notamment au travers de l’amélioration continue (« Plan-Do-Check-Act » / « Inspect & Adapt »).
Quel est le problème ?
La principale difficulté réside dans le fait que le FEEDBACK (à recevoir / à donner) n’est ni quelque chose de naturel, ni une habitude ancrée dans notre façon de travailler.
Loin de le rechercher, beaucoup d’équipes ont donc tendance à le fuir ou à le retarder, tout en rationalisant tant bien que mal une conduite de moins en moins justifiable …
- « Ça va nous ralentir »
- « S’il donne son feedback, on en finira jamais »
- « De toute façon il ne sera jamais content »
- « Il va rajouter des choses »
- « Dans le Sprint? on a pas le temps »
- « L’itératif ça marche comme ça…on se voit à la fin et les modifs c’est pour le sprint suivant »
- « Mais alors à quoi ça servirait de faire une demo? »
- …
Le feedback est déterminant et multiple
La qualité du Feedback est selon moi un indicateur majeur du caractère agile d’une équipe, signe d’une performance maîtrisée.
- Sans Feedback, ça ne marche pas…
- Plus vous intégrez tôt le feedback, mieux c’est…
- Plus le feedback est rapide, mieux c’est…
L’absence de feedback constitue donc une entrave à la performance de l’équipe qui nuit gravement à la dynamique collective ainsi qu’à la fluidité du « process » agile.
Son impact sur la qualité du produit est évident, à court ou moyen terme.
Maintenant, être prêt à recevoir (POSITIVEMENT) le feedback, et inversement, donner du feedback (DE MANIERE CONSTRUCTIVE), c’est un changement culturel majeur pour les Hommes et les organisations.
Plus qu’une question d’apprentissage, c’est d’abord une affaire de volonté et d’état d’esprit qui nécessite de s’appuyer sur trois ingrédients essentiels à cultiver sans modération :
- le courage,
- le respect
- la confiance.
Et Pour l’équipe Agile ?
- C’est solliciter des retours du Client (ou Product Owner) le plus tôt et le plus souvent possible, TOUT AU LONG DU SPRINT
- C’est multiplier les rencontres avec les utilisateurs finaux, dans une approche Guerilla Usability ou RITE
- C’est se donner en permanence du feedback dans l’équipe (Daily Scrum, workshops, Pair programming, Tests…)
- C’est recueillir en continu le feedback du produit (TDD, Intégration continue, Tests fonctionnels automatisés ou non : cela sert à ça !)
- C’est faire une demo plus formelle à chaque fin de sprint
- C’est finalement tenir compte de ces feedback et s’adapter en continu dans un esprit” kaizen”
Mon Challenge de coach Agile :
- Mettre la question du feedback au cœur des préoccupations de l’équipe et les amener à travailler ensemble sur cet axe
- Remettre les valeurs & Principes agiles sur le devant de la scène et cultiver des valeurs humaines fondamentales telles que le respect, le courage et la confiance
- Insister au niveau de l’organisation sur les vertus de la colocalisation (Product Owner / Equipe) et inciter le Product Owner à assister le plus souvent possible aux Daily Scrum
- Inciter l’équipe à « TERMINER » les choses et à les montrer en sollicitant aussitôt le Product Owner (client)
- Inciter le Product Owner (Client) à aller voir, à initier la conversation, à faire le premier pas sans attendre la demo de fin de sprint …
- Convaincre de l’intérêt de rencontrer les utilisateurs finaux
- Impliquer les acteurs et faciliter directement le feedback au travers de RDV collaboratifs
La conclusion me vient directement d’une équipe qui travaille dans un mode agile depuis quelques mois et de ses réponses plutôt éloquentes à cette question de retrospective « Qu’est ce qu’on a fait de bien sur ce sprint ? »:
1. « Les workshops techniques »
2. « Les workshops Business »
3. « Le maquettage (Balsamiq)
Chez eux, le feedback progresse ….
Mes autres Alertes:
Posté par jc-Qualitystreet le 18 juin 2010
Une vraie question, n’est-ce pas ?
Et surtout, un exercice que j’apprécie tout particulièrement, et que je propose souvent en Rétrospective dans mes activités de coaching Agile. Il permet d’ouvrir les débats, d’identifier quelques dysfonctionnements, ou de confirmer que ça va bien, et plus globalement de prendre la température de l’équipe.
Mesure de la satisfaction de l'équipe sur sa façon de travailler ensemble
On est évidemment sur du ressenti mais la technique est très intéressante puisqu’elle nous permet d’aborder les questions collaboration , communication, feedback tout en ne nécessitant que peu de temps dans sa préparation et dans sa réalisation.
Cette mesure de la satisfaction de l’équipe sur sa façon de travailler ensemble nous donne un précieux indicateur d’équipe, trés simple, qu’on peut suivre sur quelques sprints dans un souci d’amélioration … Toutefois, pour varier les plaisirs, je l’abandonne généralement au bout de 3 ou 4 sprints…
Voila comment je procède :
- Je présente l’exercice et son objectif à l’équipe
- J’explique l’échelle (de 1 à 5)
- Je distribue des post It vierges
- Chaque membre de l’équipe (au sens large, inclus PO et SCM) indique ANONYMEMENT sa note sur le post it
- Je ramasse les post it
- Je dépouille et construis l’histogramme de satisfaction durant l’exercice suivant (par exemple la Timeline)
- J’affiche l’histogramme au mur et on en discute … FEEDBACK IMMEDIAT !
La description des valeurs 5 et 4 sur l'échelle de satisfaction
Note : Une bonne variante de l’étape 4 et 5 consiste à le faire de manière transparente avec un vote à 5 doigts. Tous ensemble et en même temps. On enchaîne alors avec les pourquoi ou on laisse la discussion s’installer…
Sa simplicité fait son efficacité : amis ScrumMaster, amis Coach, n’hésitez-pas à essayer cette petite mesure !
Les autres Trucs de Coach Agile:
Posté par jc-Qualitystreet le 15 juin 2010
Voici l’une des deux présentations que j’ai données à Agile France 2010.
La thématique de celle-ci: Agile UX sous l’angle Personas
Personas : Une dose d’expérience Utilisateur dans vos projets Agiles
Avec à la clé un très bon ROTI 
Posté par jc-Qualitystreet le 14 juin 2010
L’agilité nécessite d’envisager les projets différents. Une des premières différences réside dans le travail d’estimation à réaliser. En effet, l’équipe est amenée très vite à estimer le « Backlog de produit » (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 le réaliser).
Ce travail d’estimation est un préalable à l’effort de planification qui l’accompagne, il est indispensable pour savoir où l’on va. Il va consister à estimer un « Backlog de produit » en « Points » (en quoi ?????) et à le faire de manière collective avec un Planning Poker (un quoi ????).
Ce nouveau mode d’estimation n’est au départ pas naturel : il va s’agir d’estimer la complexité de tous les items du backlog de manière relative, les uns par rapport aux autres (2x Plus ; 3x Plus ; Un peu moins ; La moitié ; 5 fois Moins ; 8xplus …).
Pour cela on utilise des cartes de planning poker (un jeu un peu spécial fondé en partie sur la suite de Fibonacci) , et l’équipe vote ensemble pour estimer chaque élément, sur 1, 2 ou 3 tours en recherchant le consensus ; pas forcément plus naturel mais au moins qui présente un côté ludique !
Jeu de planning Poker
Je ne reviendrai pas ici sur le déroulement d’une session… (peut être un prochain “truc de coach”). Le choix d’un étalon (une User Story de référence), la triangulation et surtout L‘INTELLIGENCE COLLECTIVE sont les piliers de cette technique dont les bénéfices sont certains…
Le problème : Les équipes perdent souvent le fil de leurs estimations, éprouvent des difficultés à comparer, manquent de repères. D’autant que cette activité peut prendre du temps …
La réponse du Coach : L’affichage visuel en colonnes (1 colonne par Valeur), et le placement sous chaque valeur des stories qui correspondent à celle-ci !
Affichage Visuel durant l'estimation
Les Avantages :
- C’est visuel
- Cela facilite la comparaison et renforce le concept de «complexité relative»
- Cela facilite la triangulation
- Cela renforce l’idée que rien n’est pas figé durant ce travail: changer le post it de place est facile!
ATTENTION : Garder sur le post it ou ailleurs la priorisation métier (car votre belle liste ordonnée vole en éclats)
Les autres Trucs de Coach Agile:
Posté par jc-Qualitystreet le 4 juin 2010
Le marketing agile, c’est d’abord la réalisation en mode agile de projets IT pour le marketing, des projets qui ne peuvent aujourd’hui réussir et s’épanouir que dans des cycles courts, ponctués de livraisons fréquentes, dirigés par le FEEDBACK, ouverts au CHANGEMENT.
Car, comme le soulignait récemment Lubomira Rochet (Valtech), l’enjeu du marketing digital est bien « de proposer le bon produit à la bonne personne dans le bon contexte au bon moment », dans un monde où tout s’accélère.
Pour cela, l’art du marketing aujourd’hui c’est avant tout de Livrer Tôt, Tester, Tester encore, Retester, Mesurer en permanence et S’adapter en continu. Un ensemble d’activités qui n’est pas sans rappeler les cycles d’amélioration continue, pilier du Lean thinking, et au final des problématiques auxquelles seule l’AGILITE peut répondre efficacement.
Et cette réponse de l’agilité n’est pas sans impact …
Des BIENFAITS incontestables pour le Marketing et le Business en général…
- Aligner l’IT et le Business sur une même Vision
- Livrer tôt
Voilà les atouts majeurs du marketing Agile, mais pas seulement :
- Une plus grande capacité d’influence sur l’avancement du projet, notamment pour changer les priorités, mieux gérer les besoins qui émergent et s’adapter à un environnement qui change (le backlog de produit évolutif et prioriés devient l’élément central du dispositif)
- Une plus grande visibilité sur le projet au travers du management visuel, des larges radiateurs d’information, des indicateurs simples et des RDV de fin de sprint
- L’accélération des délais de livraison, de mise en marché au travers d’un seul objectif: LE PLUS DE VALEUR AU PLUS TOT
- Une meilleure adaptation aux besoins grâce à une multiplication des opportunités de feedback, des interactions plus tôt et plus fréquentes, des démos et livraisons régulières qui répondent à ces nouvelles exigences (Test - Mesure - Adaptation)
Des devoirs et une nouvelle façon de travailler ENSEMBLE …
- Décloisonner, rassembler tout le monde, IT et Marketing
- Rechercher une collaboration efficace (montrer, expliquer … en face à face) TOUT AU LONG DU PROJET (on ne s’éclipse plus après les MRD)
- Faire émerger un nouveau rôle, côté Marketing : le Product Owner
- Responsabiliser les équipes
- Découper les projets en des sprints de courte durée (1 semaine, 2 ou 3 semaines…)
- Livrer le plus souvent des versions opérationnelles: Test, Test, Test… Inspect and Adapt!
- Faire juste ce qu’il faut de formalisme et traquer les gaspillages à tous les niveaux
La nécessaire adaptation à une nouvelle CADENCE et à des livraisons plus fréquentes…
Livrer plus tôt et plus fréquemment, c’est potentiellement des revenus supplémentaires (nouvelles conditions de facturation, fidélisation ou conquête de nouveaux clients …). C’est aussi plutôt approprié pour les acteurs du marketing interactif qui pour optimiser leur taux de conversion et leurs parcours clients, ont besoin de tester encore et toujours de multiples configurations, ou de d’imaginer des « landing pages » toujours plus variées…
Maintenant, dans d’autres contextes comme l’Edition Logicielle, comment gérer sans douleur le passage obligé d’une à plusieurs versions par an ? SalesForce est passé par exemple de 1 à 4 versions / an ; PatientKepper est monté jusqu’à 45 versions.
Outre l’implication et la disponibilité d’un Product Owner (Marketing, et plus largement Business) qui devient nécessaire tout au long du projet, mais aussi la production d’éléments associés à chaque livraison, d’autres activités et secteurs de l’Entreprise s’en voient largement bouleversés … Sans compter les choix à opérer côté Marché et Utilisateur finaux ! Ces derniers sont ils prêts au surcoût de prise en main et d’apprentissage occasionné par une nouvelle version, aux éventuelles réinstallations (ouf merci le SaaS) et changements de licence potentiels ? Ne risque t-on pas de les déstabiliser ?
Autre élément de décision : la balance entre la volonté d’engager une conversation en continu avec ses utilisateurs en leur proposant le plus régulièrement possible de nouvelles choses et le risque de voir ces nouveautés noyées dans la masse des multiples annonces faites au sujet du produit. Sans oublier, le rythme naturel du marché dont il faut tenir compte…
Bref, une affaire de contexte, une affaire de produit, une affaire de stratégie … marketing !
Livrer plus souvent c’est donc ici ou là (Support, Ventes, Opérations …), des petites doses de travail supplémentaire à intégrer, donc des arbitrages à réaliser et la nécessité absolue de trouver son rythme entre des livraisons internes et externes à l’entreprise.
Un art que des entreprises comme Google maîtrisent à la perfection !
Commentaires:
Classé sous: Agile
