Les points clés de ce succès sont :

• L’utilité du nouveau produit et l’innovation technologique
• La tenue des jalons très courts et un coût final inférieur au budget initial
• Le fonctionnement en « équipe » avec une implication très forte des utilisateurs finaux.

Le choix d’une réalisation en mode agile a donc fortement contribué à ce succès car elle a permis :

• D’établir une réelle collaboration entre MOA et MOE
• D’obtenir une implication active des utilisateurs (toutes les 2 semaines pour donner du feedback sur l’incrément de produit réalisé)
• De faire émerger une équipe de réalisation performante et fortement proactive
• De piloter via une métrique simple et fiable : La vélocité !

C’est vrai que je ne cours pas après les prix, mais quand même, cela fait vraiment plaisir quand cela arrive, alors autant le célébrer un peu

Cette comparaison peut sembler utile pour simplifier (vulgariser) la compréhension des estimations agiles par des néophytes, mais malheureusement, en dehors des arguments pour l’une ou l’autre des approches, il existe une différence fondamentale que je vais chercher à développer dans ce billet.

Points de Fonction

L’approche PF considère que la fonctionnalité est réalisé dans son ensemble, c’est à dire que le besoin est implémenté en même temps que les aspects techniques, en une seule opération qui conduit à un résultat de bonne qualité.

Il n’y a donc pas de place pour une reprise technique ultérieure de l’architecture ou du code, dans le sens ou ces modifications éventuelles ne sont pas chiffrées.

Il faut faire bien du premier coup, ce qui implique de réaliser une étude d’architecture « up-front » qui demande d’avoir des spécifications complètes, qui prend du temps … et qui ne garantit malheureusement pas qu’il ne faudra pas retoucher à l’architecture dans le futur.

L’approche Agile remet en cause le bien fondé de ces approches « up-front » qui permettent, soi disant, de définir tous les éléments nécessaires pour l’étape suivante.

Story Point

L’approche SF considère que la fonctionnalité sera réalisée durant une itération sur l’architecture en place. L’objectif est de pouvoir rapidement montrer la fonctionnalités aux utilisateurs pour prendre leurs feedbacks et vérifier que le projet se dirige toujours vers le bon objectif.

Si une reprise technique est nécessaire (modification de l’architecture), l’équipe de réalisation soumettra une Technical Story au Product Owner en lui expliquant la nécessité de cette opération et en argumentant pour que la priorité soit forte, si cette reprise est à faire rapidement.

Lorsque cette Technical Story sera implémentée, l’équipe pourra vérifier que le comportement du produit n’est pas modifié (grâce aux tests automatiques) et garantir une livraison de qualité.

Conclusion

Certains pourraient argumenter qu’une reprise d’architecture coûte chère et que pour l’éviter il faut y réfléchir beaucoup à l’avance, mais c’est typiquement un retour aux méthodes traditionnelles.

Ce que ces personnes n’ont pas compris, c’est que l’agilité fait gagner du temps sur l’ensemble du système (ce n’est pas une approche pour gérer le codage) et les gains sont très significatifs si elle est pratiquée avec discipline.

1. Définir et faire partager la vision du produit (A l’aide du Product Charter par exemple)
2. Représenter le client/utilisateur auprès de l’équipe
3. Communiquer en externe sur l’avancement (Utiliser la vélocité comme métrique principale)
4. Créer et maintenir le Product Backlog (Le quotidien du Product Owner)
5. Prioriser le Product Backlog (Définition et utilisation d’un modèle de valeur métier)
6. INVESTir dans les exigences (Rédaction complète et vérification à l’aide du modèle INVEST)
7. Participer aux meetings Scrum de l’itération (Planning, Démo et Rétrospective) et éventuellement au Stand Up
8. Accepter ou refuser le travail réalisé (Et donc faire « gagner » les points ou pas)
9. Ne rien changer durant l’itération (Si, si, c’est une responsabilité)
10. Etre disponible sur demande de l’équipe

Il m’a été difficile de faire le tri et de réduire à 10 éléments cette liste, donc si vous souhaitez rajouter quelque chose, il faudra également indiquer ce que vous aller retirer … pour que le total fasse toujours 10

« Je suis Product Owner d’un produit réalisé en mode Agile depuis plus d’un an, est-ce que vous pensez que j’ai besoin d’une formation de Product Owner Agile ? »

La question est intéressante puisque le principe de l’agilité est un peu « d’apprendre en marchant » et donc il est tout à fait raisonnable de se poser la question de l’intérêt de se suivre une formation pour se faire expliquer le travail que l’on pratique au quotidien

Comme la réponse n’est pas binaire et dépend forcément du contexte dans lequel le travail est réalisé, voici ce que j’ai répondu :

-          Si vous utilisez une modèle de valeur métier pour prioriser vos exigences

-          Si vous savez utiliser les techniques de planification agile basée sur la vélocité

-          Si vous savez faire un diagramme d’affinités pour identifier vos utilisateurs

-          Si vous savez décrire une User Story de petite taille qui soit démontrable

-          Si vous savez définir des critères d’acceptation compréhensibles par l’équipe technique

-          Si le Burndown Chart de Release est votre outil de reporting principal (voir unique)

-          Si vous avez compris pourquoi votre présence à la rétrospective est indispensable

-          Si vous avez compris pourquoi votre présence au daily stand up est facultative

Alors vous n’avez aucunement besoin de formation spécifique

Qu’en pensez-vous ?

• Avoir utilisé l’approche BDD pour définir et réaliser le produit et couvrir TOUS les cas de fonctionnement
• Avoir une batterie de tests fonctionnels automatiques permettant d’assurer une couverture complète du produit
• Réaliser une UAT (User Acceptance Test) complète lors de l’itération de mise en production

C’est cette 3ème option qui a été retenue sur un projet que j’accompagne et pour réaliser cette action, plusieurs utilisateurs (7 personnes) se sont réunis 2 jours autour de l’équipe technique (5 personnes) et du Product Owner.

Pour conduire à bien cette activité, nous avons mis en place une approche Scrum :

• Priorisation des 54 tests à faire (création d’un TEST BACKLOG)
• Estimation en points de chaque test (valeurs autorisés : 5, 8, 10, 15, 30)
• Affichage des 54 items sur le mur dans une colonne TO DO
• Démarrage de l’itération en déplaçant les items dans la colonne IN PROGRESS (avec saisie des initiales des testeurs)
• Durée de l’itération : 1 heure
• Réalisation des tests en PAIR TESTING
• Validation immédiate des feedbacks par l’équipe technique (Bug ou Evolution)
• Passage à DONE des tests réalisés au fur et à mesure
• Démo des Bugs trouvés en 5 minutes, en fait affichage de fiches A5 renseignées sur le mur d’information
• Rétrospective en 3 minutes … en fait pas d’amélioration du process qui marchait très bien
• Calcul et saisie de la vélocité dans un BurnDown Chart de Release
• Et continuation sur l’itération suivante … en tout 5 itérations dans la journée

Comme quoi l’approche SCRUM n’est pas réservée au développement de logiciel et peut se révéler très efficace pour aider une équipe à délivrer un projet … quel qu’il soit

Après quelques jours de réflexion, j’ai proposé le questionnaire suivant :

• Votre besoin fonctionnel est-il parfois incomplet au T0 du projet ?
• Identifiez-vous de nouveaux besoins en cours de réalisation ?
• Attendez-vous longtemps pour voir une première version ?
• Avez-vous des difficultés à vous faire comprendre de la MOE ?
• Voyez-vous vos planning dériver avec le temps ?
• Vous demandez-vous parfois ce que fait la MOE ?
• Découvrez-vous beaucoup de bugs en fin de cycle ?
• Souhaitez-vous augmenter votre productivité ?

Si vous avez répondu OUI à l’une de ces questions, alors les méthodes Agiles peuvent vous aider à mieux faire car

• La possibilité de changer le besoin fonctionnel est intégré structurellement dans la méthode
• Une version démontrable est livrée régulièrement (tous les 2 ou 3 semaines)
• Les échanges entre MOA et MOE sont permanents et riches d’enseignements
• La prédictibilité de la MOE est basée sur le travail réellement terminé et non sur une estimation de la progression
• La visibilité est totale et permanente sur toutes les activités
• Les tests sont faits en continu pour éviter les effets « Big Bang » de fin de cycle
• Les gains de temps sur l’ensemble du cycle (de l’expression de besoin au déploiement) sont très significatifs

Avec quelques recommandations pour passer à l’Agilité

• Se former, car même si la méthode semble simple, c’est plus complexe qu’il n’y parait
• Se faire accompagner, car c’est plus difficile qu’il n’y paraît et les bénéfices seront obtenus plus rapidement
• Démarrer au plus tôt en mode Agile, c’est-à-dire dès la collecte des besoins, car tous les acteurs sont concernés et pas seulement la MOE
• Accepter et mettre en œuvre les changements induits par la méthode (réunions en présentiel, disponibilité en continu …)
• Comprendre que l’agilité est avant tout un état d’esprit et non juste une « autre méthode »

Qu’en pensez-vous ?

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.