Le paradoxe de l’efficacité

Dans la vie, quand on travaille dur, on atteint ses objectifs.

Je suis certain que plusieurs ont entendu cette phrase à maintes reprises. C’est pourquoi il est de bonne pratique de s’assurer dans notre entreprise que tous les employés travaillent dur. Après tout, ils ne sont pas payés pour ne rien faire, n’est-ce pas?

Vous devriez donc vous assurer de maximiser leur occupation. Un employé qui est disponible est un employé qui ne travaille pas.

Chaque employé devrait travailler sur plusieurs choses à la fois. Comme ça, quand un item bloque, il peut faire autre chose sans attendre.

On devrait utiliser seulement des spécialistes compétents pour accomplir les tâches afin de réduire les coûts.

Il devrait y avoir une pile de travail à faire sur chaque bureau afin que personne ne soit en attente de travail.

Les objectifs individuels devraient être liés au fait d’être constamment en train de travailler. Le salaire et les bonus devraient être proportionnels à la quantité de travail accompli.

Est-ce que tout cela fait du sens pour vous?

Si vous n’avez pas de clients, c’est probablement la bonne approche.

WAIT-WHAT-meme-289

Ici réside le paradoxe de l’efficacité. Malheureusement, à favoriser l’efficacité de l’utilisation de vos individus, vous heurtez de façon considérable votre prestation de service et par la même occasion, la satisfaction de vos clients.

Lire la suite

Planifiez-vous pour gagner ou pour ne pas perdre?

low-bar

(English follows)

Imaginez que, en tant que membre d’une équipe Agile, vous tentez quelque chose de nouveau afin d’augmenter la qualité de votre produit et que ça ne fonctionne pas. Qu’est-ce qui fait le plus mal? Devoir re-planifier et essayer de nouveau ou devoir rendre des compte sur cet échec?

Imaginez maintenant que vous, toujours en tant que membre d’une équipe Agile, devez faire des choix difficiles dans la gestion de votre temps suite à des imprévues ayant décuplé la grosseur de l’une de vos tâches. Qu’est-ce que vous regretteriez le plus? Ne pas pouvoir augmenter la qualité du produit ou avoir manqué votre estimation?

Voyez-vous où nous allons avec ceci?

Lire la suite

Estimer, oui mais comment?

Que ce soit lors d’un sprint planning ou dans une réponse d’appel d’offre, l’estimation est essentielle. Peu importe l’unité (t-shirt size, story point, temps en heures, $$$, j/p, etc.), les experts sont appelés à estimer presque quotidiennement. Mais une question demeure: comment mesurer la fiabilité de l’estimation produite par un expert? Est-ce qu’un sénior dans un domaine en fait automatiquement un expert en estimation?

Certains diront qu’il est impossible d’obtenir une évaluation d’une précision acceptable en TI en raison de la trop grande variabilité du domaine (#NoEstimates). Contrairement à la construction, on ne peut mesurer la surface à couvrir et s’appuyer sur des chantiers similaires pour en extrapoler les coûts. Malgré tout, je ne crois pas que la tâche soit impossible.

L’estimateur est un outil de mesure

L’expert estimateur est un outil de mesure au même titre qu’un pèse-personne ou qu’un ruban à mesurer. On s’attend donc à ce qu’il soit précis et exact. Généralement, lorsqu’on demande à l’expert d’estimer, on favorise un seul de ces points puisqu’on lui demande un nombre unique. Il devient alors impossible de déterminer si l’estimé est exact (peu de risque de dépassement) ou précis (proche de l’effort réel).

Lire la suite

Attention au glissement du risque

(english follows)

En gestion de projet, atteindre la prédictibilité est un élément clé du succès et son bloquant majeur est le risque. Pour contenir ce dernier lors de la préparation d’un projet, nous prenons grand soin de gérer la quantité de risque inclue dans la portée. En ne voulant rien laisser au hasard, nous augmentons ainsi nos chances de succès en travaillant sur ce risque en début de projet. Lorsque que le risque est résolu ou sous contrôle, nous pouvons enfin tourner notre attention vers la prédictibilité.

N’est-ce pas bizarre alors de voir des ajouts volontaires de risques supplémentaires pendant le projet?

Ceci peut s’expliquer via un comportement de compensation du risque poussant les gens à faire moins attention lorsqu’ils se sentent en sécurité. Cet effet, combiné avec la pression de livrer un maximum de fonctionnalités de qualités, peut nous pousser à prendre des risques supplémentaires en remplacement de ceux qui sont résolus. J’appelle ceci “remplir sa dette de risque”, étant donné que les membres de l’équipe agissant de cette façon sont similaires aux gens qui utilisent leur crédit de façon impulsive. Au même moment, pour certains membres du projet, une baisse de pression sur le risque peut être interprétée comme un signe de perte d’opportunité. Pour résoudre ceci, on doit se concentrer à maintenir un effort constant et soutenable, alors qu’au même moment, on doit accepter une oscillation dans le niveau de risque alors que le focus fait des allers-retours entre le développement et le déploiement.

Le risque est sournois, car il fait toujours partie du développement logiciel, nous désensibilisant ainsi de sa présence et de son importance et aussi parce qu’il prend deux formes : le risque connu, qui peut faire partie de la planification, et les risques inconnus, qui nous surprendront sur le chemin. Plusieurs de ces risques inconnus seront bloquants, nous forçant ainsi à investir un temps précieux pour les résoudre alors que, et nous devrions prendre avantage de ce fait, nous avons le choix d’accepter, gérer ou, plus particulièrement, rejeter les risques connus.

Livrer la vision en résolvant les risques engagés devrait donc toujours surpasser l’ajout de risque additionnel.

Phillipe Cantin

Beware of Risk Creep

When managing a project, achieving predictability is a key element of success and one of its major impediments is risk. To curb this problem while preparing for a project, we take great care, managing the amount of risk accepted in the scope. Not willing to leave anything to chance, we further improve our odds by tackling this risk early in the project which, once removed or under control, clears the way for predictability.

How funny then, to see new risks being purposefully added during a project production.

One reason explaining this is the Risk Compensation behavior, when people tend to be “less careful if they feel more protected”. This effect, combined with the pressure to deliver a maximum of quality features, can drive us to take on new risks as the existing risk is removed. I call this “Maxing out the risk” since team members acting this way are similar to people feeling compelled to max out their credit. At the same moment, for some people, a drop of pressure on risk can be interpreted as a sign of lost opportunity. To resolve all this, we must concentrate on maintaining a constant and sustainable effort level while, at the same time, accepting an oscillation in the risk level as the focus goes back and forth between development and release.

Risk is a sneaky thing as it is always a part of software development, desensitising us to its presence and importance. It is also sneaky as it comes in two shapes: the known risks, which can be part of the planning, and the unknown risks, which will surprise us along the way. We don’t have a choice but to deal with the unknowns [risks] as they pop up here and there during the project, and we should take advantage of this fact. We have a choice to either accept, manage or, especially, reject known risks.

Shipping the vision while resolving the engaged risks should always trump the addition of new risk.

Phillipe Cantin