« 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 ?

• Chuck Norris est Scrum Master et Product Owner en même temps
• Chuck Norris peut faire des sprints de 6 mois
• Chuck Norris porte des TimeBoxer short
• Chuck Norris ne déplace pas les postIt sur le tableau, il bouge le tableau
• Chuck Norris n’estime pas, il sait
• Chuck Norris s’appaire tout seul
• Chuck Norris est autoriser à arriver en retard au Stand Up
• Chuck Norris s’assoie lors du Stand Up
• Chuck Norris a tout terminé à la fin du Sprint Planning Meeting
• Chuck Norris n’estime pas les User Story, mais les User Story le respecte
• Chuck Norris écrit d’abord le code et jamais les tests
• Chuck Norris ne craint pas les bugs, mais les bugs le craignent
• Chuck Norris ne connait pas le Kanban, il n’a pas de limite
• Chuck Norris ne tire pas, il pousse
• Quand Chuck Norris dit « c’est terminé », alors c’est vraiment terminé
• Chuck Norris ne déploie pas, il développe directement sur les machines de production
• Chuck Norris sait que pour établir un burn-down, il faut du Napalm
• Chuck Norris n’a pas de burn-down, tout est brulé autour de lui
• Chuck Norris ne répond qu’à 2 questions lors du Stand Up … il ne connait jamais de problème
• Chuck Norris n’a pas besoin de prioriser le Product Backlog
• Chuck Norris réalise plusieurs User Story en parallèle
• Chuck Norris n’utilise pas le Développement Piloté par les Tests. Chuck Norris pilote lui même
• Chuck Norris est le Product Backlog
• Chuck Norris est Scrum Master certifié sans avoir le certificat
• Chuck Norris n’a pas besoin d’Acceptance Test. Chuck Norris accepte ou pas !
• Chuck Norris n’a pas besoin de rétrospective. Le process Chuck Norris est parfait
• Chuck Norris écrit des tests qui passent avant d’avoir écrit le code
• Chuck Norris gagne toujours au Poker Planning

Et je rajouterais

• Chuck Norris n’a pas de plan de release. Chuck Norris sait ce qui est à faire
• Chuck Norris a une vélocité de 50 000 points
• Chuck Norris termine le Product Backlog à chaque itération

D’autres idées ?

J’ai choisi un thème qui me tient à coeur et qui est un peu décalé par rapport aux présentations que j’ai l’habitude de voir dans ce genre de manifestation :

Help me, they are asking for documentation!

Si vous pouviez me faire quelques commentaires directement sur le site AGILE2010, cela ferait un peu de buzz autour de mon sujet et me donnerait une chance supplémentaire d’être retenu.

Pour éviter « Access Denied », vous devez au préalable vous inscrire sur le site en créant un compte (ou utiliser votre compte existant s’il existe)

Ne laissez pas de commentaires du genre « Super idée » ou « Alex est génial » … ca ne servirait à rien voir même me desservirait, mais si vous pouvez me poser des questions sur le contenu de ma présentation ou sur ce que vous aimeriez bien y trouver … ce serait super

Merci à vous tous

Si vous avez déjà rêvé de prendre une photo avec les doigts, de lire l’heure sans porter de montre à votre poignet, de jouer au pong sur le sol du métro, d’avoir la carte météo de votre journal papier mise à jour en temps réel … et tout un tas d’autres choses aussi improbables ou incroyables … regardez cette vidéo !

Accès à la vidéo : SixthSense – La réalité augmentée

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.