Il y a tant de dérives avec Scrum … :-(

Des heures supp si le Sprint est en retard ??? Le dev le plus rapide qui défini les estimations ???? La vélocité comme indicateur de performance ??? Livraison d’un scope de fonctionnalités au lieu d’un objectif global à atteindre ???

Ce n’est pas du Scrum donc ce n’est pas un SPRINT :-)

Le Dark Scrum est une plaie (cf Ron Jeffries)

Le Vrum un poison (un Scrum bien maquillé où le cycle en V est toujours bien présent)

Et Scrum ne fait pas de miracle. Ce n’est qu’un outil qui mal utilisé peut faire des dégâts.

Si la culture de l’entreprise n’est pas en adéquation avec les valeurs véhiculées par l’agilité, si l’équipe n’est pas formée, si le produit n’est pas bien défini (Story Mapping, Impact Mapping etc …) ça commence mal.

Et on ne devrait surtout pas faire du Scrum.

Tout est donc une histoire de contexte et de personnes selon moi.

Kanban ?

Il y a déjà un peu de Kanban dans Scrum.

En effet Kanban est plus libre mais ne demande t-il pas plus de rigueur ?

J’aime l’idée de partir d’un cadre comme Scrum, d’apprendre à contextualiser et d’adapter ce cadre intelligemment au fur et à mesure du temps.

Le Burndown Chart par exemple a fini à la poubelle …

Il ne sert pas à l’équipe et peut avoir un effet anxiogène .

Le “no estimate” ? Bonne réflexion :-)

Mais personnellement, j’aime utiliser les estimations pour définir un plan de Release.

Encore une fois quand un client prend les estimations pour des engagements … alors il est préférable de s’en débarrasser au plus vite.

Les estimations ne sont qu’un outil (une fois de plus) au service de l’équipe qui développe …

Pour terminer, je pense que Scrum est surtout un Framework.

Quand on commence à bien connaitre le framework on peut se passer de certains composants et compléter Scrum avec des bundles de type XP ou Kanban (et Lean par exemple en amont).

Merci pour la réflexion et le partage :-)

Ça fait toujours du bien de se poser des questions :-)