10 façons de se planter avec Scrum et XP

Pour tous les fans de l’Agilité et du développement logiciel, le site d’InfoQ est une mine d’informations et de ressources utiles.

Nous vous invitons à regarder la présentation intitulée: «10 ways to screw up with SCRUM and XP». Réalisée par Henrik Kniberg, elle a été filmée sur l’Agile Tour 2008.

En résumé, voici les 10 façons de se planter avec Scrum et XP:

  1. Croire à un miracle de l’Agilité
  2. Incapacité à définir ce que signifie «Terminé» (Definition of Done) ou à suivre la définition en pratique
  3. Incapacité à gérer la Vélocité (mauvaise utilisation, tricher sur la vélocité réelle…)
  4. Rétrospectives inefficaces
  5. Manque d’engagement de l’équipe
  6. Incapacité à bien gérer la dette technique
  7. Problème de travail en équipe (mauvaise définition des rôles, pb de coopération, interférence du management…)
  8. Problème avec le Product Owner (disponibilité, pouvoir, implication, mauvaise gestion du product backlog…)
  9. Peur de fusionner les développements car trop complexe à faire
  10. Problème d’utilisation du tableau des tâches (mise à jour peu fréquente, complexité…)

2 réflexions sur « 10 façons de se planter avec Scrum et XP »

  1. …. mais aussi
    11. croire que si l’on fait du TDD, on fait de l’XP
    12. confondre méthodologie de GDP avec technique d’ingéniérie
    12. Penser que le Product Owner c’est le client
    13. Penser qu’un ScrumMaster est un développeur
    14. Penser que la liste des bugs, c’est pour demain
    15. Penser que l’équipe est à même de dire au client où se trouve sa valeur business
    16. Penser que l’Agilité est la pierre philosophale
    17. Rester dans son coin et ne pas fédérer les autres acteurs de l’entreprise
    18. Oublier que Scrum est un rythme: une time-box où l’on tend vers l’agilité
    19. Il y a 2 managers dans Scrum
    20. réduire les sprints, car se planter permet d’apprendre plus rapidement

  2. Merci Pierre pour ta contribution à la liste.

    J’ai bien aimé les anecdotes d’Henrik Kniberg. Notamment celle du projet pour lequel le burndown chart a été abandonné. Motif: Cela déprimait l’équipe car la courbe allait vers le haut (au lieu d’aller vers le bas). MDR 😀

    D’autres expériences à partager ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *