Posté par jc-Qualitystreet le 20 octobre 2011
La vélocité est indicateur très utilisé en agilité, en Scrum notamment.
La vélocité d’une équipe sur un sprint se mesure en Points (d’effort relatif) et correspond à la somme des points associés aux STORIES qualifiés de DONE à la fin de ce sprint.
Le pré requis : que les stories et une grosse partie du Backlog aient été estimés en Points au préalable.
Jusque là tout va bien… puisque il ne s’agit que de faire une somme. Et puis l’indicateur est précieux puisqu’il donne de la visibilité notamment sur le chemin à accomplir pour terminer une Release, atteindre un périmètre :
Mon backlog de release fait 100 points, notre vélocité après 4 sprints s’est stabilisée autour de 10 points => nous aurons besoin 10 sprints de 2 semaines pour Terminer…
On ne peut plus simple !
L’alerte ne se situe pas tant là, au niveau de l’Equpe Scrum (au sens large Equipe + PO + ScrumMaster) mais plutôt à l’extérieur de celle-ci (Management, Programme), dans un contexte de Scrum à l’echelle. En effet, dés lors que plusieurs équipes agiles émergent, la tentation est grande de
- COMPARER… de comparer au final CE QUI N’EST PAS COMPARABLE! Ta vélocité n’est pas vélocité
- SE FOCALISER UNIQUEMENT sur ce seul indicateur pour juger la performance des équipes: 10 de vélocité, 3 coups de bâton; 30 de vélocité, 3 chocolatsJ
Repeat after me…
LA VELOCITE EST PROPRE A UNE EQUPE, FONDEE SUR SES PROPRES ELEMENTS DE REFERNCE, IL EST INUTILE ET STUPIDE DE LES COMPARER.
La valeur apportée par l’indicateur vélocité est souvent discutée. Encore dernièrement, Esther Derby en faisait sa cible avec des arguments sonnant juste pour tous ceux qui ont derrière eux quelques années d’Agilité :
- la vélocité est facilement manipulable (c’est vrai, je l’ai vu, côté management, côté Equipe),
- la vélocité est facilement mal utilisée (c’est le propos de cette alerte)
- la vélocité n’est pas la meilleure métrique dans un contexte de transition agile.
Mon challenge :
- Sensibiliser Directions, Management et Programmes sur la question des indicateurs agiles (notamment la vélocité) et des estimations (agiles)
- Former et accompagner les équipes SCRUM sur la façon de réaliser les estimations (Release planning, Planning poker….) et sur les indicateurs à fournir toujours adaptés au contexte
- Eviter toute dérive de comparaison entre équipes
- Proposer d’autres indicateurs (lead time, qualité initiale, WIP, Items bloqués, satisfaction de l’Equipe, risques, taux d’occupation, obstacles, prédictibilité…)
- Re-instaurer la CONFIANCE, car ces mauvaises usages et interprétations traduisent le plus souvent un déficit de CONFIANCE au sein de l’organisation
Mes autres Alertes:
Posté par jc-Qualitystreet le 17 octobre 2011
Ou 1pt=3 jours… etc
Nouveau point d’attention pour le coach agile dans son accompagnement des équipes qui cherchent à faire du SCRUM car même si une telle correspondance est tentante pour certains, elle vous sort de la dynamique d’estimation agile et vous éloigne petit à petit de l’esprit Agile…
1 point => 2 DAYS!!!
Même avec des équipes ayant mis en place des pratiques agiles depuis quelques mois, voilà ce qu’on peut parfois observer…
« 4 points, on va la mettre à 4 points… 4 points c’est 8 jours normalement, non ? »
Alerte ! Car derrière l’agilité se cachent à la fois une nouvelle façon d’estimer et plus largement une autre façon, réaliste, de considérer les estimations :
« Nous autres Etres humains ne sommes pas câblés pour estimer on se plante tout le temps… »
La vision concrète, réaliste et adaptative (vs prédictive) de l’agilité nous amène à ré envisager 4 éléments clés relatifs aux estimations ; avoir l’esprit agile c’est donc avant tout revoir :
- L’importance et la place accordées aux estimations
- L’effort nécessaire pour les produire (Just enough)
- La façon de les réaliser: l’estimation agile est COLLECTIVE, faite JUSTE à TEMPS, par CEUX QUI VONT FAIRE LE BOULOT, RELATIVE (stories estimées en terme d’effort les unes par rapport aux autres), RÉVISÉE régulièrement
- La durée de vie des estimations
Mon challenge :
- Sensibiliser Directions, Management et Programmes sur la question des estimations (agiles)
- Former et accompagner les équipes sur la façon de réaliser ces estimations (Release planning, Planning poker….)
- Eviter toute dérive et tentative de correspondance Point/ Heures (certes compliqué qd l’équipe travaille comme ça depuis quelques temps)
- Toujours challenger le «Just enough, Just in Time»
- Insister sur la notion d’Equipe et la nécessité de bien se connaitre
« + l’Equipe avancera ensemble, + l’Equipe se connaîtra, + ses estimations (just enough, just in time) seront fiables »
Mes autres Alertes:
Posté par jc-Qualitystreet le 5 juin 2009
Product Owner c’est l’un des 3 rôles (avec le ScrumMaster et l’Equipe) proposé par Scrum; c’est aussi un vrai point de vigilance pour moi en tant que Coach Agile.
Le Product Owner est le responsable du produit, le représentant du client et des utilisateurs et donc à ce titre l’interlocuteur privilégié de l’Equipe.
Le rôle est essentiel; son importance est primordiale:
être Product Owner sur un projet Agile, c’est déjà pas mal de responsabilités (LA DECISION), c’est aussi:
- s’impliquer
- savoir communiquer
- savoir collaborer
- se rendre un minimum disponible
- disposer d’un certain savoir-faire…
Autant d’éléments, autant de risques que les choses dérapent…
Product Owner
Quant à l’activité du product Owner, même si son profil peut varier, elle est plutôt bien cadrée :
- Partager la Vision
- Définir et Alimenter un Backlog
- Fixer les priorités
- Décrire les fonctionnalités
- Ajuster les fonctionnalités et les priorités à chaque sprint
- Accepter ou rejeter les résultats (sur la base des critères d’acceptation)
Autant d’activités (et des registres différents), autant de risques que les choses ne dérapent… Backlog incomplet, exigences déconnectées de la réalité, de la valeur, Vision non partagée voire obscure, Absence de décision, Imprécision des critères d’acceptation, inéfficacité des échanges avec l’équipe, des ateliers de travail, manque de disponibilité et de présence à des RDV clés.
Seul, le Product Owner, peut il y arriver ? LA REPONSE EST NON!
mais il peut compter sur l’équipe me dire-vous?
OK mais pas suffisant…
Le Product Owner doit d’abord être accompagné.
Ensuite, même si le Product Owner doit parler d’une seul voix (vis à vis de l’équipe notamment, c’est un fondamental), constituer autour de lui une ”Team Product Owner” est trés souvent une pratique gagnante.
De ce point de vue, l’Ergonome est ce partenaire privilègié qui va appuyer le travail d’estimation et de priorisation du Product Owner, Il est aussi celui qui peut l’aider à clarifier et communiquer sa Vision, à recueillir et définir les besoins au travers de multiples ateliers de travail et d’une approche Personas. Associer trés vite Product Owner et testeurs est aussi un facteur clé de réussite
Mon Challenge :
- Faire adhérer aux valeurs Agiles
- Former à la pratique du SCRUM: les règles à respecter, le déroulé, l’attitude et les points de vigilance
- Définir précisément les rôles et responsabilités de chacun
- Diagnostiquer et dimensionner le rôle Product Owner sur le projet
- Construire le Team Product Owner si nécessaire
- Coacher le Product Owner sur 1 ou 2 sprints, avec un fort accompagnement en Sprint O
Mes autres Alertes:
Posté par jc-QualityStreet le 11 décembre 2008
Et bien, pour l’ÉQUIPE AVANT TOUT ! …
pas pour le ScrumMaster (en quelque sorte le chef de projet agile) ni le management ou les décisionnaires…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 8 septembre 2008
… pas dans l’Equipe, et c’est bien dommage !
WAIT! There is more to read… read on »
