Scrum est surévalué

La plupart des entreprises suivent un type de processus Scrum. Cela implique généralement des sprints de 2 ou 3 semaines. À la fin de chaque sprint, les changements sont présentés, des rétrospectives sont effectuées et le backlog est affiné. Pendant chaque sprint, le temps de completion des tâches est capturé, ce qui permet au management de projeter dans le futur quand les projets atteindront leur achèvement.

Beaucoup des projets Scrum auxquels j’ai participé mettent l’accent sur “s’engager” sur des tâches ou “prendre possession.” À la fin du sprint, de nombreux ingénieurs sont tenus responsables des tâches incomplètes. La vélocité du sprint est une autre idée qui est martelée. Nous devons maintenir notre vélocité ! C’est comme si créer des logiciels était une course, ce n’est pas le cas. Si les ingénieurs sont tenus responsables par une métrique, ils optimiseront pour la métrique, ce n’est pas ce que vous voulez.

Scrum crée un cadre facile à comprendre que les équipes peuvent suivre et donne au management les outils pour prédire l’avenir. Les équipes qui ont pratiqué la méthode en cascade trouvent Scrum facile à comprendre.

Beaucoup des pratiques de Scrum ne sont pas nécessaires. Par exemple, la plupart des logiciels de suivi des problèmes permettent aux managers d’exécuter des rapports sur la fréquence de completion des tickets. Avec cette information, les managers sont capables d’inférer la vélocité, au lieu d’intégrer la vélocité dans le processus et d’en faire un gros problème. Prendre possession est une farce, nous le faisons naturellement, le rendre explicite est insultant. Tous les projets auxquels j’ai participé, chaque ingénieur a un coin de l’application qui est son espace.

Autres façons d’améliorer la livraison de logiciels :

• Si vous avez besoin de déploiements hebdomadaires, planifiez-les. Déployez ce qui est prêt.
• Gardez le backlog affiné ; alors les ingénieurs ne manquent jamais de travail.
• À mon avis, les rétrospectives sont l’activité non-développement la plus essentielle. Sans elles, vous n’avez aucune chance de devenir une organisation meilleure et plus efficace.
• Automatisez, automatisez, automatisez
• S’engager sur une liste de fonctionnalités est ridicule. Classez les tâches et complétez ce que vous pouvez. S’inquiéter de pourquoi la “tâche A” n’était pas complète est une perte de temps. Il est clair que la tâche était soit trop grande, soit qu’un travail de plus haute priorité a été entrepris.
• Les démos sont une perte de temps à moins que le client ne s’en soucie et ne fournisse des commentaires.
• Les réunions quotidiennes peuvent être nécessaires ou non. Je préfère me réunir tous les deux jours.

Au final, il s’agit de fournir de la valeur au client de la manière la plus efficace.