Technique 1 : Surestimez vos Users Stories

C'est facile au lieu de dire 3 vous dites 5 ou 8, si vous hésitez entre 13 et 21 : prenez 21.

Technique 2 : Vous arrêtez le Pair Programming

Vous avez donc 2 fois plus de développeurs.

Technique 3 : Ne codez pas les classes de test

Vous gagnez du temps et donc vous pouvez coder d'autres users stories

Technique 4 : Utilisez le frigo

Ce n'est pas la plus facile des techniques mais c'est assez efficace.
Vous êtes dans le Sprint N avec un objectif de 100 points pour ce Sprint, votre équipe est à 120 points à quelques jours de la fin du Sprint, votre vélocité est déjà satisfaisante, donc VOUS GELEZ la version :

  • Interdiction de toucher au board jusqu'à la fin du Sprint
  • Si on vous demande où vous en êtes vous prétendez finir les 2 à 3 Stories qui sont dans le colonne "En cours"
  • Pendant ce temps là, l'équipe continu à coder mais tout ce qu'elle est en train de faire DOIT être compter sur le Sprint suivant.

Petite remarque : Faites attention que le PO élise bien vos Stories terminées pour la prochaine itération...

Technique 5 : Ajoutez des Users Stories techniques dans les itérations

Encore plus facile que toutes les autres techniques, lors du Planning Game rappeler qu'il faut :

  • Ré-indexer la base de données (5 points),
  • Faire du refactoring (13 points),
  • Installer quelques patchs (de préférences des trucs sur de la sécurité, cela passe mieux) (21 Points) etc etc ...

Si vous êtes SUPER BALAISE : Vous pouvez chiffrer les corrections des bugs de l'itération précédente.

Technique 6 : Transformer les Bugs en Users Stories

Si vous n'avez pas réussi à intégrer les corrections de bugs lors du Planning Game il vous reste une solution :

  • "it's not a bug it's a feature"

Donc quand votre PO voudra modifier ce "non" bug : vous lui présenterez cela comme une évolution donc une nouvelle User Story.

Technique 7 : Dites à votre PO que vous avez 1 ou 2 développeurs qui sont malades

Cette technique ne fonctionne qu'avec 2 conditions :

  1. Vous présentez votre vélocité en fonction du nombre de jour de présence des développeurs
  2. Vos développeurs travaillent de chez eux (mais sans faire trop de bruit)

Les développeurs sont contents car ils restent chez eux, reste généralement un petit problème de facturation en fin de mois à maquiller (sauf si vous êtes au forfait par itération)...

Technique 8 : Oubliez la notion de "Propriété collective du code"

Spécialisez vos développeurs : un en HTML, l'autre en SQL et le 3ième en Java.
C'est mathématique : vous allez créer 3 experts dans le domaine, les 3 meilleurs gars de la planète : Personne ne pourra aller plus vite qu'eux.

Technique 9 : Interdisez toutes les cérémonies à vos développeurs

StandUpMeeting, Rétro, Démo, Planning Game : tout ça fait perdre du temps à vos équipes et le temps perdu s'est de la vélocité qui s'envole.
Vous allez me dire que les cérémonies sont importantes, mais non regardez comment les gérer :

  • StandUpMeeting : Vous distribuez les tâches aux développeurs
  • Rétrospective : Cela ne sert à rien, votre vélocité ne fait que progresser
  • Démonstration : Bah vous êtes le Chef de projet ScrumMaster : Vous protégez votre équipe (et votre vélocité), vous allez seul en démonstration
  • Planning Game : Vous chiffrez pour vos développeurs : vous les connaissez bien, dans ScrumMaster : n'oubliez jamaiqe qu'il y a Master.


Technique 10 : Augmentez les plages horaires

Quelques petites astuces :

  • Imposez le 9h00/19h00 (voire 20h00 2 à 3 fois par semaine)
  • Préférer les sandwichs devant le PC que les restaurants
  • Gérer les pauses : 5 minutes le matin & 5 minutes l'après midi (+ 5 minutes si vous pensez finir après 20h00)
  • Si un membre de l'équipe passe trop de temps sur son téléphone : achetez un brouilleur (http://www.magnumtelecom.com/Pages/brouilleurs.htm)

Vous avez maintenant 20% de développeurs en PLUS et tout ça pour le même prix et le même nombre de jour de production.


ETC, ETC, ETC...



DISCLAMER

Dans le prochain billet je vous expliquerais pourquoi toutes ces techniques ne sont que de LA POUDRE AUX YEUX. Robert Redford et Paul Newman auraient pu écrire ces 10 techniques en 1973 et/ou en faire un film : Arnaque