Catégorie : Scrum

Moins c’est mieux !

yinYangJe suis convaincu depuis longtemps que l’agilité génère moins de bugs que les méthodes traditionnelles et j’avoue avoir souvent argumenté cela par la mise en place d’un socle technique et de pratiques d’ingénierie (Tests automatiques, Intégration continue …)

Dernièrement j’ai eu l’occasion de jouer une demi douzaine de fois le jeu « Artistes et Spécifieurs » dans un contexte universitaire et professionnel, et cela m’a donné l’opportunité de confirmer un argument supplémentaire pour expliquer pourquoi l’agilité génére moins de bugs que les méthodes traditionnelles.

Bien entendu il ne s’agit pas d’une pratique d’ingénierie car le jeu n’en comporte aucune mais bien d’un effet très intéressant lié au processus même de l’agilité.

Continuer la lecture de « Moins c’est mieux ! »

Comment créer un produit que les utilisateurs détestent !

Conflits Product OwnerArticle librement traduit de l’anglais : Article d’origine chez Pichler (Merci à Romain pour le pointeur)

Voici une liste de comportements qui partent d’une bonne volonté mais qui sont en fait des erreurs assez classiques lors de l’application de Scrum et qui influencent négativement la réalisation du produit, et qui de plus, lorsqu’elles sont combinées peuvent conduire à un échec cuisant du produit.

  1. Etre trop pragmatique dans l’application du rôle de Product Owner : Pour essayer de répartir la charge de travail sur plusieurs individus ou un comité représentatif
  2. Viser à maximiser la diffusion du produit : Pour essayer d’avoir un produit qui contienne un maximum de fonctionnalités et qui puisse être distribué à un maximum d’utilisateurs différents Continuer la lecture de « Comment créer un produit que les utilisateurs détestent ! »

Rigueur ou Discipline ?

cerveau_rigueur_disciplineIl y a quelques jours, je présentais l’agilité à des clients en insistant sur l’aspect discipliné de la méthode. Une personne m’a alors interpellé en me demandant pourquoi je parlais de discipline plutôt que de rigueur, et en insistant sur les bénéfices à être rigoureux.

J’avoue ne pas avoir été très bon dans ma réponse en live, et en bon Agiliste, je me suis fait une rétrospective le soir même pour identifier la cause du problème et définir une solution pour que cela ne se reproduise pas !

Cause : Méconnaissance de la définition des mots RIGUEUR et DISCIPLINE

Solution : Ouvrir un Dictionnaire 🙂

Continuer la lecture de « Rigueur ou Discipline ? »

SuperMario Scrum

new-super-mario-brosJe ne résiste pas à vous faire partager ce qu’Ambroise a publié sur l’intranet de sa société … un grand merci à lui de me l’avoir envoyé 🙂

Si je vous dis : super héros moustachu, chronomètre, sprint, rires, agilité et compétition. A quoi pensez-vous ?

Peut-être à votre prof de gym de 5ème, ou plus probablement à vous refaire une partie de SuperMario Kart sur votre console favorite. Et pourtant, la vérité est ailleurs… Mais pas si loin !…Pour être exact, la vérité était même dans la péniche… Car c’est bien une sorte de super héros moustachu, que nous avons reçu fin juin : un vrai champion de l’agilité venu éclairer la R&D.

Continuer la lecture de « SuperMario Scrum »

Un prix pour l’agilité

FT 01Un projet logiciel réalisé en mode agile depuis 9 mois, dont je coach la MOA et la MOE, a reçu le prix Agile en Avril 2010 dans le cadre des ITN Awards 2009 (sélection au niveau corporate des projets les plus représentatifs réalisés en 2009).

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 🙂

Points de fonctions ou points d’histoire ?

boite_a_bons_pointsJ’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.

Continuer la lecture de « Points de fonctions ou points d’histoire ? »

Les 10 responsabilités du Product Owner

top-ten-goldVoici 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 ?

product-ownerDerniè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 🙂

Continuer la lecture de « Suis-je un Product Owner Agile ? »

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 :

Continuer la lecture de « Tests Fonctionnels en Scrum »

Agilité pour MOA

AgileImprovementsDerniè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 ?