Toujours plus agile - Vers de nouveaux challenges

Posté par jc-Qualitystreet le 19 octobre 2009

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

Posté par jc-Qualitystreet le 14 octobre 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  …

Coaching Agile : une question de style

Posté par jc-Qualitystreet le 9 octobre 2009

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.

MàJ: Une description plus détaillée du rôle de coach se trouve dans ce billet : Coach Agile Bien Plus qu’un Coach !

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. “Vous comprenez les régles”: il faut voir plus loin. 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.

Le coaching … c’est enfin conseiller, de manière plus épisodique, quand les choses roulent et que les pratiques ont été intériorisées, améliorées. C’est souvent la petite touche experte qui rassure…

Bref le coaching c’est tout cela…

Agile CMMI : Voyage d’un coach agile au cœur de la gestion des exigences-REQM

Posté par jc-Qualitystreet le 6 octobre 2009

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, pour diverses raisons, 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 perspective Agile CMMI :

1. Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
2. Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
3. Quels sont les objectifs génériques à satisfaire OBLIGATOIREMENT ( Niveau 2 & 3), et comment se positionne l’agilité sur les pratiques génériques initialement recommandées?

1 OBJECTIF(S)SPECIFIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI

REQM SG1 : Gérer les exigences
OK AGILE CMMI

Un seul objectif à satisfaire mais il est de taille. Les exigences sont gérées, et les incohérences avec les plans du projet et les produits développés sont identifiées.  C’est l’objectif à atteindre, et l’agilité le permet largement.

2 PRATIQUES(S)SPECIFIQUES DE REFERENCE RECOMMANDEE POUR CMMI

Il s’agit des pratiques recommandées dans le modèle théorique. Non imposées, elles servent souvent de guide pour ceux qui démarrent leur projet d’amélioration des processus mais peuvent être remplacées par des pratiques alternatives, contextualisées à l’entreprise, pourvu qu’elle permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les exigences !

REQM-SP1.1 Développer une compréhension commune des exigences et de leur signification avec ceux qui les ont fournies.
OK AGILE CMMI

L’agilité se retrouve bien dans cette pratique qu’elle pourrait faire sienne. Les ateliers de travail, les face à face, pour construire de manière collaborative une Vision PARTAGEE, et un Backlog de produit, ESTIME et PRIORISE vont dans ce sens. La réunion de lancement en fait partie. Les critères d’acceptation portant sur chaque User Story (élément du Backlog) prolongent cet effort de compréhension commune et concourent  à l’atteinte de l’objectif.
Qui : Product Owner, Equipe
Quoi : Vision, Backlog de produit, Réunion de lancement, Réunion d’estimation, Réunion de planification, User Stories

REQM-SP1.2 Obtenir des participants au projet leur engagement sur les exigences.
OK AGILE CMMI

Engagement et responsabilisation : voilà des points forts des méthodes Agiles. La réunion de planification (à chaque début de sprint) est un moment où l’équipe s’engage collectivement sur la réalisation, durant le sprint, d’une partie du Backlog de produit (et user stories). Chaque jour, les membres de l’équipe s’engagent sur la réalisation d’une tâche pour construire les user stories : c’est le Daily Scrum.
Qui : Equipe, ScrumMaster
Quoi : Réunion de planification (CR PPT ou Wiki), Daily Scrum

REQM-SP1.3 Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet.
OK AGILE CMMI
 
Maintien et contrôle des exigences : c’est aussi l’objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l’avancée du projet.  Il est actualisé à la fin de chaque Sprint (suite à la réunion de fin de sprint).. Historiser les versions du Backlog est très pertinent dans un contexte CMMI.
Le changement dans les exigences peut se traduire aussi au niveau des user stories (éléments du Backlogde produit). Mettre à jour, faire vivre, la partie « Conversation » de l’User Stories est déjà une pratique en place chez beaucoup d’équipes.
Le burndown chart montre concrètement au quotidien ce qui est réalisé, et les changement éventuels survenus.
Au final, ce qui compte ici, c’est UN BACKLOG DE PRODUIT ET DES USER STORIES à JOUR.
Qui : Product Owner, Equipe
Quoi : Backlog de produit, User stories, Burndown Chart, Réunion de fin de sprint (CR PPT ou Wiki)

REQM-SP1.4 Maintenir une traçabilité bidirectionnelle entre les exigences et les produits d’activité.
OK AGILE CMMI
 
On s’en fait une montagne, et pourtant …il suffit d’envisager la fonction développée et présentée en DEMO comme la barquette de viande vendue au supermarché. Le  cas échéant, on doit  pouvoir remonter toute la chaine, et mesurer les enjeux collatéraux. Pour les végétariens, vous vez aussi la métaphore du Petit Poucet J  Le quatuor (Backlog de produit - User Stories - Tâches - Produit Développé) assure un système de suivi des exigences souple et performant, se concrétisant dans la démo de fin de sprint.  CMMI attend une matrice de traçabilité des exigences. Les feuilles de calcul et les outils du marché gérant les Backlog de produit permettent d’atteindre cet objectif.
Qui : Product Owner - Equipe
Quoi : Backlog de produit, Démo, Réunion de fin de sprint (CR PPT ou Wiki)

REQM-SP1.5 Identifier les incohérences entre les plans du projet et les produits d’activité d’une part et les exigences d’autre part.
OK AGILE CMMI

Cette pratique est un vrai point fort de l’Agilité. Elle s’effectue de manière continue, dans la collaboration, durant tout le sprint avec comme clé de voute les critères d’acceptation définis pour chaque User story mais aussi grâce aux daily scrum. La démo de fin de sprint est un RDV formel  permettant de déterminer ce qui a été fait ou pas, ce qui est bien fait de ce qui ne l’est pas.  Ce RDV qui donne lieu potentiellement à des actions correctives et à l’actualisation du Backlog de produit. FEEDBACK ET ADAPTATION.
Qui : Product Owner - Equipe - ScrumMaster
Quoi : Backlog de produit, User Stories, Daily Scrum, Démo, Réunion de fin de sprint (CR PPT ou Wiki)

3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES

REQM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI

En somme pour REQM, les exigences doivent être gérées (renvoie à REQM SG1 : Gérer les exigences)

REQM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI

Là cela devient intéressant… Cet objectif n’est pas le plus simple à atteindre ; il est pourtant nécessaire dans les contextes CMMI et Agile CMMI.   Il ne nécessite pas forcement une adaptation des pratiques Agiles, mais plutôt un élargissement de celle-ci à l’entreprise :  « J’ai réussi un projet agile, et je souhaiterais capitaliser et faire en sorte que mes autres projets en bénéficient ». Des expériences que je capitaliserais à nouveau pour les améliorer.
Je vous parle donc de PROCESS AGILE, Capitalisation et amélioration continue. Je vous parle donc d’ENTREPRISE AGILE…  C’est dans l’ère du temps non ?

REQM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des exigences…
OK AGILE CMMI

C’est un élément incontournable de mon Process Agile. Je m’appuie généralement sur le sponsor pour travailler cette directive qui vient d’en haut. Le plus souvent, elle reste générique (les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la  gestion « agile » des exigences (développement et gestion). C’est en quelque sorte officialiser  le process Agile dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes

REQM-GP2.2 Planifier le processus Gestion des exigences…
OK AGILE CMMI

Une adaptation des pratiques agiles est nécessaire puisqu’on doit introduire pour chaque projet un plan de projet ou charte projet qui décrira dans les grandes lignes le Qui, Quoi, Quand, Ou  du projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.

REQM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des exigences…
OK AGILE CMMI

Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies.  Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog, et par la désignation d’un Product Owner (disponible). Cette pratique m’est très utile car elles la question des moyens est souvent un facteur d’échec des projets agiles. Avec cette pratique, on gagne en maturité. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.

REQM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des exigences…
OK AGILE CMMI

C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? Cela revient à décrire brièvement  le rôle de Product Owner …
Qui : ScrumMaster.

REQM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des exigences…
OK AGILE CMMI

Cela fait partie de mon travail de coach Agile. Dans ce cas précis, cela passe par la mise en place de formations et ateliers dédiés au Product Owner, aux testeurs, à l’équipe.
Qui : Coach Agile.

REQM-GP2.6  Placer les produits d’activité identifiés du processus Gestion des exigences au niveau de contrôle approprié…
OK AGILE CMMI

Comme sur tous les projets informatiques … Il s’agit du niveau de configuration d’éléments comme le Backlog de produit ou les User Stories. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : Product Owner, ScrumMaster.

REQM-GP2.7  Identifier et impliquer les parties prenantes concernées par le processus Gestion des exigences…
OK AGILE CMMI

Un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le Product Owner est l’acteur principal sur laquestion mais, l’équipe (en particuliers les testeurs) est fortement partie-prenante. Business analysts, Ergonomes, Utilisateurs… sont aussi concernés.
Qui : ScrumMaster.

REQM-GP2.8 Suivre et contrôler le processus Gestion des exigences …
OK AGILE CMMI

Cette pratique consiste à suivre l’avancement des activités de gestion des exigences sur la base d’indicateurs. La fin du sprint est un jalon essentiel avec la collecte de données : sur les user stories (Done / Ready), le burndown chart, les changement sur les stories…. Cela fait partie « par défaut » des attributions du ScrumMaster.
Qui : ScrumMaster

REQM-GP2.9  Évaluer objectivement  le respect du  processus Gestion des exigences…
OK AGILE CMMI

Relié aussi au GP2.2. C’est du QA. Le ScrumMaster est le garant de la bonne application du Process Agile sur le projet. Cela fait partie « par défaut » de ses attributions. Maintenant attention, le Process Agile est adaptatif…
Qui : ScrumMaster.

REQM-GP2.10 Revoir l’état du processus Gestion des exigences avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI

C’est à la fois donner de la visibilité et  remonter des problèmes potentiels à la hiérarchie. C’est justement le rôle du ScrumMaster (le « Chien de berger ») qui doit aussi protéger l’équipe et faire remonter, les obstacles éventuels soulevés par l’équipe (par exemple en Daily Scrum). Il peut s’appuyer sur des éléments du radiateur d’informations, burndown chart et fiches de Sprint pour donner de la visibilité à sa hiérarchie sur cette question des exigences.
Qui : ScrumMaster, Product Owner, Hiérarchie

REQM GG3 : Institutionnaliser le processus en tant que processus ajusté
OK AGILE CMMI

Comme précédemment, pas facile mais nécessaire (pour la maturité 3). On est plus que jamais dans du Process Agile…on est dans du standard mais dans une perspective qui me plaît bien, c’est à dire adaptative et non figée, fondée sur l’amélioration continue.

REQM-GP3.1 Établir et maintenir un processus Gestion des exigences ajusté
OK AGILE CMMI

Une description du processus Agile « standard » de l’entreprise doit être disponible .Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé).  On est en plein dans de l’AGILITE en CONTEXTE.
Définir le Process Agile standard, de manière collaborative et participative (jamais seul !)cela fait partie de mon travail.
L’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe et le Product Owner.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes

REQM-GP3.2 Collecter l’information d’amélioration du processus Gestion des exigences
OK AGILE CMMI

Le projet doit se servir de retour d’expérience à la fois pour le Process Standard et pour les autres. C’est très agile, c’est très adaptatif (niveau organisation), et c’est la base de l’amélioration continue. Les agilistes doivent se féliciter de cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes

Une autre référence sur la sujet : Flex”i”MMI

Divergence - Convergence : les deux temps d’une bonne Facilitation

Posté par jc-Qualitystreet le 1 octobre 2009

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.
Mon boulot : Bien introduire, proposer un cadre et de multiples techniques pour faciliter l’exploration et encourager la pensée divergente.
Mon premier message : « Diverger c’est se plier à 5 règles de base » :

1. Suspendre le jugement
2. Chercher la quantité
3. Oser
4. Combiner, associer les idées
5. Tout noter

CONVERGER, c’ est resserrer et faire des choix judicieux.
Mon boulot :  Guider vers l’élaboration, aider à la sélection, à la priorisation, Rationaliser autour de critères ou d’objectifs précis
Mon premier message : «Converger c’est se plier aussi à 5 règles de base »:

1. Se référer aux objectifs
2. Améliorer les idées
3. Juger constructivement et avec des critères
4. Chercher l’inédit
5. Etre déterminé

La clé : multiplier les techniques aussi bien sur des réunion ou ateliers d’1heure que sur une série de RDV !
Faites preuve de créativité.