Aucune image

Transformation agile : comment choisir ses projets pilote ?

Même si de (rares) exemples d’adoption agile « Big Bang » existent, notamment celle de Salesforce en 2007 (sans pilote mais non pas sans préparation), je reste persuadé qu’une transformation agile réussie passe par l’expérience de deux ou trois (max.) projets Pilotes.

PROJET REEL – EQUIPE REELE : ça c’est la base, mes deux prérequis : le projet pilote doit être représentatif même s’il reste tourné vers l’apprentissage!

NE PAS TESTER CE QUE POURRAIT DONNER l’AGILITE DANS LA VRAIE VIE ET DANS SON PROPRE CONTEXTE ORGANISATIONNEL EST SELON MOI UNE ABERRATION. C’est de surcroit se priver d’une source de connaissance et d’amélioration non négligeable (approche KAiZEN) ainsi que d’un bon levier d’accompagnement au changement.

Comment sélectionner les bons projets pilote ?

Voilà une question ô combien cruciale, tant ces projets seront sous le feu des projecteurs, une question que nous sommes tous amenés à nous poser et sur laquelle est revenu dernièrement Mike Cohn, grand gourou US de l’agilité.

Ces 4 critères me vont plutôt bien :

Durée: Le projet pilote ne doit être ni trop court (pour être crédible et source d’apprentissage) ni trop long (pour capitaliser au plus vite et adopter dans la foulée).
Bref : Entre 2 et 5 mois (max) avec entre 4 et 7 itérations de trois semaines…

Aucune image

Un Backlog priorisé pour le Père Noel … Acte 2

Noel approche et les enfants le savent, du coup voilà à quoi j’ai eu droit le weekend dernier…

Mes enfants : « Papa … papa … pour Noel on fait le jeu des post it »
Moi : « D’accord les enfants mais on va faire un petit peu différemment … »

Car depuis ce billet « Des priorités pour le Père Noel », j’ai bien évidemment eu le temps d’améliorer le process 🙂 même si côté contraintes, c’est toujours plus ou moins la même chose :

– Le temps du Père Noel est compté
– Son traineau n’est pas extensible
– Les délais sont serrés
– La date de livraison ne peut pas bouger
– Le Père Noel a un grand nombre d’enfants à satisfaire
En outre, mes enfants, en bons Product Owner qu’ils sont, ont compris qu’ils ne pouvaient pas tout avoir (même s’ils en veulent toujours plus), et que le fait d’avoir été sage (ou non) pouvait « potentiellement » avoir un impact sur ce qu’ils allaient recevoir… d’où la nécessité pour eux de fixer des priorités !

SCRUM / XP depuis… la maison

Aucune image

User story : la forme c’est important !

Les « User Stories » sont de plus en plus utilisées sur les projets Agiles, et c’est une très bonne chose.

Leur simplicité, leur orientation à la fois « But Utilisateur » et « Valeur Business », ainsi que le focus immédiat sur les critères d’acceptation les rendent en effet terriblement efficaces pour les projets de conception.

Une fois la règle des 3 C assimilée (Carte, Conversation et Confirmation) et les critères INVEST bien décrits, quand les équipes et le Product Owner commencent à découvrir les stories, ils me demandent souvent si le format « User Voice » doit être respecté …
Ce format c’est le fameux :

En tant que < Rôle d'utilisateur >,
Je peux < But >,
Si bien que < Justification >

Un format au sein duquel,

Le rôle représente celui qui fait l’action et qui en bénéficie
Le but représente l’action accomplie
La valeur Business représente les bénéfices qui se dégagent de l’action
Alors, doit-on utiliser ce format ? Ma réponse est sans équivoque OUI…