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.

Les gens veulent toujours plus, les utilisateurs en particulier. Je le vois de façon très concrète avec iceScrum, dont je suis le Product Owner. Il y a plus en plus de demandes pour faire évoluer le produit. Ce feedback est très positif et permis de faire évoluer très favorablement la R3 depuis octobre 2010. Cependant, il y a aussi dans ces retours des utilisateurs des demandes qui partent dans tous les sens. On ne peut pas dire oui à tout.

En tant que PO, je résiste plutôt bien à toutes celles qui sortent de l'esprit initial, qui est de faire un outil agile. Je résiste d'autant plus facilement que c'est un logiciel open source fait par une communauté dans les ressources sont limitées, cela pousse à avoir des priorités.

Cependant, je garde du billet d'Highsmith l'idée d'avoir une liste explicite des choses à ne pas faire.

Voici une première version de cette liste pour iceScrum :

  • collecter le temps passé sur les tâches (tout ce qui concerne le timetracking),
  • permettre au ScrumMaster d'affecter le travail aux membres de l'équipe,
  • permettre aux utilisateurs de rajouter autant de colonnes qu'ils veulent dans le tableau des tâches.

Finalement c'est plus une nottodo liste qu'une to do less liste.

Commentaires

1. Le vendredi 03 juin 2011, 09:23 par windu.2b

Si je comprends parfaitement la présence des 2 premiers points de cette nottodo list, car ils vont à l'encontre de la "philosophie" de Scrum, je ne vois pas ce qui justifie forcément la présence du 3° ?

2. Le vendredi 03 juin 2011, 18:04 par François michas

Je suis toujours perturbé par cet affirmation de "suivre le temps passé ne sert à rien". Ce n'est pas une fin en soi mais matérialiser la dérive est important.
Le focus sur le reste à faire peut vite faire oublier que des obstacles ont pu être rencontrés.
On peut se dispenser de suivre le consommé par "symétrie" du reste à faire : si le reste à faire est constant d'une journée sur l'autre ou qu'il augmente alors il y a une surconsommation ... ou erreur d'estimation ... ou un imprévu qui fait que l'on a rien fait du tout.
Négliger l'information de cet écart entre prévision et réalisé (après on prend le reste à faire ou le consommé) serait se priver d'une source d'apprentissage. Comme les raisons de la dérive sont encore fraîches, il est intéressant dans une perspective d'amélioration continue de tracer le problème et au passage, si possible, sa cause première (probablement un job pour le scrummaster durant et après le daily meeting).
Au scrummaster de juger des actions à mener, éventuellement lors de la rétrospective, ou plus tôt pour s'assurer que le problème rencontré ne se reproduise pas. L'impediment list peut recenser tous les problèmes rencontrés et s'assurer qu'ils sont définitveemnt résolus.
Donc ne pas suivre le consommé pourquoi pas, mais il faut tirer les leçons des dérives. Non ?

3. Le samedi 04 juin 2011, 01:37 par Oaz

Pour ma part, je ne listerais pas la collecte du temps passé.
Pourtant, il y a 2 ans, j'aurais été persuadé que c'était une chose à ne pas faire -comme quoi on évolue et la liste des choses à ne pas faire devrait probablement mériter des révisions au fil du temps.
Mais, contrairement au commentaire de François, mes raisons concernant cette collecte du temps n'ont rien à voir avec la "dérive" entre estimation et mesure qui est une notion non agile pour rester poli.
En fait, je suis de plus en plus persuadé que la clef est d'arrêter les estimations et de ne faire QUE des mesures. La vélocité est une mesure mais elle implique des estimations. On doit pouvoir faire mieux.

@windu,
la raison d'être du 3ème point est la maitrise des "stocks". + de colonnes signifie souvent + de taches spécialisées, globalement + de "work in progress" et, au final, la perte de vue de l'essentiel. Il ne faut pas gérer des stocks de fonctionnalités en cours de réalisation. Il faut livrer des fonctionnalités à l'utilisateur.

4. Le lundi 06 juin 2011, 14:44 par claude

@windu Oaz a répondu avant moi.

@françois L'analyse des déviations est au cœur de l'empirisme, qui se pratique tous les jours lors de la réunion quotidienne et tous les sprints. Mais pas besoin de collecter le temps passé individuellement sur des tâches pour cela.

@Oaz Arrêter les estimations, est-ce que ça ne revient pas à compter les tâches (ou les stories) ?

5. Le lundi 06 juin 2011, 16:15 par JA

Il y a cette liste des choses à ne pas ajouter dans le produit.
On peut aussi imaginer la liste des fonctionnalités à retirer dans l'existant pour garder le produit simple à utiliser et à maintenir.
Donc à chaque demande pour ajouter, joindre aussi une suggestion pour retrancher. Certes, mécanisme pas très utile au début de la vie du produit, mais peut être un peu plus utile après.

6. Le lundi 06 juin 2011, 21:33 par Oaz

@claude,
En partie, oui. Pour mesurer, il faut compter (les taches, les stories, ...) mais ce n'est peut être pas suffisant.
Est-ce que l'on ne pourrait pas obtenir de meilleures prévisions en mesurant, par exemple, le temps écoulé entre le début et la fin de chaque story ?
Je n'ai pas d'élément pour l'affirmer ou l'infirmer. C'est juste une idée.

Plus généralement, j'ai l'impression que le développement logiciel manque encore de méthodes éprouvées de collecte de données par rapport à ce que l'on peut trouver dans le manufacturing.