Cette exercice de relecture avait généré quelques polémiques, car ma vision de Scrum diffère parfois un peu de celle de Claude, et donc des échanges très intéressants et surtout très enrichissants.

Je ne peux que vous inviter à acheter ce livre qui vous donnera beaucoup d’information sur la pratique de Scrum, et cela même si vous le pratiquez déjà.

Sinon, c’est vraiment beau un livre et cela me donne une sérieuse envie de tenter l’aventure moi-même … il ne me reste plus qu’à trouver le temps … car j’ai déjà le titre et le thème

Avoir été le rédacteur en chef de cette revue a été une bonne expérience pour moi, avec quelques challenges comme la définition d’une ligne éditoriale cohérente, la recherche de sujets en phase avec cette ligne, l’appel aux rédacteurs d’articles et le suivi de la fabrication.

Aujourd’hui je suis vraiment fier du résultat obtenu et je remercie tous les contributeurs pour la qualité de leurs articles.

Au sommaire :

• Qu’est-ce qui fait courir les agilistes ? Laurent Bossavit
• Le défi de l’agilité par Messaoud Oubechou
• SCRUM – retour d’expérience chez Orange par Jean-Michel Ortholand
• Agilité et logiciel avionique critique chez Thales par Pascal Fortin et Nicolas Blanpain
• Retour d’expérience : Agilité distribuée par Stéphane Mercier et Emilio Gutter
• Spécifications exécutables par Radhouane Gourchene
• Découverte de l’Agilité par Valentin Brossard

Dites-moi ce que vous en pensez en laissant un petit commentaire sur ce blog

Message personnel pour les anciens ENSIMAG :

Merci de payer votre cotisation 2010

pour que nous puissions continuer à éditer des revues de cette qualité.

Mais revenons au sujet de cet article : La Checkliste Scrum Non Officielle (disponible en anglais ici) proposé par Henrik sur le site de Crisp.se

En 2 pages A4 (Henrik aurait-il suivi les recommandations Lean du A3), Henrik nous propose un questionnaire simple et redoutablement efficace pour évaluer l’application de Scrum par une équipe projet.

Tout d’abord 3 questions essentielles qui valent de l’or … ou plutôt la garantie d’utiliser un processus performant :

• Livrer un logiciel opérationnel et testé toutes les 4 semaines ou plus fréquemment
• Livrer ce que le business attend le plus
• Améliorer son processus en permanence

Viennent ensuite 10 thèmes de questions sur l’application réelle de Scrum couvrant les rôles, pratiques et artefacts. Tous ces points sont des pré-requis pour que l’équipe puisse dire : NOUS FAISONS DU SCRUM !

Puis ensuite un ensemble de points qui ne sont que recommandés et non obligatoires dans la pratique de Scrum, et parmi ceux-ci :

• La présence d’un Scrum Master
• Le calcul de la vélocité
• Le Burndown de sprint
• La mêlée quotidienne

Puis 3 questions sur le fonctionnement de Scrum à grande échelle, et 3 les indicateurs positifs comme le FUN et le travailler pas tard

A titre personnel, je suis surpris que le calcul de la vélocité ne soit pas un pré-requis. Bien que je comprenne la raison, calculer la vélocité n’aide pas à la livraison d’un incrément de produit fini, je sais d’expérience que toutes les organisations demandent une vision à moyen terme de ce qui va se passer et sans la vélocité, il est impossible de donner quelques informations sur la mise à disposition d’une release.

Nous pourrions également discuter sur l’absence de pratique d’ingénierie telle que le TDD, Refactoring, Tests Unitaires, Intégration Continue … mais cela s’explique car Scrum est seulement un cadre (Framework) pour livrer de la valeur métier rapidement … et rien de plus, mais c’est déjà beaucoup !

PS : J’ai proposé à Henrik de la traduire en Français … je vous tiens au courant

Ken nous a présenté le concept du SCRUM.ORG qui est maintenant le seul dépositaire de la méthode Scrum et qui propose à des sociétés d’utiliser les matériels mis à disposition sous contrat de « licensing » … et c’est sur cette base que la ScrumAlliance va fonctionner.

Il a également présenté le nouveau concept de « Certification Scrum Developer », qui consiste sur 5 jours à former à Scrum et aux pratiques d’ingénierie issues de XP. La certification est basée sur un questionnaire relativement difficile et n’est donc pas automatique à ce jour (seulement 73% des participants l’ont obtenues). C’est un peu mieux que ce qui est proposé par la ScrumAlliance … mais cela reste très scolaire !

Autant vous dire que je ne suis pas un fervent supporter de cette approche par certification pour plusieurs raisons :

• Il est nécessaire de bachoter le scrum guide pour connaître les réponses « in the book » … alors que pour moi rien ne remplace l’apprentissage par la pratique et l’expérience qui consiste bien souvent à faire des erreurs pour apprendre. Par exemple, pour obtenir le permis de conduire, il faut avoir son « code », mais la connaissance parfaite et « in the book » des règles du « code » ne garantit pas d’avoir une bonne conduite.
• Le questionnaire ne prend absolument pas en compte l’aspect culturel de chaque pays. Même s’il faut excuser nos amis américains qui ne peuvent pas penser autrement, il est fort dommage que le questionnaire ne soit pas traduit en Français ou dans d’autres langues. Mon expérience personnelle de mise en place de Scrum en Corée est riche de cet enseignement. Hier soir la réponse de Ken à cette question n’est pas terrible puisqu’il a simplement dit hier soir « qu’il comprenait la question, mais que ce point était très bas dans son backlog »
• Il me semble également que la Scrum.org cherche à créé un besoin qui n’était pas demandé par les clients, et bien que je comprenne tout à fait la démarche business (c’est le modèle de beaucoup de sociétés innovantes), je regrette que cela ne soit pas rendu visible (un des grands principes de Scrum) et masqué derrière le message : « Nous sommes là pour aider les organisations, les équipes et les individus ».

Sinon je vous rappelle/informe que la soirée anniversaire du FrenchSUG se déroulera le 30 mars sur Paris et les thèmes proposés sont très intéressants, pensez à le noter dans vos agendas.

Je partage totalement l’avis de Claude sur la certification et cela me fait penser à la remarque d’un client chez qui j’interviens depuis peu de temps pour suppléer un coach agile déjà en place.

Le client était étonné que le coach en place ne soit pas « opérationnel » car il était certifié Scrum Master.

J’ai donc expliqué à mon client que pour obtenir la qualification CSM, il suffisait de payer pour 2 jours de formation avec un CST … rien de plus, puisqu’aucun contrôle de connaissances n’était réalisé, ni théorique ni pratique !

Sa réaction a été simplement de dire : « Ah, si je l’avais su avant … »

Mon objectif n’est pas de remettre en cause l’utilité d’une formation agile – pour moi indispensable lorsque l’on veut démarrer – ni la compétence des formateurs, certifiés ou pas, mais de faire prendre conscience à tous les clients que cette certification n’est qu’un business autour de l’agilité, très lucratif d’ailleurs, et aucunement une validation de la compétence des individus.

Je connais beaucoup de personnes qui veulent le tampon CSM sur leur CV en se disant que cela le valorise … surement pour l’instant car les clients ne connaissent pas encore bien les dessous de l’histoire … mais cela va venir … et le tampon ne servira pas à grand chose si vous n’êtes pas capable de justifier d’une pratique ou au moins d’un intérêt (participation à des conférences ou des groupes de réflexion tel que le CARA en Rhône Alpes) !

Et je vais conclure avec quelques recommandations pour bien se former à l’agilité :

• Choisissez bien votre formateur, plutôt qu’une société
• Assurez-vous de ses compétences et connaissances dans le domaine (visibilité sur le web, conférences …)
• Choisissez une formation en Français car il est plus facile d’en comprendre les subtilités … et parfois d’éviter de rater l’essentiel
• Idéalement formez toute l’équipe au démarrage du projet (construction d’un esprit d’équipe durant la formation)

Cette approche est un réductrice car si la traque des MUDA (gaspillages en Japonais) est essentielle, elle n’est qu’un des 7 concepts du Lean pour le logiciel, il y en a donc 6 autres (Eliminate Waste, Build Quality In, Defer Commitment, Create Knowledge, Deliver Fast, Optimize the Whole, Respect People).

De plus cette approche par les gaspillages est erronée car elle ne tient pas compte de la notion de maîtrise de la variabilité qui doit arriver AVANT la réduction des gaspillages.

En effet, réduire les gaspillages sur un système à forte variabilité ne conduit pas automatiquement à une amélioration du système et donc à une augmentation de la satisfaction client.

Vous n’êtes pas convaincu ?

Alors essayez ce simple exercice :

• Constituez une chaine de production de 5 ou 6 personnes en séquence.
• Donnez 10 allumettes au premier
• Faites lui lancer un dé à 6 faces.
• Faites lui donner le nombre d’allumettes indiqué sur le dé au 2ème.
• Faites lancer le dé au 2ème, et faites lui donner le nombre d’allumettes indiqué sur le dé au 3ème
• Continuer ainsi jusqu’au bout de la chaîne
• Recommencer jusqu’à ce que les 10 allumettes soient arrivées au bout de la chaîne

La moyenne d’un dé à 6 faces est de 3,5 et on devrait donc voir les 10 allumettes au bout de la chaine en 3 passages … mais la réalité est qu’il faudra 6 ou 7 passages … pourquoi ?

Maintenant doublez la capacité de production de l’équipe en utilisant un dé à 12 faces (si, si cela existe, demandez aux joueurs de jeux de rôles) et refaites l’exercice … et oh surprise … vous constatez qu’il vous faut encore 5 ou 6 passages … soit à peine mieux qu’avant pour un coût double  !!!

L’explication de ce phénomène est dans la variabilité des dés – ou écart type – qui est très forte et qui annihile l’effet bénéfique de l’augmentation de la capacité de production.

Maintenant prenez un dé à 6 faces, mais collez un sticker 3 sur les faces 1 et 2, et un sticker 4 sur les faces 5 et 6. Vous obtenez un dé avec 3 faces à 3 et 3 faces à 4 … la moyenne est toujours de 3,5 mais la variabilité est très faible … et si vous refaites l’exercice, vous constaterez qu’il ne vous faut plus que 3 passages (4 parfois). Et 2 passages avec un dé à 12 faces modifié suivant le même principe (et vous auriez même pu faire passer 12 allumettes au lieu de 10).

De la même façon la recherche et la réduction des gaspillages sur un système à variabilité forte ne va pas forcément conduire à une augmentation de la productivité … donc il est indispensable de commencer par réduire la variabilité puis de chercher à réduire les gaspillages.

Avec Scrum, pour calculer la variabilité, il suffit de mesurer la vélocité produite et de la comparer aux estimations de l’équipe. Lorsque l’équipe produit de façon régulière les points prévus, alors sa variabilité est faible et vous pouvez vous attaquer à la réduction des gaspillages car vous êtes certain d’améliorer le système et de produire plus pour moins cher.

Voici quelques informations marquantes que l’on peut retirer de cette enquête :

• Les participants s’inscrivent très tard  – Seulement 70 personnes inscrits 1 mois avant l’évènement !!
• Le bouche à oreille (dans et hors de l’entreprise) et les informations diffusées par mail (via le CARA ou autre) sont les sources principales de communication de l’évènement
• Les participants étaient nouveaux à 69%
• Cible atteinte : 45 % de débutants, 45% de confirmés et 10% d’experts agiles
• Les Keynotes de Henrik Kniberg et Elisabeth Hendrickson sont plébiscités
• 2 de mes sessions sont également en très bonne position – Cf Mes sessions à Agile Grenoble
• L’intendance est l’axe d’amélioration principal … mais nous le savions déjà
• L’organisation, la gestion du temps, la qualité des sujets présentés et des orateurs sont les critères principaux de satisfaction … et c’était bien nos objectifs principaux
• la documentation agile est un des sujets qui manquait … alors pour la conférence de cette année (en décembre 2010), je proposerais une version enrichie de la présentation faite sur Paris en 2009 (Cf. paris-puis-toulouse)

En conclusion, avec 92 % de participants très satisfaits ou satisfait, c’est confirmé, l’évènement AGILE GRENOBLE 2009 a été un véritable SUCCES !

Un grand BRAVO au CARA et à tous les organisateurs

La métaphore pour la conférence 2010 est « Learn, Practice, Explore » en référence au Shu-Ha-Ri des arts martiaux et l’engagement de James Newkirk (Agile 2010 Conference Chiarman) est de proposer plus de sessions pour les agilistes expérimentés … YEAH !!!

3 communautés sont identifiées :

• Business : animée par Lowell Lindstrom
• Leadership & organization : animée par Pollyanna Pixton (que j’avais vraiment aimé l’année dernière)
• Technical : Brian Button

Les soumissions seront ouvertes à partir de Janvier et si vous souhaitez en savoir plus … suivez le lien du blog de la conférence

A titre personnel, j’adore ce type de conférence alors j’y serais en août car mon chef vient d’accepter le déplacement … qu’est ce qu’il est bien mon chef

Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.

L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.

Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement ( »Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !

Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de  passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.

Et vous, comment trouvez vous du temps pour réduire votre dette technique ?