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 modifications sont démontrées, des rétrospectives sont effectuées et le backlog est affiné. Pendant chaque sprint, le temps d’achèvement des tâches est enregistré, ce qui permet à la direction de projeter dans le futur quand les projets atteindront leur achèvement.

Dans de nombreux projets Scrum auxquels j’ai participé, l’accent est mis sur « s’engager » sur des tâches ou « prendre la responsabilité ». À 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 pour que les équipes le suivent et il donne à la direction les outils pour prédire l’avenir. Les équipes qui ont pratiqué le waterfall trouvent Scrum facile à comprendre.

De nombreuses pratiques de Scrum ne sont pas nécessaires. Par exemple, la plupart des logiciels de suivi des problèmes permettent aux gestionnaires d’exécuter des rapports sur la fréquence d’achèvement des tickets. Avec ces informations, les gestionnaires peuvent déduire la vélocité, au lieu de l’intégrer au processus et d’en faire un gros problème. Prendre la responsabilité est une farce, nous le faisons naturellement, le rendre explicite est insultant. Tous les projets auxquels j’ai participé ont chaque ingénieur avec 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é ; les ingénieurs ne manquent jamais de travail.
• À mon avis, les rétrospectives sont l’activité non-développement la plus essentielle. Sans cela, vous n’avez aucune chance de devenir une organisation meilleure et plus efficace.
• Automatiser, automatiser, automatiser
• 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 la raison pour laquelle la « tâche A » n’a pas été complétée est une perte de temps. Il est clair que la tâche était soit trop grande, soit que du travail de priorité plus élevée a été entrepris.
• Les démos sont une perte de temps à moins que le client ne s’en soucie et ne fournisse de retours.
• Les réunions quotidiennes peuvent ou non être nécessaires. Je préfère me réunir tous les deux jours.

En fin de compte, il s’agit de fournir de la valeur au client de la manière la plus efficace.