Scrum, le guide pour 2015

Après les pratiques Scrum que je considère comme obsolètes dans la plupart des contextes, voici une liste de pratiques émergentes que je vous encourage à essayer en 2015 si ce n'est pas encore fait.

Pratiques obsolètes

  • Burndown chart de sprint
  • Estimations pendant la planification de sprint
  • Revue pour le Product Owner
  • Rétro et revue mélangées
  • Écrire les stories
  • Estimation des tâches en heures
  • Excel pour le backlog
  • Planification de sprint en 2 parties
  • Des slides sur l’avancement à la revue
  • Une colonne à tester sur le tableau des tâches

Pour en savoir plus, relire ce billet et celui-ci.

Pratiques à essayer

Audience 2014

J'aime bien avoir un objectif sur quelque chose qui se mesure.

Lire la suite...

Rupture douce, saison 3

Lire la suite...

Bac d'affinage et plan de release

Diagramme de bacs empilés

Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage.

Lire la suite...

Les événements du sprint

Les événements du sprint

Bien sûr, il faut ajouter un événement à ceux de ce schéma : le scrum quotidien.

Lire la suite...

Epics et Stories

Epic et story dans le bac d'affinage

Lire la suite...

La purge du backlog

Rejet à partir des bacs

Lire la suite...

Les participants à l’affinage de backlog

L'affinage consiste, à partir de l'idée brute, à rendre une story prête à être réalisée en un sprint.

La vie de la story

Lire la suite...

Les travaux d'affinage du backlog

Affinage avec les bacs

Lire la suite...

Les promesses de l'Agilité

On vous avait promis plein de bienfaits quand vous êtes passés à l’Agilité et en regardant vos résultats, vous n’en voyez qu’une partie ? On vous aurait menti ?

Posez-vous la question de la maitrise que vous avez acquise :

Le modèle Agile Fluency

Lire la suite...

L’Agilité en mouvement

Vue d'Alesund depuis le CessnaJ'ai la chance de faire partie de la communauté Agile et discuter fréquemment avec ses membres éminents.

J'ai aussi le grand plaisir de faire des formations et des prestations d'accompagnement en binômes avec certains d'entre eux.

Nous avons des parcours différents, cependant nous avons tous trempé dans le développement de logiciel, plus ou moins selon les sensibilités. Et nous nous sommes retrouvés dans le mouvement agile, certains plus récemment que d'autres, mais tous avec le même enthousiasme pour mettre en œuvre les pratiques agiles tout en partageant les mêmes valeurs et principes.

Après plusieurs années d'expérimentations, on peut dire que les méthodes agiles ont changé la vie de beaucoup d'équipes et apporté de beaux succès aux organisations qui ont entrepris la transition agile.

Cependant, au fur et à mesure que cette diffusion s'accomplissait plutôt bien sur le terrain, de nouveaux problèmes sont apparus.

Lire la suite...

Quand faire l’affinage du backlog ?

When to refine the backlog?

Lire la suite...

D'autres pratiques Scrum obsolètes

Péniche et platanes du canal du Midi

Lire la suite...

Affinage de bac en bac

Des petits bacs plutôt qu'un gros backlog, l'idée a maintenant fait son chemin. C'est plus facile pour l'affinage.

Lire la suite...

Affiner c’est mieux que groumer

Vendredi toute la journée, mes interlocuteurs ont parlé de grooming.

Lire la suite...

La rétrochâtaigne

Les 3C du Raid AgileAu cours du Raid Agile, nous avons essayé une nouvelle technique de rétrospective.

A la demande générale -il y en a même eu venant de l'étranger, je vous explique dans ce billet comment animer une rétrochâtaigne.

Lire la suite...

Pratiques Scrum obsolètes

[deprecated]

Lire la suite...

Hypothèses validées, annonce du Raid Agile #2

Le Raid Agile, on y est venu pour son saucisson et la charcuterie cévenole mais on a aussi apprécié ses gâteaux, dont le fameux Mont Aigoual :

Le Mont Aigoual, une tuerie !

Lire la suite...

Chapitre dix-huit

Le chapitre 18 de mon livre s'appelle La transition à Scrum. Les chapitres précédents ont traité de la mise en place de Scrum au niveau d'une équipe. Celui-ci évoque les impacts au niveau de l'organisation.

Le sujet "Scaling Agile" est devenu à la mode, c'était par exemple le thème de l'Agile tour Montpellier. C'est devenu un sujet fourre-tout, qui regroupe des préoccupations bien différentes. Dans mon livre, j'ai choisi de différencier l'Agilité à grande échelle pour des gros projets, qui fait l'objet du chapitre 19, de l'Agilité au niveau des organisations, ce chapitre.

Pour mes lecteurs, voici le supplément en ligne au chapitre 18.

Lire la suite...

Discussion à propos de #noEstimates

Lors de la deuxième journée de l'Agile tour Toulouse, le sujet #noEstimates que j'avais proposé a été retenu pour le premier run de l'Open Space. Nous étions un groupe de 6 ou 7 à en discuter. Le sujet ayant de nombreuses implications, la demi-heure que nous y avons consacrée est passée très vite.

Nous avons tous souhaité continuer cette discussion. Nous avions d'abord envisagé de le faire l'après-midi, toujours pendant l'Open Space. Finalement nous sommes partis sur d'autres sujets.

Nous proposons de reprendre la conversation avec Agile Toulouse. Un framadate est en cours pour trouver le meilleur moment. Quelqu'un qui n'était pas à la première conversation est le bienvenu si le sujet l'intéresse.

Petit résumé de ce qu'est #NoEstimates

Contrairement à ce qu'on pourrait croire, le mouvement #NoEstimates ne milite pas pour la suppression de toutes les estimations. Il s'agit d'un retour aux principes de l'agilité.

  • D'abord en faisant prendre conscience que les estimations dans le développement logiciel demandent pas mal d'effort et apportent finalement peu de valeur.
  • Ensuite en proposant des façons de prévoir, pour pouvoir prendre des décisions, qui ne demandent pas d'estimation.
  • Enfin en mettant l'accent sur ce qui est le plus important, les impacts qu'aura le logiciel plutôt que combien il va coûter.

A lire : l'origine du hashtag #NoEstimates

Pourquoi je m'intéresse à #NoEstimates

  • Parce que je suis persuadé qu'on peut souvent se passer d'estimations ; j'ai fait des années de développement de logiciel, en tant que développeur ou chef de projet, sans faire d'estimations (en H*j) et ça n'a jamais manqué.
  • Car je constate des dérives dans l'usage des estimations en points et de la vélocité dans les organisations. Il est possible de faire mieux en faisant autrement, en particulier quand le développement est soumis à un contrat.

- page 1 de 57