Parcourez tous les articles dans cette catégorie
Linear et Sinra utilisent tous les deux le mot cycle. Ce n'est pas un hasard : les deux outils rejettent le vocabulaire Scrum classique. Mais au-delà du vocabulaire, leur périmètre diverge nettement.
Monday.com permet de tout construire : c'est sa force marketing et sa faiblesse pratique. Une équipe de développement qui adopte Monday.com passe ses premières semaines à définir, par elle-même, ce qu'un outil dédié offre par défaut.
Asana est un excellent outil de gestion de tâches, utilisé par des équipes marketing, RH et opérations aussi bien que par des équipes produit. Cette polyvalence a un prix quand il s'agit de suivre des releases logicielles précises.
Passer une demi-journée à configurer des workflows Jira avant même d'avoir créé un seul ticket : beaucoup de petites équipes vivent ce moment et se demandent si l'outil est vraiment fait pour elles. Voici ce qui coince et ce qu'il faut chercher à la place.
Un CTO qui code encore à temps plein n'a pas encore compris son poste. Le vrai travail consiste à absorber la pression du business pour que les équipes techniques puissent construire correctement, et à porter seul les décisions qui tournent mal.
Un Lead Developer qui code toute la journée n'est pas un lead, c'est un développeur avec un titre en plus. Le vrai travail est ailleurs : dans les décisions qu'on prend pour que d'autres puissent bien faire les leurs. Et ça commence par accepter de disparaître un peu.
Le projet a une date de début, une date de fin, et un périmètre. Quand c'est livré, c'est terminé. Le produit, lui, n'a pas de fin. Il évolue, il s'améliore, il répond à des besoins qui changent. Ces deux façons de travailler ne sont pas compatibles - et confondre l'une avec l'autre coûte cher.
Il est 14h. Tu viens de rentrer dans un état de concentration profonde. Ton ticket avance. Et là : une invitation de réunion pour dans dix minutes. « Rapide sync sur le sujet X. » Cette réunion aurait pu être un message.
Le ticket passe en « Done ». Tout le monde passe à la suite. Trois semaines plus tard, on découvre que la fonctionnalité n'a jamais été déployée en production, que les tests d'intégration n'ont pas été mis à jour, et que personne n'a de monitoring en place. Elle était finie, vraiment ?
Votre équipe livre 40 story points par sprint. Le backlog avance. Les tickets se ferment. Et pourtant, les utilisateurs attendent des features depuis six mois. Quelque chose ne tourne pas rond. Le problème : vous mesurez l'activité, pas la livraison de valeur.
Il est 9h30. L'équipe est réunie. Chacun à son tour répond aux trois questions : « Qu'est-ce que j'ai fait hier, qu'est-ce que je fais aujourd'hui, quels sont mes blocages. » Quinze minutes plus tard, tout le monde repart à son écran sans que rien n'ait changé. Ce daily n'a servi à rien.
Votre organisation a implémenté SAFe. Vous avez maintenant des ARTs, des PI Plannings, des System Demos et des Inspect & Adapt workshops. Votre organisation est également plus lente, plus réunionnée et plus frustrante pour les ingénieurs qu'avant. Ce n'est pas un bug de votre implémentation SAFe. C'est souvent une caractéristique.
L'estimation est souvent une fiction partagée : les développeurs donnent des chiffres qu'ils savent imprécis, le management les prend comme des engagements, et quand les estimations sont dépassées, tout le monde est surpris d'être surpris. #NoEstimates dit : arrêtons la fiction. La question est : par quoi on la remplace ?
« On a besoin d'un sprint de dette technique. » Cette phrase est prononcée dans des centaines d'équipes chaque trimestre. Ce qui se passe ensuite : deux semaines de refactorisation sans direction claire, dont la valeur est impossible à communiquer au management, et qui ne change pas fondamentalement les problèmes les plus douloureux.
Combien de fois avez-vous eu un 1-on-1 où votre manager a ouvert Jira pour passer en revue vos tickets en cours ? Cette réunion aurait pu être un email, ou une consultation de tableau Kanban. Le 1-on-1 qui ressemble à un rapport de statut est un 1-on-1 gâché.
Votre équipe a une page Notion avec le plan du prochain trimestre. Elle a été rédigée la semaine dernière. Trois personnes ont ajouté des commentaires. Deux ont mis un emoji. Le plan n'a pas changé. Personne n'a pris de décision. C'est l'async sans contrôle : beaucoup d'activité, peu de résolution.
Quand est-ce qu'une epic est terminée ? La question devrait avoir une réponse simple. En pratique, dans la plupart des équipes, c'est une longue conversation. L'epic grandit, se divise, se réouvre, migre d'un sprint à l'autre. Ce n'est pas un problème d'implémentation Scrum. C'est un problème de définition.
« Notre velocity est de 42 points par sprint. » Cette phrase est prononcée avec fierté dans des centaines de réunions de planification chaque semaine. Elle dit quoi, exactement ? Que l'équipe ferme des tickets à un rythme cohérent. Ce qu'elle ne dit pas : si ces tickets créent de la valeur, si les estimations sont réalistes, si l'équipe est épanouie.
Combien de fois avez-vous vu une release se transformer en fourre-tout de fonctionnalités semi-terminées, de corrections de dernière minute et de tickets migrés depuis trois sprints précédents ? La release a perdu son sens parce qu'elle n'est utilisée que comme conteneur de livraison, pas comme outil de pilotage.
« En tant qu'utilisateur, je veux pouvoir me connecter afin de pouvoir accéder à mon compte. » Ce ticket a été écrit des millions de fois. Il ne décrit rien d'utile sur ce que le développeur doit faire. C'est le problème central de la user story comme unité de travail.
