Valeurs de l’agilité: le courage

Posté par jc-Qualitystreet le 4 avril 2011

Voilà ce que cela signifie pour certaines équipes agiles que j’accompagne…

Courage: une valeur Agile

ET POUR VOUS?

Scrum Day France 2011: un programme d’enfer!

Posté par jc-Qualitystreet le 22 mars 2011

Jeudi  31 mars se déroulera chez Microsoft, une journée de conférence, organisée par le French Scrum User Group, et consacrée uniquement à Scrum (et à l’Agilité).

Pas de session proposée de mon côté,  j’y serai, en spectateur pour en profiter pleinement… d’autant que le  programme est incroyable, regardez-plutôt.

Ils “ouvrent” à 8h30 mais le sessions démarrent à 10h45…une trés belle journée en perspective!

Scrum Day: Le programme du matin

Scrum Day: Le programme de l'après midi

J’espère que les ROTI seront de sortie pour les sessions!

Equipe Agile et Diversité: les différences qui font la différence

Posté par jc-Qualitystreet le 14 mars 2011

• Co-localisée,
• Dédiée,
• AUTO-ORGANISEE,
• CROSS-FONCTIONNELLE,

plus que de simples caractéristiques d’Equipe, il s’agit de quatre pratiques agiles et composantes incontournables d’un environnement agile propice au succès. Parmi elles, l‘Auto-organisation (capacité d’une équipe à décider de l’organisation de ses propres activités pour atteindre les objectifs fixés) est souvent citée (à juste titre) comme le moteur de la super-performance, mais la diversité en est aussi un ingrédient essentiel !

Soutenir la diversité n’est pas seulement un réflexe humaniste, c’est croire avant tout en une pensée constructiviste et adaptative conduisant au succès.

Favoriser la diversité pour provoquer les coups de chance…

Et faciliter le changement à moyen et long terme…

La variété est une richesse… la Vie et l’histoire des espèces, faites de tant de heureux hasards, en sont les meilleurs exemples.  La diversité dans l’Entreprise est également une richesse, source de dépassement et d’innovation. Contrairement aux idées reçues, la diversité ne se joue pas seulement en termes d’origines, d’âges ou de sexes, elle se joue aussi et surtout  en termes d’expériences, de savoirs, d’idées et de points de vue. Dans l’entreprise, c’est  le rôle de l’organisation et du Management d’assurer cette diversité cognitive, cette diversité des perspectives, et de réunir les conditions permettant aux coups de chance de se produire.

Comment ?

• en décloisonnant toujours plus,
• en sortant de la logique des silos,
• en créant des espaces d’échanges pourquoi pas virtuels, mais surtout physiques,

Open Space Technology en Interne

• en facilitant par tous les moyens les échanges et les interactions sociales,

Googleplex: ouverture et interactions

• ou encore en créant un maximum de petits points de rencontre informels…

Googleplex: toujours plus d'heureux hasards

On s’enrichit de ses différences… « des différences qui font la différence »

La diversité , c’est aussi la base du conflit socio-cognitif, et de cette incroyable capacité des interactions sociales pour nous faire apprendre, progresser et voir le monde différemment. C’était tellement vrai durant l’enfance,  ça l’est aussi à l’âge adulte…

A nous de retrouver la créativité et cet esprit d’ouverture qui nous caractérisait tant quand nous étions enfants!

A l’entreprise de nous y aider !

Ajouter une Vision pour se différencier et innover

Très vite, à court terme.

C’est un peu, j’imagine, la diversité des contenus présents sur ce blog qui fait sa richesse et sa différence. A vrai dire, je n’ai jamais su rentrer dans des cases et qualitystreet.fr en est le reflet… maintenant vous proposer une collection de contenus sans une direction affichée n’aurait guère de sens. Le mariage de ces différentes techniques et disciplines présentées ici se veut au service de vos projets IT, et vise la réalisation de produits de qualité avec des utilisateurs et collaborateurs satisfaits. J’essaie de vous transmettre ce cadre.

Dans l’univers IT et dans une perspective plus sociale,  celle d’une dynamique d’équipe par exemple, pour que la diversité tienne toutes ses promesses, il faut aussi lui donner un cadre pour s’exprimer. Ce cadre c’est une vision commune vers laquelle les efforts de chacun pourront tendre.

La vision et les objectifs communs permettront alors aux personnes de dépasser leur divergence, de sortir de la zone de turbulences qui accompagne inévitablement cette confrontation salutaire, pour que le collectif en sort grandi et enrichi. C’est justement toute la force de l’Equipes Agile, une équipe diverse et auto-organisée autour d’une vision et qui tend vers des objectifs communs.

Le workshop spécification, portant en cours de sprint sur des User Stories à réaliser, est l’exemple le plus frappant des bienfaits uniques de l’équipe agile cross-fonctionnelle, celui qui me permet régulièrement de mesurer toute la richesse et la puissance de la diversité. On y retrouve en effet réunis pendant quelques heures:

• Un Product Owner qui réfléchit le plus souvent en terme de valeur et décrit le cas, qu’il a imaginé, celui où tout se passe bien
• Des développeurs qui envisagent les composants, les cas aux limites et proposent des alternatives techniques
• Un ou des testeurs qui cherchent les moyens de casser ce beau scénario et amènent la réflexion sur le terrain des erreurs (comment elles apparaissent-elles? comment les gère-on?…)
• Le spécialiste UX (user Experience) qui pense avant tout «Utilisateur», et défend le confort de celui-ci et la satisfaction de ses buts.

A la fin de cet atelier de travail, facilité par le ScrumMaster, consensus et sentiment du devoir accompli sont le plus souvent au RDV…

Bref, la diversité, y-a -que ça de vrai!

Mon Backlog de produit est DEEP… et PHY-SI-QUE!

Posté par jc-Qualitystreet le 31 janvier 2011

Le Backlog de produit est cette liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit. C’est le véritable fil rouge d’un projet Agile Scrum.

Vous qui suivez ce blog, vous connaissez peut être déjà les caractéristiques majeures (D.E.E.P.) d’un bon backlog ?

Mon Backlog est DEEP: c'est clair !

Malheureusement, on peut constater que parmi les équipes travaillant dans un mode Agile, encore peu de backlogs de produit répondent aujourd’hui à ces critères de qualité!

Étonnamment (ou pas), la question de l’outil permettant de gérer ce backlog suscite souvent plus d’intérêt… Outils dédiés, payants ou non,  Excel, Google spreadsheet mais aussi Sharepoint, Jira voire même QualityCenter (si si je vous assure…)… quel outil choisir? Mais, c’est oublié assez vite, une autre caractéristique du Backlog de produit qui pour moi demeure essentielle: sa dimension physique.

Mon Backlog de produit est avant tout PHYSIQUE

Disposer d’une version physique (postits ou bristols sur un mur) du Backlog de produit, visible et accessible en permanence, est tout simplement indispensable. Accompagné de sa courbe, le BurnUp, c’est selon moi un élément clé du radiateur d’informations.

Backlog Physique: je vois où j'en suis; et là ON TOUCHE AU BUT !

Des bénéfices bien réels…

Le backlog de produit « physique » :

• offre aux yeux de tous (Equipe ou non) une vraie visibilité sur l’avancement du produit: ce qu’on fait, ce qu’on a fait et surtout le chemin restant à parcourir.

La vison du produit nous donne le cap ; le backlog de produit guide nos pas.

• est un signal fort de transparence (valeur forte de l’Agilité), mais aussi la marque d’une vraie volonté d’ouverture et de recherche de collaboration et de feedback
• permet aussi, en plus du produit partiel livré à chaque sprint, de DONNER DU SENS au travail de l’équipe. Proposer & afficher un but, une ambition est une source de motivation et d’engagement désormais reconnue. Le backlog de produit en tant que fil rouge du projet, vient concrétiser tout cela.
• Donne enfin la vue globale, cette “big picture” que CHAQUE MEMBRE DE L’EQUIPE ATTEND, et qu’aucun outil virtuel ne peut à ce jour remplacer.

L’esprit Agile et quelques prérequis

Le coût de création, notamment d’écriture, est un faux-problème (car l’ensemble prendra au final très peu de temps). Toutefois, l’efficacité du backlog de produit physique nécessite:

• Que celui-ci soit affiché, au sein du radiateur d’informations, là où l’Equipe travaille et donc évidemment pas très loin du Product Owner
• Que celui-ci soit partagé et qu’il devienne un élément de discussion entre l’Equipe et le Product Owner. Le backlog de produit physique doit devenir un véritable point de rencontre
• Que celui-ci soit «bichonné» et mis à jour en continu: laisser un backlog de produit à l’abandon dans un coin du mur n’est pas acceptable, c’est le signe que quelque ne va pas.

Trois conditions qui se travaillent au fil des sprints.

Vous l’aurez compris: le backlog de produit, moi j’en suis Fan !

Evidemment, les versions électroniques des backlog de produit restent INDISPENSABLES pour les équipes distribuées évoluant dans des contextes distants. Pourtant, y compris dans ces contextes, il faut savoir revenir à plus de simplicité, et redonner l’outil sa vraie place, c’est à dire « rendre les processus plus efficients et faciliter le travail des personnes ».
L’outil doit rester source de valeur, et ne doit pas ni devenir une contrainte ni une forme de gaspillage.

Management 3.0… Dans la peau du Manager Agile

Posté par jc-Qualitystreet le 8 novembre 2010

Quand il s’agit d’agilité, ne laissez pas vos Managers au bord du chemin ! Aidez-les plutôt  à devenir des managers Agiles… et à maîtriser l’évolution de leur métier.

L”ère du management 3.0 est annoncée, un management AGILE et LEAN !

En haut, en Bas… et Au Milieu !

Approche « Top-Down » ou « Bottom-Up », le débat est largement dépassé. On sait aujourd’hui que le soutien de la direction et que l’appropriation par les équipes sur le terrain sont des conditions essentielles pour assurer la réussite d’un projet de transformation Agile.

Non, les enjeux de l’Entreprise Agile se situent désormais dans les couches managériales intermédiaires de l’organisation…

Comment les aborder ? Comment les convaincre ? Comment les transformer ?

Agile Middle Management - Vers un management intermédiaire agile

Mon expérience des projets agiles et du coaching Agile dans des secteurs variés (bancaire, industriel, édition logiciel…) m’a montré que c’est bel et bien le middle management qui détient les clés de l’agilité sur le Long Terme.

Ce management intermédiaire sera soit le meilleur catalyseur d’agilité devenant le plus beau des alliés, soit  le pire obstacle et donc le plus farouche opposant ! L’agilité reposant sur des valeurs clés comme la collaboration, la communication, ou le feedback… si on ne joue pas le jeu, c’est tout de suite plus compliqué (et très visible)…

Le Manager : Acteur clé du Changement

L’introduction de l’Agilité induit un changement fort dans ce système complexe et social qu’est l’organisation. Diagnostics et pilotage approprié sont nécessaires… des activités dans lesquelles on retrouve très vite ces personnages incontournables, relais de la mutation agile, que sont les managers.

Exemple d'exercice. Workshop Forces et Résistances au changement

Positionnement, nature et niveau de l’impact, réactions probables, freins et leviers à activer (en termes de communication, de formation ou de participation) : le Middle Management est une cible privilégiée du coach Agile engagé dans un programme de transition avec un travail qui s’effectuera à la fois sur le plan individuel, collectif et organisationnel.

L’opportunité de devenir  un Manager Agile et de faire évoluer son métier…

Dans un seul but : la réussite des équipes ….

L'évolution des métiers: Le MANAGER AGILE

Le mode de management « Command & Control » issu du Taylorisme et de l’organisation scientifique du travail (OST) , avec sa vision appauvrie de l’Homme au Travail a montré ses limites; le manager agile explore de nouvelles dimensions pour garantir le succès de tous.

Le métier de Manager Agile (au sein d’une organisation agile) est donc un savant compromis entre:

• le maintien de certaines responsabilités,
• l’abandon de certaines autres (par exemple distribution des tâches)
• et l’acquisition de nouveaux savoir-faire et savoir-être.

Alors même si les frontières du rôle de Manager sont propres à chaque individu et à chaque organisation,voici selon moi les 6 pistes à privilégier:

1. (Toujours) Gérer le portefeuille de projets (priorités, stratégies, budget, ressources)  et se coordonner, travailler en équipe avec les autres managers
2. (Toujours) Gérer les recrutements (les départs et éventuels conflits)
3. Soutenir les  projets et Equipes Agiles Auto-organisées (en favorisant autonomie et responsabilisation, en levant les obstacles que l’Equipe ou Le ScrumMaster ne sont pas en mesure de lever, en gérant la logistique, l’achat de fournitures, en challengeant les équipes et en les aidant à acquérir de nouvelles compétences par du training, des séminaires, conférences ou, livres…)
   

   liste des obstacles de l'Equipe Agile

4. Créer une relation de confiance, développer (carrière) et MOTIVER les personnes (par la connaissance de chaque personne et de son travail, en facilitant l’acquisition de nouveaux savoirs, en se rendant disponible, en donnant de la reconnaissance, du Feedback mais aussi en déléguant quand il le faut)
5. Créer un environnement organisationnel propice au succès et Booster le changement (en communicant la Vision, en donnant du sens, en adoptant le style de management adapté, en simplifiant les usages, en recherchant la performance au travers d’outils et de processus adaptés fondés sur l’amélioration continue et la chasse aux gaspillages)
6. Initier, Soutenir et pourquoi pas animer les INDISPENSABLES communautés de pratiques (en donnant du temps, des moyens aux communautés agiles transverses, ScrumMaster, Product Owner, Manager Agile, Architectes…, et surtout en en faisant la promotion)

Mais aussi la nécessité “d’être” un Manager Agile !

De nombreux éléments concourent à cette prise de conscience et à la naissance d’un sentiment d’urgence, seuls véritables points de départ d’une volonté de changer:

1. Tout d’abord, l’environnement externe de l’entreprise fait de changement rapide, de complexité dynamique et de concurrence accrue retentit à l’intérieur même de l’entreprise. Poussée à revoir son mode de gouvernance et ses processus, l’organisation est amenée à se différentier en termes de connaissances, de partage d’informations, de gestion de compétences ou d’évolution des collaborateurs. L’entreprise Globale, Agile & Lean est une réponse évidente à cette vaste problématique, et le manager est en première ligne de ces chantiers.
2. Le middle management constate aujourd’hui à la montée en puissance d’une Agilité de terrain, imposée ou non par sa hiérarchie. Les méthodes Agiles s’incrustent dans les  projets, dans le quotidien des personnes. Très populaires dans les projets IT, il est difficile de les éviter et  de ne pas s’y intéresser, en tant que responsable de personnes fortement impliquées dans l’agilité.
3. D’autant que cette nouvelle façon de concevoir des produits, d’envisager et de mener un projet informatique FAIT DU BRUIT,  avec des résultats concrets et des bénéfices réels et  visibles : réduction des délais de mise en marché, qualité, productivité, visibilité, satisfaction des équipes. L’agilité, ça marche et ça va s’étendre. ..
4. Enfin, les attentes des personnes évoluent. L’esprit AGILE gagne les collaborateurs qui goûtent aux projets Agiles, Scrum ou autres, avec un rapport aux autres, au travail et à l’organisation forcément changé. Dans le même temps et d’un point de vue générationnel,  l’Entreprise change de visage avec la présence de plus en plus marquée de la génération Y, ces digital natives nés à partir des années 78-79, dont les maîtres mots sont collaboration, réseaux et communautés… Dans les deux cas, le style de management agile et ouvert est une attente forte.

Des idées pour sortir du status quo ou lever les résistances?

Manager Agile la (r)évolution en marche

HUMANITÉ, PROXIMITÉ, FACILITATION, COLLABORATION  & LEADERSHIP , voilà ce qui concrétise le mieux le manager Agile au quotidien.

Le Manager Agile: Un chef d'orchestre

Un manager « Chef d’orchestre », à la fois actif, réactif et proactif, qui peut facilement et dans un premier temps, trouver l’inspiration dans ces quelques principes du Lean Management :

• Penser sur le long terme (c’est à dire fonder ses décisions sur une philosophie à long terme même si cela affecte la réalisation de certains objectifs financiers à court terme)
• Cultiver les leaders (c’est à dire faire grandir les leaders qui comprennent et connaissent le travail, vivent la philosophie, et l’enseignent aux autres)
• Faire monter en compétences les personnes (c’est-à-dire développer les personnes et équipes exceptionnelles (« les talents ») qui suivent la philosophie de l’entreprise
• Respecter et motiver ses partenaires (c’est à dire respecter son réseau étendu de partenaires et de fournisseurs  en les challengeant et en les aidant à s’améliorer)
• Aller toujours sur le terrain (c’est à dire aller et voir par soi même pour comprendre les situations en profondeur)
• Prendre les décisions en consensus (c’est-à-dire prendre les décisions lentement en consensus en considérant toutes les options puis mettre en œuvre rapidement les décisions choisies)
• S’améliorer en continu (c’est-à-dire devenir une organisation apprenante au travers de la réflexion et de l’amélioration continue - Hansei & Kaizen)

En tout cas personnellement, c’est ce que j’attends de mes managers !

Et mon rôle du Coach Agile dans tout cela ?

C’est simple : accompagner ces managers dans leur parcours vers l’Agilité et dans l’exercice de nouvelles pratiques !

Et pour en savoir plus, contactez-moi …

Agile Testing Days - Jour 1

Posté par jc-Qualitystreet le 6 octobre 2010

Agile Testing Days 2010 : Jour 1 (English version : Day 1 on www.agile-ux.com)
Agile Testing Days 2010 : Jour 2 (English version Day 2 on www.agile-ux.com)
Agile Testing Days 2010 : Jour 3 (English version Day 3 on www.agile-ux.com)

Première journée de conférence des Agile Testing days au Seminaris Center de Berlin. Quelques centaines de participants, 26 nationalités : une conférence anglophone même si dans les couloirs l’allemand se laissait facilement entendre.

Les plus grands experts du Test Agile se sont donnés RDV pour échanger sur un sujet désormais incontournable des projets SCRUM, et plus largement Agiles : le TEST.

Des Keynotes de très Haut Niveau

Pas moins de 3 Keynotes, et non des moindres, pour cette première journée avec 3 femmes à l’honneur : Lisa Crispin, Linda Rising et Elisabeth Hendrickson.

Keynote d'ouverture

Lisa Crispin s’est chargée du keynote d’ouverture : “Limbo Lower now : an agile approach to defect management”. Une ouverture en fanfare sur une question de fond et récurrente dans le cadre de nos missions de coaching : Outil de gestion des anomalies, OUI ou NON ? avantages ou inconvénients ? pour quels contextes ?

Limbo Dancing from Lisa Crispin

Après avoir présenté la vision traditionnelle des défauts, Lisa présenta les autres perspectives, agile et lean:

“Defect queues are waste. It’s inventory”

“You find a defect, fix it because bugs are technical debt”

La prévention des défauts est donc le cœur et doit constituer l’unique but de l’équipe :

« make it a Team problem »

Pour le reste c’est une affaire de contexte, et la capacité d’expérimenter plusieurs options (commencer sans DTS, fixer des règles simples comme pas plus de 10 défauts à la fois, utiliser le taskboard …)  pour au final, aprés retrospective (”Inspect & Adapt”) trouver celle qui colle le mieux …

« Do that works for your team »

Second keynote avec Linda Rising en début d’après midi « Deception and estimation : how we fool oursevelves”.

Dans un style rempli d’humour et de finesse, mais sur fond de psychologie cognitive, Linda Rising démontra à quel point l’être humain est mauvais dans ses estimations.  Des exemples du quotidien, et  la capacité jouer avec son auditoire ont mis l’ambiance tout en assurant une démonstration efficace…

Le lien avec les projets IT : de mauvaise estimations tout simplement:

“We tend to believe we’re better than we are”

et on aurait tendance à sur estimer notre capacité de faire (analyse, dév, test…).

“Agile to the rescue”

Et c’est là que l’agilité nous sauve avec son découpage en petites étapes, son juste ce qu’il faut, son ouverture, son travail collectif et la possibilité d’expérimenter et d’apprendre  de ses erreurs. Bref, être Agile permet d’atténuer, seulement, ce défaut tellement humain !

Dernier keynote de la journée avec Elisabeth Hendrickson « Lessons learned from 100+ Simulated agile transition ».

Un dynamisme hors du commun pour relater ses observations et exposer conclusions obtenues suite à  la passation, plus d’une centaine de fois de sa simulation de transition agile, WordCount. Ce qui ressort de ses données: pas mal de choses à commencer par ce qui caractérise une équipe qui marche de celle qui ne marche pas, mais aussi quelques invariants : les personnes ajoutent leur propre complexité et se mettent la pression du temps, toute transition conduit au CHAOS (pour une période de temps seulement … heureusement !), les tests servent d’outil d’ajustement et permettent de s’aligner (Business / IT).

Ou encore, en version originale :

“Don’t use communication solutions for visibility problems”

(c’est parce que tu ne sais pas ce qui se passe que tu en parles !! ) A vrai dire, C’est assez juste

Dernier conseil aux coachs et facilitateurs que nous sommes : Faire confiance à l’équipe ! Lui donner l’info dont elle a besoin et  savoir prendre du recul (« sortir du cercle ») sans lui dicter ce qu’elle a à faire!

“Trust the group”

Côté sessions : des confirmations

Une matinée orientée ATDD (Acceptance Test Driven Development) avec un focus sur Robot Framework, outil d’automatisation des tests, au travers des sessions de Thomas Jaspers (« Testing web applications in practice… ») puis de Pekka Klarck (« ATDD using Robot Framework »).

ATDD using Robot Framework avec Pekka Klarck

Au programme : la volonté de montrer l’excellente intégration de Robot Framework avec Hudson et Selenium pour le premier, et de bons exemples de cas de test (syntaxe BDD ou non) pour le second.

Intéressant donc … RobotFramework semble être l’outil qu’un grande partie de la communauté des testeurs semble pousser, un outil sur lequel Valtech Technology (avec Maxime, Laurent et Yannick) a beaucoup communiqué, afterwork , tutoriel, blogs ou conférence..

L’après midi, des confirmations sans plus, avec la session de Geneva Murphy « Requirements in the agile world » surtout (et un peu trop) centrée sur les outils de sa socièté HP !

Agile Requirements - Image ou Texte

Les 4 axes de la session:

“Be lean, Iterate, Visualize, Collaborate “

… on est d’accord ! Cela dit, on est resté en surface sans toucher l’essentiel et sans creuser les attentes des équipes agiles que je peux coacher…

Plus intéressante, la session de Ray Arell, « Waterfall to an agile testing Culture » avec une attention toute particulière sur la place de la dimension « Culturelle » dans un chantier de transformation Agile.

Ray aborde le sujet au travers d’une comparaison tout à fait pertinente avec le « Thru-Hiker » (”randonneur de l’extrême ?” celui qui par exemple se fait une rando du Mexique au Canada à 20 miles /jour).

Agile Testing Culture - Ray Arell

Même plan, même préparation, même but, même rythme, l’équipe Agile et le « Thru-Hiker » cherchent tous deux à éviter le danger et vont avancer en s’appuyant sur des succès incrémentaux.

Bref, sans la culture Agile (représentée selon Ray entre autres par un rythme soutenable, un environnement de confiance, un espace ouvert et de collaboration, la motivation…), ça ne marche pas ; un point dont je suis intimement convaincu.

Trop d’organisations veulent aujourd’hui « faire de l’agile » pour en récolter les bénéfices mais surtout sans efforts et sans remise en cause de la culture organisationnelle. Mon message : « Dégrader l’agilité et vous obtiendrez des résultats … dégradés ! ».

Seuls les efforts paient ; pour avoir des résultats, il faut travailler encore et encore et … faire des efforts !

La suite, demain.