La durabilité des effets plutôt que l'optimisation de la production
Optimiser, pourquoi pas, mais optimiser la production pousse à ne pas donner assez d'importance aux effets du résultat, en privilégiant la productivité sur l'impact.
Priorité
La notion de valeur pour le Product Owner, de l'utilitarisme au don
Cet article est une version revue d'un extrait de l'ebook L'agilité, extension du domaine du don publié par le collectif Agile Radical à l'occasion du calendrier de l'avent.
L’extrait porte sur le récit de Lucas, Product Owner de PermaBio.
La première partie aborde la notion de valeur à travers l’histoire de Lucas, qui a évolué d’une vision utilitariste vers le paradigme du don.
L'impact sur le vivant comme critère pour définir les priorités
Nous voulons des coquelicots !
Le Manifeste agile met en avant la collaboration avec le client plus que la négociation du contrat. Dans notre précédent article, nous avons constaté qu’en fait, sur le terrain, ce qui s’est passé dans les équipes agiles, c’est :
la coopération avec le Product Owner plus que la collaboration avec le client
C’est bien. Mais il est temps d’aller encore plus loin.
Prioriser avec CD3
Coût du Délai Divisé par la Durée
Comment prioriser, estimer et planifier ?
Il existe de nombreuses techniques de priorisation, par exemple HIPPO, 10/10, VRAC. Étudions un nouvel outil, le CD3.
CD3, c’est le Coût du Délai Divisé par la Durée.
Prioriser, estimer et planifier
Agile ou pas, il est souvent utile d’avoir des prévisions sur le moyen terme
Prioriser, cela permet de définir l’ordre de développement. Dans le cadre de Scrum, la priorisation porte sur les éléments du backlog et indique à l’équipe sur quoi elle va travailler dans le ou les sprints qui viennent.
La priorité d’une fonctionnalité est basée sur sa valeur métier, mais pas seulement. Pour affiner l’ordre de cette fonctionnalité et se projeter un peu plus loin que le travail immédiat, il convient aussi de s’intéresser à l’effort pour la développer. Le fameux Planning Poker est une technique d’estimation couramment utilisée par les équipes.
Critères VRAC pour la priorité dans le backlog
Prioriser, en VRAC ou pas, c'est une activité clé de l'affinage du backlog.
Prioriser est un néologisme souvent utilisé, et pas que pour un backlog. Avec Scrum, on dit que le Product Owner priorise les éléments du backlog. Bien qu’en fait, il les ordonne.
Mais sur quels critères se base t-on ?
Le PO proxy n'existe pas
Si vous avez défini un rôle de Product Owner proxy, vous faites du faux agile
J’ai participé vendredi à une réunion/débat organisée par l’association Agile Toulouse sur le rôle de PO, axée sur la notion de PO Proxy.
En faire moins
La *to do less* liste
Jim Highsmith vient de publier un billet avec une idée qui m’a beaucoup plu The ‘’to do less’’ List, qu’il reprend des fondateurs de 37 signals.
Penser plus, faire moins : par tempérament, j’ai déjà tendance à suivre naturellement cette idée. De plus en plus au fil des années.
Séminaire 'L'agilité : du projet au programme et à la ligne de produits'
IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits
J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée.
Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Le jeu de la valeur métier
Ah, la valeur !
Il y a un peu plus d’un an, je me disais dans ce billet sur la valeur que j’allais essayer le Business Value Game. C’est seulement hier que j’ai eu l’occasion d’approfondir cette simulation. Nous étions quelques uns de la SigmaT à nous retrouver dans notre local de la maison des associations.
Changer les priorités dans le backlog
Un backlog de produit à prioriser, du concret pour le Product Owner.
Le backlog de produit est l’outil du Product Owner. Il le triture, le malaxe, pour qu’il soit toujours utile et à jour. A jour, cela implique notamment que les éléments du backlog sont ordonnés par priorité.
Un Product Owner est amené à changer l’ordre de priorité pour différentes raisons :
Eléments du backlog : Features, stories et spikes revisités
Que met-on dans le backlog ?
L’an dernier, j’avais fait un billet sur les features, stories, epics.
Aujourd’hui je revisite ces notions à l’occasion d’évolutions dans IceScrum, qui les embarque actuellement de façon pas très limpide. Pour simplifier l’usage, nous allons fusionner les notions de thèmes et de features, et nous appuyer sur des idées de Dean Leffingwell et Philippe Kruchten.
Zorro est revenu
La valeur et le coût, c'est pas pareil
Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s’y perd entre les notions de valeur, d’effort et de coût.
J’essaie d’éclaircir.
Le burndown chart montre l’effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit.
Quelle valeur pour la valeur ?
Pas facile de donner une valeur à la valeur ajoutée par une user story…
Dans la toute première version d’IceScrum (2005), il y avait un attribut associé aux éléments du backlog de produit, qui s’appelait valeur. Je l’avais demandé parce que c’est un précepte de Scrum et des méthodes agiles que de définir la priorité en fonction de la valeur. Plus la valeur est grande, plus la priorité est importante et la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés.