Agilex : Agilité et Expertise

Les dessous de l’affaire Toyota

Je me fais pas mal chambrer en ce moment car beaucoup de ceux qui connaissent mon fort intérêt pour le Lean, dont Toyota est le créateur, me demande ce que je pense des problèmes de qualité que rencontre Toyota actuellement, et certains en profitent même pour remettre en question l’approche Lean dans son ensemble … les petits sournois

La lecture de cet article (Les étranges dessous de l’affaire Toyota) donne une vision nouvelle de la situation, et qui, même si je ne peux pas juger de sa véracité, me semble très intéressante à lire.

Intox et contre-intox diront certains, pourquoi pas, je ne connais ni le rédacteur de la note, ni la fiabilité du site knowckers.org, mais je vous laisse vous faire votre propre impression (merci pour le pointeur Franck )

[humour] De l’utilisation des Post-it

Ceux qui me connaissent savent que je suis fervent partisan de l’utilisation d’un mur d’information visuel à base de Post-it ou autre cartes, plutôt que n’importe quel outil électronique de gestion de projet agile.

Peut-on aller trop loin avec l’utilisation des Post-it … c’est possible à en voir l’usage qu’en fait cet « agiliste » distingué

Poste agile chez ST à Crolles

Pour ceux qui seraient intéressés, voici une offre de poste Agile chez ST à Crolles.

Voici l’offre telle que je l’ai reçu … et surement disponible sur le web si vous cherchez un peu

J’ai besoin rapidement d’un ingénieur en informatique, pour le développement d’utilitaires softwares, dans le cadre de notre flot d’implémentation. Quelqu’un qui ait une bonne aptitude a résoudre des problèmes logico-mathématiques. Au moins quelques années d’expérience dans le développement CAD et les outils C/C++/Tcl/shell sont souhaitables. Une expérience dans les méthodes de développement agile (extreme programming ou scrum) seraient aussi très intéressantes pour participer a leur mise en place. Cet ingénieur rejoindrait la petite équipe que je dirige ou les développeurs ont un ou plusieurs projets sous leur responsabilité tout en ayant une responsabilité partagée sur le processus et l’infrastructure software. Cet équipe travaille en relation très étroite avec les utilisateurs, qui sont partie intégrante de notre processus de développement.

Sessions retenues pour Agile France à Paris

Après être venu en touriste l’année dernière à cette superbe manifestation, j’ai décidé en 2010 de proposer quelques sujets et 2 d’entre eux ont été retenus :

• Une présentation+atelier sur les métriques pilotées par le comportement (Behaviour Driven Metrics) que j’animerais avec Manu
• Les bonnes pratiques du Product Owner mise en œuvre sur un projet qui a très bien réussi

Ce sont des créations faites spécifiquement pour cet évènement, souhaitez moi bonne chance

Voir ci-dessous pour plus de détails

Lire la suite »

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 »

Cherche Coach Agile (J’ai trouvé !)

Je recherche un coach agile (et non un Scrum Master) pour travailler en binôme avec moi sur la région parisienne (enfin surtout lui ou elle).

Le projet comporte une 40aine de personnes et j’estime la charge de travail à un mi-temps jusqu’à la fin de l’année.

Il est important que nous partagions certaines valeurs humaines … et je ne cherche pas à faire un coup financier … si vous êtes tenté, je vous laisse me contacter en direct (a POINT boutin AT agiletoyou POINT com)

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

Jouer à être le Product Owner

Venez nous rejoindre ce soir au Club Agile Rhône Alpes pour jouer à être un Product Owner en pratiquant le Business Value Game … vous verrez que ce n’est pas si facile que cela

Plus d’information sur le site du CARA : http://clubagile.org/2010/03/rencontre-agile-a-grenoble-17-mars-2010/

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 »