1/ Pas de Users Storys mais des fonctionnalités

L'équipe et le client préfèrent parler en (petites) fonctionnalités qu'en Users Story.
Les fonctionnalités restent petites, donc les tests d'acceptation sont possible; le danger intervient quand les fonctionnalités sont trop grandes.
Les intérêts d'avoir des fonctionnalités au lieu de Users Storys :

Pas de "nano" découpage
Vision plus globale des modules de l'application
Des développements plus "gros" avec plus de fonctionnel et plus de technique


2/ Estimation en jour homme et non en points d'histoire.

J'avais écrit un billet en Avril 2010 sur ce sujet : Point d'histoire ou jours homme ?.
Personnellement, je suis plus à l'aise avec des jours hommes même si il m'arrive d'utiliser d'autres unités de mesure (T-Shirt) pour comparer la complexité des fonctionnalités.
Néanmoins, l'utilisation de jour homme a un défaut : les développeurs ont une limite en jours hommes et donc ils peuvent se mettre "la pression" pour atteindre l'objectif chiffré.
Cela reste une estimation par un chiffrage.

3/ Plus de 7 développeurs par équipe "Scrum"

J'ai connu un projet en "Scrum like" avec 15 développeurs car il n'y avait qu'un seul "Scrum Like Master", les 16 équipiers intervenaient sur 5 applications très liées.
Les difficultés résident dans les réunions : Daily Scrum Meeting, Démonstration et rétrospectives.
Des sprints de 2 semaines décalés :

Semaines paires pour 2 projets
Semaines impaires pour les 3 autres projets

avec quelques collaborateurs travaillant sur 2 applications.

4/ Pas d'estimations collectives

Sur des projets avec 6 ou 7 développeurs, il peut être parfois difficile d'avoir toute l'équipe pour estimer l'intégralité de l'application, on peut des développeurs plutôt spécialisés :

sur des flux avec les applications externes,
sur des interfaces html + javascript + ajax
base de données
backoffice
.../...

L'objectif est de ne jamais laisser un développeur seul sur un sujet mais de le binômer ou trinomer :-) (avoir 3 personnes par sujet).

5/ Ajouter un WIP (nombre de tâches maximum par colonne)

J'ai appris que ce n'était pas dans Scrum même si inconsciemment j'ai instauré le WIP sur ma colonne "In progress", pas plus de tâche en cours que de développeurs (sauf exception).

6/ Ajouter des colonnes à son "Scrum like Board"

Au début on commence avec Todo / Do / Done ou Todo / In progress / Done ou A faire / En cours / Terminé.
Puis l'équipe veut valider les tests croisés donc on rajoute une colonne : "à tester" pour avoir :
A faire / En cours / A tester / Terminé
Sur des équipe TMA, il arrive de voir le workflow BugTracker sur le board :
Initialisé / en correction / à tester / à livrer / à valider / clos ...

7/ L'attribution des tâches développeurs

Logiquement les développeurs choisissent leurs tâches mais il arrive que le "Scrum Like Master" a déjà attribué les tâches aux développeurs.
Cela peut se comprendre en cas de "fortes" logiques économiques : un développeur qui a déjà travaillé sur un module sera plus efficace pour y développer une évolution ou un module similaire.
Je pense qu'il est important de bien communiquer sur les raisons de ces affectations et d'étudier des roulements et/ou des binômages.


Je me répète mais les indicateurs principaux sont :

Satisfaction du client et adéquation avec ses attentes,
Motivation de l'équipe,
Qualité de l'application.


Et vous vos "entorses" à Scrum ?