Qui essayez-vous d'impressionner avec vos délais?

Astuce: évidemment pas vos utilisateurs.

Levez la main à ceux dont l'entreprise a proclamé «l'orientation client» comme l'une de ses valeurs d'entreprise. Pour ceux d'entre vous qui ont lu ce texte sur Habré et qui ne voient pas le public: presque toute la salle a levé la main, à l'exception de quelques personnes de derrière.

Ils travaillent chez Oracle.

La satisfaction du client est l'une des valeurs d'entreprise d'Oracle. Mais les valeurs de l'entreprise - elles sont comme un abonnement au gym - ce n'est pas suffisant de les avoir.

L'obsession du client est une chose utile, mais il y a encore une chose qui obsède de nombreuses entreprises: le timing. Les délais sont bons. «Il sera prêt quand j'aurai fini» peut être une excellente stratégie (ou même recommandée) pour deux personnes travaillant sur la même application. Mais lorsque vous travaillez dans une entreprise de plus de deux cents employés, vous devez comprendre ce qui se passe; une idée approximative du moment où vos utilisateurs pourront utiliser vos nouveaux sifflets et pets.

J'ose dire que les délais fixes sont de mauvais délais, et si votre entreprise en a, vous devriez probablement aller encore plus loin et supprimer l'élément «orientation client» de la liste des valeurs de l'entreprise. Parce que, croyez-le ou non, les utilisateurs ne se soucient pas des sprints jonchés.

Les délais sont principalement nécessaires non pas aux clients, mais à la direction.

Le but principal est le but

Ou pourquoi geler les exigences de sprint est une terrible pratique

Le timing est bon, ils créent un sentiment d'urgence, assurent la prévisibilité de vos processus, et donc vous devriez les avoir.

Mais il y a de bons et de mauvais termes. Et il y a des entreprises dans lesquelles les délais sont fixés dans la pierre, et ceux qui remplissent les délais à un pas du licenciement. Et puis les problèmes commencent.

Je parle d'une culture de développement dans laquelle il est de coutume de geler les objectifs pendant le sprint: quand tout le monde se rassemble au tout début, ils évaluent les tâches, certainement en utilisant uniquement les chiffres de Fibonacci, et quoi que ce soit qui serait décidé lors de ces réunions, tout cela devrait être fait avant la fin sprint - rien ne change et n'est pas toléré. En théorie, cela semble génial, mais je pense qu'une telle tactique perd dans n'importe quel scénario:

Situation A. Supposons qu'un développeur surmonte la loi de Parkinson et ferme ses tâches à l'avance. Dans ce cas, soit le développeur ne le signale pas lors du stand-up du lendemain matin, car bon, eh bien, il ne peut pas dire qu'il n'a rien à faire. Ou son manager lui confie plus de tâches en gelant le sprint, car bon, il ne peut pas avoir de développeur qui ne fait rien .

Situation B. Le développeur, étant un développeur, est en retard sur le calendrier. Les problèmes de mise en place de l'environnement ont pris plus de temps que prévu et il n'est plus sûr d'avoir le temps de tout faire avant la fin de la semaine.

Ce qu'il rapporte à la prochaine réunion, à laquelle le chef de projet répond: «D'accord, je vous ai entendu. Mais nous nous sommes engagés, alors pouvez-vous essayer de tout terminer à temps? » Dans le même temps, la tête du manager scanne une image de la façon dont il doit expliquer le retard de la libération lors de la synchronisation hebdomadaire au vice-président de la société de développement, qui, à son tour, lui donne le conseil instructif "Just do it" , il est donc préférable de simplement filtrer et essayer de faire.

Ainsi, le développeur, en tant que développeur, part pour quelques nuits, ou peut-être un week-end, et termine le travail à temps. Et son manager apprécie ses efforts lors du prochain rallye. Affaires quelque chose.

Ou n'est-ce pas si lisse? Les délais ont été respectés et le travail a été mené à bien, mais un mauvais précédent a été créé. Un étudiant récemment embauché aux yeux exorbités a reçu le signal que le traitement le week-end était correct .

Et nous ne discuterons même pas du triste scénario lorsque le délai n'est pas respecté, la tâche va au prochain sprint, et le manager doit justifier le retard lors de sa prochaine synchronisation hebdomadaire devant le vice-président du développement et écouter les conseils moraux.

Voyez-vous un problème? À aucun moment, personne n’a posé la question: «Écoutez, que se passe-t-il si nous la déplaçons au prochain sprint et n’excusons personne? Comment cela affectera-t-il les utilisateurs? "

Beaucoup plus souvent qu'elle ne devrait l'être, les délais sont l'auto-hypnose. Et comment y faire face - aussi.

La solution idéale serait de simplement parler aux parties intéressées - l'équipe de produit ou l'équipe de vente, en cherchant à savoir si le retard pourrait entraîner la perte du client. Et si c'est le cas, alors allouez définitivement des heures supplémentaires, et il est possible de travailler le week-end. Dans ce cas, le jeune étudiant recevrait un signal que l'entreprise se soucie vraiment de ses clients, et non de ses sprints.

Il y a un autre problème avec le gel des sprints. Supposons que vous ayez reçu une demande d'un client –– pour corriger un bogue potentiellement trivial et de faible priorité. Le développeur y fera face en une journée. Mais vous suivez le processus de ^MT , ce qui signifie que la tâche est ajoutée au backlog de votre équipe et peut-être qu'elle sera mémorisée après quelques mois. Mais vous avez perdu l'occasion de faire plaisir à l'utilisateur! Vous pouvez résoudre ce problème en quelques jours et informer l'utilisateur par e-mail que son problème a été résolu. Les gens se souviennent de tels moments, et ce sont des choses qui les font recommander votre produit à leurs amis.

Ne vous laissez pas trop emporter par les processus - à cause d'eux, vous pouvez manquer votre objectif. ¹

Je crois également que le gel des sprints ou toute autre pratique restrictive est un signe de la méfiance mutuelle inhérente à l'entreprise, en raison de problèmes plus fondamentaux au niveau de la culture de la communication, mais plus à ce sujet la prochaine fois.

Pourquoi les délais sont-ils terribles

1. Ils créent de fausses attentes, contrairement à ce qui est écrit dans vos valeurs d'entreprise. Parce que vos valeurs d'entreprise ne sont pas vos valeurs, vos vraies valeurs sont des attentes et des préjugés non écrits (bons et mauvais).
2. Les gens vont rogner si vous les mettez dans des conditions difficiles. Quelqu'un marquera pour le test, quelqu'un ne mettra pas à jour la documentation. Vous expédiez la version à temps, mais à quel prix?
3. Personne n'accepte de passer du temps à chercher de nouvelles solutions pendant que les gestionnaires prient pour les tâches terminées à temps. Tout le monde écrira le front-end sur les frameworks MVC jusqu'à ce que quelqu'un sur Facebook franchisse un certain délai.

Alors, travaillez sans délais?

Bien sûr que non. Fixez des délais, mais rendez-les flexibles. La flexibilité de vos délais est votre objectif. Si le non-respect du délai pouvait entraîner la perte d'un million de dollars, votre flexibilité devrait être nulle. Mais s'il s'agit d'une autre caractéristique, il y a toujours une marge de manœuvre. Vous pouvez également expérimenter des méthodes probabilistes plus complexes pour estimer les dates, au lieu de jouer des nombres de Fibonacci avec votre doigt dans le ciel. ²

Mais le gel des sprints est une décision médiocre.

^1. Jeff Bezos a bien parlé de ce sujet dans une lettre aux actionnaires en 2016 . Il a conseillé de «résister aux procurations entre les personnes au sein de l'entreprise».

^2. Joel Spolsky parle de méthodes avancées pour estimer les délais dans son article «Evidence Based Scheduling» ( traduction en Habré ).