Posté par jc-Qualitystreet le 28 septembre 2011
Le daily scrum meeting est un des cérémoniaux Scrum, une bonne pratique collaborative mise en place par les équipes Agiles que vous connaissez sans doute pour la plupart d’entre vous. Mais connaissez-vous l’AFTER?…
photo: Karthik Chandrasekarial
Les régles de base du “Daily” sont désormais plutôt bien assimilées:
- “timeboxé” (pas plus de 15 minutes),
- tous les jours,
- tous ensemble
- tous debout
- même place (autour du taskboard),
- même heure
Bref, un vrai point de coordination par l’Equipe, pour l’Equipe (et PAS DE TIME REPORTING!!!!), source d’énergie et qui s’articule par la prise de parole, à tour de rôle, de chaque membre de l’équipe autour de ces 3 questions:
- qu’est ce j’ai fait hier?
- que vais-je faire aujourd’hui?
- qu’est ce qui m’empêche de faire mon travail?
Pour être court et efficace, pour ne pas déborder, il faut aller à l’essentiel; or parfois des questions peut survenir, on a envie d’aller plus loin….
On souhaite souvent s’étendre sur un point, se lancer dans une activité de résolution de problème, certains peuvent se sentir frustrer de pas aborder plus avant une question qui leur chère et qu’ils jugent importantes mais qui ne va pas forcement concerner tout le monde. L’AFTER est fait pour ça!
D’où l’idée de se réserver un After, une plage de 15 à 30 minutes, activable ou non, utilisable si besoin pour prolonger dans la foulée les échanges et démarrer un mini Workshop à 2 ou à plusieurs quand on a besoin d’échanger davantage avec certains membres de l’équipe.
Par défaut, la plage est réservée, pas d’autres Workshop ou autres réunions planifiées…
Voilà ce que certaines équipes que j’accompagne ont mis en place:
- Daily Scrum: 9h30
- AFTER : Jusqu’à 10h
et ça marche plutôt bien…
Posté par jc-Qualitystreet le 26 mai 2011
Tout frais, voici les slides de la présentation que j’ai donnée ce jeudi matin à la conférence Agile France2011. Cette session intitulée “Dans la peau du Manager Agile” est consacrée au Management 3.0, un management Agile & Lean. Le pitch:
“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. Entre nécessité et opportunité, le métier de Manager Agile (au sein d’une organisation agile) devient un savant compromis entre le maintien de certaines responsabilités, l’abandon de certaines autres et l’acquisition de nouveaux savoir-faire et savoir-être… L’ère du management 3.0 Agile & Lean est annoncée!”
Posté par jc-Qualitystreet le 13 mai 2011
La conférence Agile Francophone de l’année approche à grand pas, les 26-27 mai, au vert, Chalet de la Porte Jaune (bois de Vincennes).
Retrouvez-moi dans deux sessions:
Le reste du programme est impressionnant; durant ces deux jours, de vraies opportunités pour apprendre et vous former, pour échanger, communiquer mais aussi de multiples occasions de participer, et de vivre l’agilité l’espace de quelques heures dans des ateliers ou agile games toujours plus créatifs!
Au plaisir de vous y croiser et de discuter avec vous de ces sjuets qui font mon quotidien depuis quelques années:
- Trans formation et Coaching Agile
- Management Agile
- AgileUX (Experience Utilisateur & Ergonomie Agile)
- Agile Testing & ATDD
P.S: De douloureux événements personnels survenus récemment ont entravé la bonne marche de ce blog. Ne m’en tenez pas rigueur chers lecteurs… de nouveaux articles seront publiés très bientôt.
Posté par jc-Qualitystreet le 24 mars 2011
Une User story est une exigence du système à développer, une brève description d’une fonctionnalité telle que vue par l’utilisateur ; très en vogue sur les projets agiles. Dalleurs je n’utilise quasiment plus que ça.
« En tant que Client, je veux réserver un billet de train pour me rendre à Paris »
Quand on pense aux User Stories, on pense d’abord à la règle des 3C et aux critères de qualité (INVEST) et au format « User Voice”…
User Story INVESTed... dans un format orienté But Utilisateur tourné vers la valeur
Chaque user story sera estimée et priorisée mais ce qui caractérise aussi une user story, c’est qu’elle doit être SUFFISAMMENT PETITE pour être livrée dans un sprint (généralement les équipes embarquent au minimum 3 stories par sprint) . Une véritable nécessité si on veut observer de vrais gains en termes de valeur produite, de visibilité, d’avancement, de flexibilité, de feedback et d’amélioration continue.
Au cours de mes missions de coaching agile, je suis donc régulièrement amené à aider l’Equipe et le Product Owner à décomposer des user stories en user stories plus petites.
Voilà les 10 stratégies de décomposition que je propose, toutes efficaces et éprouvées !
1 Par étapes d’un Workflow
L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémental.
2 Par scenario
On obtient une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’autres pour les cas d’erreurs ou les scénarios alternatifs :quand il se passe x ; quand il se passe y
3 Par séquence dans un scénario
Le cas est plus précis, on découpe cette fois-ci une séquence au sein d’un scénario…
4 Par opérations
Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer.
5 Par format ou type de données
Assez évident aussi. On joue sur le type d’objet (ex : compte titres, espèces… messages en français, anglais, espagnol…)
6 Par type d’entrée, sortie ou configuration
Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi au niveau de l’interface…
7 Par Persona ou rôle
Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’appuyer le user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit.
8 Par niveau de connaissance
Le niveau de connaissance acquis sur une fonctionnalité est un bon critère de décomposition…Une story pour ce qui est connu, une autre là où c’est moins maîtrisé. Çela peut déboucher sur un spike (une user story un peu particulière orientée exploration)
9 Par niveau de complexité
Une user story va par rexemple décrire une fonctionnalité dans son mode de réalisation le plus simple, d’autres suivront par un niveau de complexité plus grand
10 Par niveau de qualité attendu
Performance, Sécurité, Utilisabilité… ces exigences non fonctionnelles constituent le plus souvent des conditions de satisfaction pour des user stories spécifiques mais elles peuvent permettent également de distinguer des user stories entre elles (ex : afficher en moins de 60 sec, moins de 30 sec ; données en temps réels ou non…)
Les illustrations viendront au fur et à mesure ; si vous voulez participer, n’hésitez pas à proposer votre exemple en commentaires avec le n° de stratégie correspondant… un post incrémental et participatif en quelque sorte
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!
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!
