Pour une collaboration efficace rien ne remplace…
… le face à face, les discussions et les échanges autour du tableau blanc ! Les workshops ou « Ateliers de travail » se multiplient dans le cadre […]
Ergonomie des Portails d’entreprise : une conception modulaire… et ludique
Le rôle d’un portail d’entreprise est de fournir un point d’interaction unique et homogène à toutes les applications du Système d’information. Aujourd’hui le portail d’entreprise […]
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…
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
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…
Toujours plus agile – Vers de nouveaux challenges
Une page se tourne…
puisque j’ai démissionné de mon poste de Consultant senior chez SQLI Paris.
Une expérience humaine et professionnelle enrichissante qui me conduit aujourd’hui vers de nouveaux challenges…
Un bon break d’une semaine, et c’est donc parti, début novembre, pour PLUS D’AGILITE et de CONSEILS chez Valtech Technology.
Demain c’est l’Agile Tour Paris 2009
« Go see » …
demain 15 octobre, à partir de 9heures, à l’Université Paris Ouest – Nanterre La défense (Paris X)
L’agile Tour, c’est un cycle de conférences sur l’Agilité, dans plusieurs villes de France et d’ailleurs durant tout le mois d’octobre avec comme objectifs de:
– Promouvoir l’agilité
– Partager nos visions de l’agilité
– Fédérer
– Soutenir
Le programme parisien est allêchant. L’inscription semble nécessaire.
Pour ma part, un déplacement à Brest ne me permettra pas d’assister à l’événement; j’y serai l’année prochaine … sans faute !
Sinon vous avez aussi l’événément toulousain, le 22 octobre, avec du beau monde, notamment Claude Aubry, Pascal Roques, Thierry Cros, Laurent Carbonnaux, Olivier Azeau …
Style de coaching agile
Le coaching Agile, je le rappelle, consiste à aider l’organisation, une équipe, une personne dans son parcours vers l’agilité pour des résultats concrets et mesurables. C’est un savant mélange d’expertise et de déontologie, c’est aussi et surtout une question de style adapté au contexte de l’intervention, et couplé à une mécanique d’apprentissage qui m’est chère : SHU – Ha – RI.
Le coaching … c’est donc enseigner, notamment les règles fondamentales (« suivre les règles »), les pratiques clés, les valeurs, les principes en encouragent et en impliquant au maximum (Implique moi et je comprendrai) pour initier le changement.
Le coaching … c’est aussi accompagner et guider sur la base de ce qui a été enseigné préalablement. Il s’agit d’approfondir et de répondre à des problématiques plus diverses, souvent plus complexes. Etre le partenaire privilégié, étudier les situations, envisager toutes les options et essayer avec l’équipe celle(s) qui me semble(nt) le(s) plus pertinente(s). Feedback et adaptation, mais toujours avec un minimum d’enseignement…
Agile CMMI : Voyage d’un coach agile au cœur de la gestion des exigences-REQM
Première étape de mon parcours au travers d’un référentiel Agile CMMI, et premier billet d’une longue série qui s’adresse en priorité à mes lecteurs AGILISTES, aux praticiens CMMI et à ceux qui s’intéressent de prés ou de loin à l’amélioration des processus. Ma posture est celle d’un coach Agile qui accompagne une organisation cherchant à atteindre le niveau de maturité 3 CMMI, mais souhaitant garder un mode de fonctionnement agile fondé sur des pratiques Scrum et XP.
Voici donc REQM, Gestion des exigences, l’un des 7 domaines du Niveau de maturité 2, dont l’intention est de « gérer les exigences des produits et composants de produits du projet et d’identifier les incohérences entre ces exigences et les produits d’activité du projet ». La gestion des exigences (REQM) est avec RD (Développement des exigences) la base de ce qu’on appelle l’Ingénierie des exigences, des activités ô combien cruciales dans les projets informatiques. Les exigences sont fonctionnelles (« ce que les système doit faire ») ou non fonctionnelles (attributs de qualités, par exemple fondés sur l’ISO 9126). Au programme, REQM dans une vision Agile CMMI …
Divergence – Convergence : les deux temps d’une bonne Facilitation
Dans les organisations, l’heure est aujourd’hui à la collaboration et à la participation. Process et outils se multiplient pour servir au mieux ces deux valeurs fondamentales de l’Entreprise 2.0, mais l’enjeu reste essentiellement HUMAIN.
Ce sont bien les personnes motivées, engagées qui collaborent, qui participent, qui dynamisent l’entreprise… qui permettent que des communautés se créent, des groupes de travail se réunissent, des événements participatifs (type open space) se montent, des équipes projets se forment, le plus souvent dans la transversalité, en cassant les frontières dans et autour des organisations.
Personnage clé de ce dispositif : le FACILITATEUR, dont le rôle est d’aider un groupe, une ou des personnes à apprendre, explorer, trouver des solutions, atteindre un consensus …
La facilitation a de multiples tenants, se prépare et se travaille toujours en contexte. Mais, selon moi la qualité d’une bonne facilitation se mesurera dans sa capacité à alterner judicieusement sans les mélanger des activités de divergence et de convergence (principes de base de la pensée créative).
DIVERGER, c’est ouvrir et lister un maximum d’options…