Points de fonctions ou points d’histoire ?

J’entends souvent des personnes comparer les estimations agile en Story Point (SP) avec les Points de Fonction (PF).

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.

Lire la suite »

Les 10 responsabilités du Product Owner

Voici ma définition des 10 responsabilités principales du Product Owner (proposé sous forme de liste non priorisée) :

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

Suis-je un Product Owner Agile ?

Dernièrement j’ai eu la question suivante :

« 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

Lire la suite »

Tests Fonctionnels en Scrum

Avant de mettre en production une release importante, il est primordial de s’assurer que le produit fonctionne correctement dans le détail. Pour obtenir cette confiance, il y a plusieurs possibilités dont :

• 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 :

Lire la suite »

Agilité pour MOA

Dernièrement un client m’a demandé un court argumentaire pour inciter une MOA (le représentant du client) à se renseigner sur l’agilité. La problématique était présentée de la façon suivante : « La MOA veut savoir ce qu’est l’agilité avant de consentir à se la faire présenter !  » et il fallait donc proposer quelque chose de court, concis et percutant.

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 ?

La checkliste Scrum non officielle

J’aime vraiment bien ce que fait Henrik Kniberg et surtout comment il le fait, car Henrik possède une réelle capacité de vulgarisation qui lui permet de rendre simple et fluide la compréhension d’un problème compliqué. Et si vous ne me faites pas confiance, J’espère que vous ferez confiance à Marie Poppendieck qui dit la même chose dans la préface du dernier livre co-écrit par Henrik sur Scrum & Kanban (disponible au téléchargement sur le site de Claude Aubry).

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.

Lire la suite »

Le French SUG invite Ken Schwaber

Très belle soirée organisée par le French SUG hier soir, après la visite de Jeff Sutherland en 2009 et celle prévue de Scott Ambler très prochainement, c’était monsieur Ken Schwaber en personne qui était reçu dans les tout nouveaux locaux de Microsoft à Issy les Moulineaux (partenaire officiel du French SCRUM).

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 !

Lire la suite »

De l’utilité de la certification

Je vous invite sincèrement (si ce n’est déjà fait:)) à lire le court article de Claude Aubry FAQ Formation Scrum et également à participer à la formation qu’il organise en février sur Toulouse si vous êtes sur la région

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 … »

Lire la suite »

La Variabilité avant les Gaspillages

Beaucoup de personnes associent systématiquement le Lean à la recherche et la réduction des gaspillages.

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 ?

Lire la suite »

Scrum en Vidéo

Un article vraiment enrichissant posté par Florent Lothon (Blog L’agiliste) avec une vidéo de la mise en œuvre de Scrum sur un projet complexe et un retour d’expérience personnel très intéressant sur les difficultés de la mise en place de certaines pratiques (ne regardez pas que la vidéo et allez lire ce que Florent écrit plus bas dans son article )