Using Fibonacci suit to estimate is cool, but nearly ununderstandable for anyone used to estimate in hours. How many times have we heard: « Ok, so, one point is one hour, right? » ? Ok, estimation based on complexity or effort is not intuitive. Can we use some tool to make a strict distinction between hours based estimation and complexity based estimation? Well, let’s try with the Cynefin framework, designed by Dave Snowden.
Catégorie : Agility
-
How to estimate a backlog with hundreds of items?
Estimation meetings have always been time-consuming. To avoid useless discussions, Agilists are using Planning Poker game, which reduces technical conversations, and instead increases focus on what estimations are: « wild guesses ».
But using Planning Poker to estimate a backlog, filled with hundreds of items, will still take time. So, how can you estimate faster? Well… By pushing further, and by removing all useless discussions: formally during a Planning Poker game the PO has to present each item one by one, even if all team members will immediately agree on effort. Can we throw that away? Well… Yes, indeed…
-
Lorsqu’aider devient nocif.
Vous ou un des membres de votre équipe avez l’impression d’être enfermé dans un rôle, qu’on vous a collé injustement une étiquette, que quoique vous puissiez dire, systématiquement, personne ne fait rien, rien ne change, tout s’effondre tout le temps?
(J’insiste sur le côté répétitif et systématique de la situation. Il n’est pas question ici de situations de désaccord anecdotiques, mais bien d’un type d’interaction clairement établi et ancré.)
Il est possible que cette impression ne soit pas complètement fausse, mais que la première personne qui puisse changer la donne soit également vous-même. Il est possible que vous vous sentiez Sauveur de toute situation, ou Victime, ou potentiellement parfois Persécuteur. Il est possible que ces différentes positions alternent. Autant le dire simplement: si vous pensez être dans ce genre de situation, il n’est pas bon d’y rester. Il est possible qu’il s’agisse du triangle dramatique…
-
Lean Canvas: comment le définir?
J’avais été impressionné par l’outil, lors des ScrumDays 2014. En quelques minutes, l’orateur a réussi à accompagner un entrepreneur inconnu dans la définition de son produit, certes superficiellement, mais sous tous ses aspects: vision, coûts, risques, cibles, …
-
Dépasser le modèle Scrum pour une équipe DevOps transverse: ShuHaRi
Lors du keynote des ScrumDays 2014, Alistair Cockburn s’intéresse à l’évolution de l’Agile, du manifeste à aujourd’hui. Il fait mention notamment d’une notion dont je ne connaissais pas le nom: Shuhari. D’abord apprendre, ensuite se détacher, finalement transcender. Concept qu’il intègre à sa manière d’être un professionnel agile, et auquel on se retrouve parfois confronté de manière fortuite.
Extrait de la page wikipedia:
Shuhari est un concept issu des arts martiaux japonais qui décrit les 3 étapes de l’apprentissage. Il est parfois appliqué à d’autres disciplines comme le jeu de go.
ShuHaRi peut se traduire par suivre les règles, comprendre les règles et transcender les règles.
- Shu (守:しゅ, « protéger », « obéïr ») — sagesse traditionnelle – apprendre les fondamentaux
- Ha (破:は, « se détacher », « digresser ») — casser avec la tradition — trouver les exceptions à la sagesse traditionnelle, trouver de nouvelles approches
- Ri (離:り, « quitter », « se séparer ») — transcender — il n’y a pas de technique ou de sagesse traditionnelle, tous les mouvements sont permis.
-
La chasse aux préjugés
Voici une présentation donnée à une équipe concernant les pré-jugés.
C’est une paraphrase d’une partie de l’excellent livre d’Hervé Gougeon (Un bourdon sur les chemins de la réussite) que je ne saurais trop conseillé à quiconque souhaitant aborder ses problématiques sereinement, et augmenter ses chances de succès.
Source: Un bourdon sur les chemins de la réussite).
[googleapps domain= »docs » dir= »presentation/d/1A5qRuUa2XRu-hpCbj-Isq2iCp9nyHo3qWEKAvmrCIAI/embed » query= »start=true&loop=false&delayms=3000″ width= »800″ height= »624″ /]
-
Savoir quand prendre ses distances…
Le rôle de Scrum Master est un paradoxe, dans une société où on nous apprend qu’il faut savoir se rendre indispensable pour protéger son poste, ou du moins qu’il faut tout faire pour ne pas devenir inutile.
C’est le principe, l’idée, l’essence même du Scrum Master: un jour où l’autre, soit nous avons réussi à rendre notre équipe autonome – et elle n’a plus besoin de nous pour pouvoir s’introspecter dans le cadre d’une amélioration continue – soit la situation dépasse nos compétences / capacités.
-
Les premiers pas vers une culture Produit: Personas.
La « Culture Produit » est axée vers ce que l’on vise, contrairement à la culture projet qui s’intéresse la manière dont on organise une mise en oeuvre. Cette notion est centrale dans toutes les méthodes Agile que nous croisons ces dernières années. Bien que nous en entendons parler que depuis peu de temps en France, cette approche de la production (quelque soit le domaine) est en exercice depuis plusieurs décennies dans d’autres pays, notamment outre-atlantique.
Créer de la valeur pour l’utilisateur et non se focaliser sur la gestion d’un projet prédéfini au détriment de l’expérience de nos clients.
-
Garder la foi, quelles que soient les difficultés.
Scrum Master, Coach Agile, sont deux rôles que l’on qualifie souvent de « servant leader ». C’est un joli mot qui peut faire un peu rêver. L’altruisme dans le monde du travail est quelque chose de précieux, de magnifique, et cetera… Sauf que cela peut parfois épuiser, et garder sa propre motivation, à la longue, n’est pas forcément évident.
-
Relancer la motivation et l’implication d’une équipe Scrum
Tout scrum master ayant quelques sprints d’expérience s’est déjà confronté à un problème plus ou moins profond de motivation, ou d’implication de son équipe. Que ce soit de la part des développeurs ou du PO, il arrive que des tâches répétitives, malgré une habituelle bonne entente entre les différentes personnes, finissent par casser la motivation. Non, mettre en place les réunions et le rituel du Scrum, les itérations et rétrospectives ne suffisent pas en soi à pallier à cette difficulté.