Vers une autre structure projet

Publié le 12 avril 2012 par pierrefauvel

SOUS-SYSTEMES
Couper un système en deux crée deux sous-systèmes et une interface, une surface de frontière commune aux deux systèmes.
Cette interface va engendrer du gaspillage, au sens lean du terme.

MODE PROJET MULTI-ORGANISATION
Exemple caricatural mais réaliste : une entreprise confie la rédaction des spécifications à un premier sous-traitant, la réalisation des développements à un second, la recette des développements à un troisième. Sois trois sous-systèmes. Je vous laisse dénombrer le nombre d’interfaces.
Ici, le découpage créer des sous-système appartenant à des organisations différentes (au sein ou non du même groupe, il ne s’agit pas nécessairement de SSII), ce qui « durcit » les interfaces : les organisations parentes ayant des objectifs différents, elles « blindent » leurs points de contact avec les autres.

CONTRATS D’INTERFACE
Pour chaque interface, ce découpage engendre un besoin de formalisation de « contrats ». Cahier des charges, spécifications fonctionnelles détaillées, cahier de tests détaillés, etc… Le summum étant le contrat au forfait.
Ces contrats engendrent la nécessité de formaliser à l’excès un échange d’information qui pourrait être plus fluide, rester à un niveau synthétique, être complété de manière « ad hoc » dans un wiki, le meilleur passage de connaissance restant le biseau, en synchrone, formation des nouveaux par les anciens.

L’ESPRIT DU MODE PROJET
Le découpage crée la nécessité de pouvoir stocker une information pour la restaurer plus tard dans d’autres contextes (chez un sous-traitant qui n’a pas participé à l’effort initial d’élaboration de l’information, au tribunal pour justifier de ce qui avait été convenu, …) créer une formalisme qui serait –sans cette nécessité- inutile. La source de ce besoin en formalisme est la nature asynchrone de l’utilisation de l’information par les différents sous-systèmes.
Du coup, l’idéal est d’appliquer le principe du mode projet (que l’on soit en interne ou avec des ssii partenaires) selon son esprit : Tous à bord, tous dans le même bateau. En régie. Dans les mêmes locaux.

SYNCHRONISATION
Ce découpage en sous-entités engendre aussi un besoin de synchronisation dans le temps.
Du coup chacun va publier son planning, ses jalons. Et déployer une énergie phénoménale à se synchroniser avec le planning des autres,
prendre des marges en annonçant ses dates et freiner des quatre fers à l’idée du moindre changement.
Changer une ampoule passe de 10 minutes à 3 semaines.

DISCONTINUITE DU PROJET
Autre exemple, caricatural mais réaliste lui aussi.
On n’a pas le budget qu’il me faut pour faire mon projet.
On en réalise un premier tiers cette année.
L’année d’après on en réalise un nouveau tiers.
L’année encore après on en réalise un troisième tiers.
Evidemment, les tiers ne durent pas toutes l’année, donc il y a des trous, pendant lesquels on libère les membres de l’équipe.
Quand on reprend le tiers suivant, on prend de nouveaux intervenants.
Et après le dernier tiers, on passe en maintenance, par une équipe encore différente.
On se retrouve avec un besoin de formalisation décuplé.
Comment faire passer à l’équipe suivante toute la compréhension métier et technique ?
On rédige tout, mais comme on n’a pas le temps de le faire au fur et à mesure, on le fait au dernier moment, en remontant péniblement le temps, avec une piètre qualité.

EXEMPLES D’ALTERNATIVES

  • Prendre moins de monde (sacrifier les délais) pour garder les personnes en continu. Dans mon exemple, faire des tiers mieux étalés dans le temps, de façon à conserver l’équipe. Le « sacrifice » est donc d’étaler aussi les livraisons, donc d’avoir la release moins vite.
  • Embarquer un membre de l’équipe support dans le projet.
  • Embarquer un membre de l’équipe projet dans le support.

 

PRAGMATISME DANS LA STRUCTURE DE L’EQUIPE PROJET
La nécessité de gérer la complexité d’un gros projet est indéniable. Le découpage en équipes est inévitable.
Ce découpage est fait pour des raisons commerciales (client / fournisseur), politiques, historiques, … que je peux comprendre mais qui aboutissent à un résultat qui n’est pas toujours optimum.
L’organisation d’un projet, calque parfois à tort sur la base de l’organigramme de l’entreprise (découpage fonctionnel, business d’un côté, IT de l’autre)
et pas sur un découpage ad hoc (feature teams).
Ce qui devrait compter, à tous les niveaux, y compris pour l’organisation, c’est la seule efficacité du fonctionnement du projet !

DYNAMIQUE DE LA STRUCTURE DU PROJET
Et puis il y a l’aspect dynamique : J’ai visité il y a très longtemps un projet où les intervenants n’avaient pas de bureau fixe, où ils se regroupaient selon le sujet du sprint, afin d’optimiser les échanges. Cela m’avait impressionné.
A un niveau plus avancé : plutôt que de décréter ce qui sera efficace, faire intervenir les uns et les autres dans l’élaboration, sans y passer trop de temps, faire un essai, éprouver, faire un retour, changer ce qui a été élaboré, … Mais cela suppose que l’on admette que l’on ne sait pas et que l’on refuse de plaquer des organisation importées d’autres contextes, même si elles sont popularisées.

Publié dans Agile, Entreprise, Humain | 1 commentaire

Transformation agile agile : Les besoins et la valeur

Publié le 19 février 2012 par pierrefauvel

Deuxième post d’une série sur la question : « la transformation agile de l’entreprise est-elle elle-même agile ? »

Je contribue à la transformation agile d’un grand compte industriel, au sein d’une équipe de 5 coaches. Cette série de post est un retour d’expérience visant à visiter mon retour d’expérience à l’aune des principes agiles. Un trait récurrent est de remettre en question l’applicabilité au pied de la lettre d’une analogie entre l’activité de transformation agile elle même et un projet gérable par Scrum (méthode agile la plus classique), tout en redécouvrant  les principes du manifeste agile.

La définition du produit : « Business people and developers must work together daily throughout the project »

Dans scrum, la définition du produit est assumée par le product owner, qui sait obtenir de ses interlocuteurs côté utilisateurs une compréhension du besoin et sait définir une vision. Ici en revanche la responsable au sein de l’entreprise de la transformation n’est pas forcément à même de se forger une vision. Elle a besoin de contributions de conseil que nous, prestataires consultants, fournissons. S’il fallait appliquer l’analogie, nous serions dans une situation où l’équipe est parfois plus compétente que le product owner sur la nature des actions à entreprendre. Du coup, que fait-on ? Lors d’atelier et d’échanges, la connaissance des rouages de l’entreprise va à la rencontre du savoir faire agile, et des propositions en sortent. En revanche, elle a la décision finale.

Le périmètre des sprints : « Welcome changing requirements, even late in development« 

Nous nous astreignons à tenir des itérations de un mois, validées par des démos.Or, il apparaît que de nouveaux besoins apparaissent souvent en cours d’itération, des opportunités de prêcher la bonne parole en adressant tel ou tel aspect non couvert jusque là. La décision est souvent d’accepter ces besoins.

S’il fallait appliquer l’analogie, nous serions en infraction avec le principe de protection du périmètre de l’itération, qui ne doit pas changer en cours.

Pour nous c’est différent : ok pour accepter ces nouvelles actions, après tout elles seront démontrées à la fin et illustrerons bien l’avancement, quitte à ne pas faire tout ce qui était prévu si ce n’est pas urgent.

Du coup nous passons à un mode un peu plus Kanban, en observant tout particulièrement la durée entre le début et la fin d’une action, et en limitant le nombre d’actions entamées à un moment donné.

Mesure de la valeur acquise : « Working software is the primary measure of progress. »

La démo, auprès d’un certain nombre d’acteurs côté DSI sanctionne l’effort, l’existence des livrables produits, pas vraiment le déploiement de l’agilité (comme « software » à installer dans les esprits).

Une vision qualitative nous vient de nos ateliers communautaires ou conférences de types « Open Space Technology ».

Pour être vraiment rigoureux, il faudra disposer de PKI (Indicateurs clefs de performance) sur les projets agiles et sur les autres, et comparer l’apport de l’agilité. Nous ne mesurerions pas notre action de transformation isolément, son impact étant confondu avec celui de l’agilité.

Une autre approche, que nous allons mettre en oeuvre, est de systématiser des revues de l’agilité des projets, et d’en agréger les résultats pour voir leur évolution dans le temps par exemple. Cet outil nous permettra plus précisément de voir l’impact de notre action. En revanche, il s’agira plus d’une évaluation de l’adoption (rendre les projets agiles) que de la transformation (rendre l’entreprise agile dans son ensemble, y compris le business, l’infrastructure, …)

Publié dans Agile, Entreprise, Humain | Laisser un commentaire

Transformation agile agile : process & tools

Publié le 2 décembre 2011 par pierrefauvel

Premier post d’une série sur la question : « la transformation agile de l’entreprise est-elle elle-même agile ? »

Dans le manifeste agile: « Les individus et leurs interactions plutôt que les processus et outils ». Pourtant, sur une transformation d’un grand compte :

plutôt que les outils
Nous déployons Jira + Greenhopper, comme unique alternative autorisée à l’utilisation d’Excel, avec 2 variantes : Seulement les user stories dans Greenhopper (qui contient donc le Product Backlog), ou bien les user stories ET les tâches (notamment pour les projets distribués). Donc tous les projets vont avoir le même outil, imposé. Est-ce que la perte de cette latitude de choisir l’outil est un drame ? Il y a des avantages : mutualiser le support sur l’outil, d’éventuels plugins développés une fois pour toute. On change de dimension. Ce n’est plus le projet, mais la DSI qui adopte un outil. Il est indéfendable d’expliquer au management de la DSI que l’on va prendre des outils différents pour différents projets, que chaque projet va concevoir un choix d’outil.

Encore faut-il que cette mutalisation se nourrisse vraiment des remontées et besoin du terrain. Que périodiquement les représentants (le Scrum Master) de chaque projet rencontre le coach responsable de cet outil, une sorte de « scrum de scrum », bref des interactions. On a bien un projet jira avec les demandes d’évolutions de l’outil mais ça ne remplace pas les échanges.

plutôt que les processus

L’entreprise bénéficie d’un réseau d’ingénieurs qualité, qui effectuent des revues de qualité des projets à certains moments de leur déroulement. Ils vont le faire notamment pour les projets agiles. Dans le cadre de la transformation, un travail a été fait avec eux sur les questions à se poser, et nous a amené à formaliser un référentiel agile. Il ne s’agit pas vraiment d’un processus figé, mais d’une description du framework Scrum, des pratiques d’ingéniérie tirées d’Extreme Programming et des spécificités de l’entreprise. L’approche est très proche de Scrum en tant que framework. C’est ce qui nous sauve : il y a largement place à interprétation.

Pourquoi ne pas utiliser directement le Scrum Guide ? ou le bouquin de Claude Aubry ? Cela vient des objectifs de ce référentiel. Les ingénieurs qualité sont supposés être compétents pour évaluer la bonne adéquation d’un projet à l’agilité. Ils sont supposés être formés, et avoir le même regard qu’un coach qui auditerait le projet. Le but est pour eux d’avoir une référence. Le référentiel est là à but normatif, pour poser des règles à respecter, pas pour enseigner expliquer comment faire. Nous nous sommes efforcés d’avoir un ensemble de règles cohérent & souple, avec juste ce qu’il faut de contrainte pour indiquer la direction aux projets.

L’ingénieur qualité collecte des preuves (fut-ce lors d’entretien) du respect des règles. Le référentiel ne dit pas comment s’y prendre. La réelle difficulté, et c’est comme pour CMMI, réside dans le fait qu’un ingénieur qualité fonctionne sur la base soit de preuve, soit d’entretiens très brefs, et que ni l’un ni l’autre ne se substituent au retour que peut faire un coach par exemple. Du coup nous (coach) participons aux revues. Que se passera-t-il quand la transformation sera finie ? quand l’entreprise décidera de réduire le coaching qui sert actuellement à déployer l’agilité ? Est-ce que les revues ne se baseront plus sur les traces d’exécution d’un processus (les livrables) et moins sur une évaluation fine du fonctionnement de l’équipe ? Et où iront les responsables qualité chercher leur connaissance de l’agilité ?

Quand je regarde ce que j’ai pu apporter aux projets que j’ai coachés, c’est 20% de forme, de respect des règles du processus Scrum, et 80% de fond, d’état d’esprit. Difficile de résumer l’état d’esprit agile dans une checklist destinée à être appliquée par des personnes qui n’ont jamais participé à un projet agile ni été Scrum Master. C’est peut-être au fond une limitation de l’agilité, plus difficile à généraliser dans une entreprise qu’un processus lourd comme UP.

Publié dans Agile, Entreprise | 1 commentaire

ALM : Les cordonniers sont les plus mal chaussés

Publié le 9 novembre 2011 par pierrefauvel

L’ALM (Application Lifecycle Management) dénomme des solutions du marché qui ont l’ambition de tout gérer : expression de besoin, spécification, code, tests, traçabilité entre tous ces aspects. J’approche l’ALM avec un postulat simple :

Les projets sont des entités organisationelles qui ont chacune besoin de son propre SI

Partant de là, je vois un parallèle (un peu abstrait) à faire entre :

  • informatiser une entité organisationnelle (par exemple la direction commerciale / turbine à qui on fournit une série d’applications, plus ou moins liées, pour se gérer)
  • informatiser un projet de développement informatique (fournir à un projet une série d’application, plus ou moins liées, pour se gérer)

Une sensation de déja vu, comme le chat noir dans Matrix.

Des échanges récents chez mon client actuel m’ont replongé dans mon passé. J’avais, à la demande d’un autre client, essayé d’utiliser Caliber RM (un outil de gestion d’exigence) pour outiller la traçabilité de bout en bout des projets (y compris stocker des risques ou des liens vers des cas de tests). Là, on aimerait utiliser la suite Atlassian (wiki confluence + gestionnaire de tickets jira) pour gérer tout, les scénarios de tests, etc…

Les objets métier d’un projet informatique

Un projet informatique (un minimum complexe) gère des objets « métier » : user story, backlog, scénarios de test, rapports d’exécution de test, bugs, … Il y a des principes d’associations entre ces objets, d’où la fameuse traçabilité : être par exemple capable de pouvoir dire qu’il n’y a plus aucun bug portant sur cette user story. Etre capable de dire que toutes les user stories de la release ont été testées (ça s’appelle chercher des trous dans la matrice de traçabilité).

La charrue avant les boeufs.

Sur un projet informatique, on commence par réfléchir au besoin, recenser les story, etc… Pourquoi ne pas faire pareil ? Commencer par recenser les user story de notre SI projet ?

En tant que développeur, je peux de manière transparente associer un commit à une user story et ou à un bug.

En tant que scrum master, je peux obtenir un rapport d’avancement des tests d’acceptance par le business.

En tant qu’ingénieur qualité, je peux obtenir un rapport d’exécution des tests automatisés et manuels pour chaque version

Etc…

Intégration entre les outils

A chaque fois, on se perd dans les détails de tel ou tel outil. Comme un projet se perdrait dans les détails d’intégration ou de flux entre outils.

Dans l’idéal, il faudrait une combinaison miracle d’outils, chacun étant accessible par service web, en consultation, en modification. Chacun étant capable d’accéder à d’autres outils par service web ( par exemple pour pouvoir sélectionner une user story dans le backlog afin de l’associer à un cas de test).

Mais n’est-ce pas un leurre ? Est-ce qu’on ne peut pas se contenter d’un champ en saisie libre où l’on mettrait l’identifiant de la story. C’est moins bien (risque d’erreur contrôlé a postériori), mais ça peut être tolérable dans certains cas.

Où est le product owner capable d’arbitrer ça ?

Alors il y a les grands comptes qui peuvent se permettre des suites (hors de prix). Et les autres qui bricolent, comme ils peuvent.

Spécifique

J’ai une tendance à préconiser du spécifique à chaque projet, par opposition à une « cellule transverse » qui spécifierait et mettrait en place la solution d’ALM pour tout le monde. Dans mon ancien client, j’avais connu des projets hardware + software, d’autres que software, d’autres de type EAI, bref des configurations qui faisaient que le besoin du projet en solution d’ALM était différent d’un projet à l’autre. Comme on aurait des besoins métiers différents entre des directions métier différentes. Quoi d’étonnant ?

Ca implique surtout d’articuler le besoin

  • Les besoins au niveau de la direction des études : le product owner du SI des projets est le responsable outil/méthodes
  • Le paramétrage de la solution retenu / les besoins spécifiques pour chaque projet : le product owner du SI du projet est le chef de projet/scrum master, avec arbitrages avec le responsable outil/méthodes (souci de capitalisation, d’homogénéité, …)

Rétrospectivement, mon ancien client avait adopté une démarche sensée au niveau entreprise

Analyser le besoin (outils/méthodes + représentants des Chefs de projet/Scrum Master)

  1. Prioriser le besoin (idem)
  2. Sélection des outils sur des critères comme l’ouverture par API, la facilité à synchroniser les données de référence, etc…
  3. Faire un pilote, avec une première intégration des outils (avec le CP comme product owner)
  4. Faire un deuxième pilote, avec une intégration différente (idem)
  5. Capitaliser
  6. Animer une communauté
  7. Intégrer un budget « SI du projet » dans chaque budget de chaque projet.
Publié dans Entreprise | Laisser un commentaire

La doc est un code comme les autres

Publié le 11 octobre 2011 par pierrefauvel

Par documentation, j’entends :

  • documentation utilisateur en ligne ou papier
  • supports de formation (pour les différents auditoires)
  • documentation d’administration fonctionnelle
  • documentation d’installation
  • documentation d’administration technique
  • documentation d’exploitation
  • documentation pour la maintenance corrective et évolutive (notamment design & tests)
  • etc…

Mon propos est que la documentation est comme le code, et devrait être élaborée comme le code. Voici quelques idées qui découlent de ce principe.

Produit

Le corpus documentaire livré avec un projet gagne à être considéré comme un produit en soi.
Cet ensemble de documents doit être cohérent, un jeu de versions cohérent, et cohérent avec une version de chacun des composants de code.
Quelle différence avec un incrément de code, si ce n’est qu’il s’agit de langage naturel et de documents office au lieu de code ?

Traçabilité
Il y a une adhérence entre la documentation et le code, et une modification structurelle, dans le cadre de l’implémentation d’une user story, va engendrer un impact sur la documentation.
Le travail sur chaque user story aura un impact sur la documentation, à plusieurs endroits, mais on ne pourra pas forcément découper chaque document en paragraphe par user story (pensons par exemple à un modèle de donnée pour l’exploitation que l’on ne sait pas ramener à telle ou telle user story).
Il y a la même problématique que pour le code, avec la traçabilité code/user story.
Dans certains cas, il faudra aller jusqu’à tracer le lien entre user story et chapitre de doc (des outils existent), comme on le fait parfois pour les liens entre le code et les user story (dans les commentaires, ou dans les commentaires subversion).

Au fil de l’eau
Quelle différence entre la doc et tel ou tel aspect (au sens POA) que l’on décide de couvrir au fur et à mesure, plutôt que d’attendre à la fin, comme les transactions ou le reporting.
L’idée est de ne plus dissocier dans le temps le design, l’implémentation, la documentation, et d’adopter comme unité de travail la user story de bout en bout.
Comment s’assurer que, si on a décidé de l’écrire au fil de l’eau, la doc l’est réellement ? Comment sensibiliser l’équipe ? Faire des revues documentaires (par leurs destinataires) ?
Ce qui n’est pas revu n’est pas comptabilisé, et la user story correspondante ne l’est pas (Inclure tel incrément de tel doc dans la definition of done).
Une doc qui n’est mise à jour dans un sprint est une dette technique, dont le coût s’alourdit au fur et à mesure qu’on oublie ce que l’on a fait.

Comment se fait il que les développeurs expérimentés, qui ont déjà vu des fins de projets douloureuses, avec une documentation difficile à rattraper dans des conditions budgétaires très tendues, comment font-il pour oublier ça, et recommencent-ils à repousser sans fin la doc à l’itération suivante ?

Refactoring
Le bon niveau de doc rend le code plus facile à refactorer (vue globale du système, analyse d’impact, points de vigilance, …)
Quand on y pense, il est plus facile de réécrire le code à partir de la doc que d’analyser le code pour produire la doc,donc il serait presque plus logique de privilégier la doc sur le code.

Génération
A défaut de se demander si on peut générer une partie de la documentation, on peut l’organiser pour qu’elle soit facile à maintenir.
Une nouvelle fois, il s’agit de réflexions que l’on se fait aussi pour le code.
Si génération il y a, il faut, comme pour le code, quelque part, décrire l’information, la génération n’est qu’une mise en forme.

Auditoire
La doc est un produit, elle a donc a avoir une ergonomie, à être pensée en fonction de l’utilisation qui va en être faîte.
Si la définition de l’auditoire est trop abstraite, pourquoi ne pas définir des « persona » de la documentation, qui matérialiseraient les utilisateurs type, les administrateurs opérationnels type, l’exploitant type, … comme on le fait pour le code.

Négociation
Il faut s’assurer des attentes de l’auditoire.
J’ai vu des forets entières disparaître parce que l’on anticipait à tort les attentes de tel service ou tel organisme de contrôle, sans en débattre avec eux, sans négocier.

Politique documentaire
Définir une politique documentaire concrète et explicite, adaptée au contexte plutôt qu’appliquer une liste des modèles de doc, sans remettre en question l’usage de telle ou telle doc, ou la structure des tables de matière.
L’équipe élabore cette politique sous les contraintes des partenaires, et la revoit au fur et à mesure du projet, en intégrant les retours des lecteurs.

Documentation & Agile

Quand on parle de réduire la doc en agile, on parle de réduire la contractualisation entre les acteurs, pas la doc finale.
On prétend juste que la doc à produire in fine n’est pas la documentation utilisée en cascade pour élaborer le produit, mais bien une documentation adaptée aux personnes qui vont l’utiliser, à jour, cohérente , minimale, optimale, adaptée, fruit d’une négociation avec son lectorat.

Publié dans Agile | 4 commentaires

Ce qui fait une équipe formidable

Publié le 26 septembre 2011 par pierrefauvel

Nous avons tous connu la sensation de faire partie d’équipes formidables. J’ai retrouvé ces derniers mois ce plaisir (comme coach) et je vais vous livrer ce qui me semble en être les caractéristiques :

  • Casting de haut niveau de sélection. Je ne parle pas du nombre d’années d’expérience, mais de la motivation et des compétences (voire des capacités) de chacun. Un individu à la traîne qui ne connaîtrait pas les enjeux finira exclu. Un individu à la traîne mais qui s’approprierait les enjeux pourrait monter dans le train, et en sortir grandi.
  • Des membres curieux d’esprit, ouverts aux autres idées, qui écoutent les autres membres.
  • Du respect, pas nécessairement de l’amitié.
  • Des individus ambitieux, pour eux et pour le projet.
  • La présence d’un ou plusieurs leaders au sein de l’équipe, pour mettre la machine en marche, pour pousser à aller plus loin.
  • La volonté de faire avancer le projet globalement qui pousse ceux qui sont « en avance » à aider ceux qui sont « en retard ».
  • La place laissée (et prise) à chaque membre de l’équipe pour s’exprimer, à sa façon, le moment venu.
  • Un souci partagé de fonctionner comme un système harmonieux, en synergie, tout en n’hésitant pas à débattre tant que nécessaire afin d’aboutir s’il le faut à une troisième voie.
  • Un sens de l’urgence, certains membres qui entraînent les autres vers la nécessité de produire, régulièrement, des incréments livrables, démontrables, quitte à renoncer à certaines subtilités fonctionnelles.
  • Un sens de l’importance du projet, nourrie de rencontres avec les acteurs métiers et les utilisateurs finaux. Une équipe qui partage les enjeux et les objectifs du projet.
  • Un rythme soutenable mais soutenu.
  • Une équipe qui s’éclate.
  • Une équipe qui prend les difficultés à bras le corps.
  • Des moments de déconade sincères pour laisser un peu filer la pression, et partager la joie de travailler ensemble.
  • Une équipe à qui on laisse l’opportunité de s’organiser et qui le fait, collectivement, en remettant sa méthode et son organisation en question tout le long du projet.
  • Une équipe qui débat de ses ambitions (qualité, rythme de livraison, …).
  • Un défi technique, une perspective d’enrichir le CV.
  • Un top management qui met la barre assez haut et pas trop.
  • Un top management qui se rend disponible et sait prendre des décisions.
  • Un middle-management charismatique mais aussi et surtout soucieux du bien-être des membres de l’équipe.
  • Un management présent, pas systématiquement directif, qui rappelle les contraintes et aplanit les difficultés hors du périmètre de l’équipe.
  • Une adoption comprise et sincère de pratiques agiles et lean, adaptée au projet.
  • Du coaching (par un externe, pas par un hiérarchique), pour guider, prendre du recul, et aider à trouver là où ça fait mal.

Je suis convaincu que l’application de l’agilité au sein d’une équipe gagne à avoir une grande partie de ces caractéristiques. Posséder ces garanties n’est peut-être pas indispensable. Posséder ces garanties n’est peut-être pas un gage de succès assuré dans l’absolu. C’est par contre selon moi lié à un voyage en commun mémorable et enrichissant. N’est-ce pas après tout le plus important ?

Publié dans Agile, Humain, Leadership | Laisser un commentaire

Pourquoi passer du conseil au coaching agile ?

Publié le 7 septembre 2011 par pierrefauvel

Une brève réflexion sur la transition du conseil au coaching en agilité.

Publié dans Agile | Laisser un commentaire

My Own GTD Sprints

Publié le 30 août 2011 par pierrefauvel

Since it has been asked for in english by Yves Hanoulle, this short post will be in english ;-)

I started this summer a very simple experiment.
I think that this should sound familliar to anybody practicing agile.

I had for year 2011 a kind of « Getting Things Done » list (as a matter of fact, it is a xmind map, much easier to group, split, … than an excel file).

Now I have also iterations, of 2 weeks. When I start an iteration, I select entries in my GTD list and I split them in concrete short term tasks (that I will be able to do in 2 weeks delay, knowing the fact that I am only working part time on my personal GTD), my sprint list.

Items in my sprint list are more concrete, more simple, don’t need long term thinking.

During my sprint, I take a greate pleasure checking items in the list to mark the fact that they are done. Or de-scoping them to further iterations.

If I find new ideas, I add them to the global GTD list, and I try not to change the scope of the sprint.

What is fun is to feel the power of having 2 level a granularity (PBL Items/Tasks) also for « personal » tasks.

Moreover, the use of a mind map is not innocent : it also helps to collapse items in order to hide their details and get a more synthetic view. Sounds like epics, no ?

It’s like a training where the trainer would ask you :

  • Imagine you make a list of things to do this year.
  • Detail them.
  • Arrange them.
  • Then select some of them for the next two weeks.
  • Split them into concret tasks.
  • Manage them
  • Look at what you have done at the end of the sprint.
  • Retrospect.
  • Start the next sprint.

Except I do it for real.

And it works !

Publié dans Agile, Efficacité, English | 1 commentaire

Réunions (2/..) : 2 coachs valent plus que 4 coachs

Publié le 26 août 2011 par pierrefauvel

Je pratique ces temps-ci à hautes doses des réunions entre coach agiles réalisées chez mon client, pour coordonner nos activités « transverses » (au niveau de la transformation agile elle même, au delà du coaching de nos projets respectifs).

Nous avons constaté un phénomène assez particulier, que nous avons mis du temps à canaliser.
Il peut se résumer à « 2 coachs valent plus que 4 coachs« .

Une réunion à 2 coach sur une activité de transformation est constructive.

Une réunion à 4 coach part dans toutes les directions, change plusieurs fois d’agenda, et pourra être sérieusement contre productive.

J’ai une théorie selon laquelle, à 2 coach on négocie de manière plus explicite et moins fréquente les changements de « mode » d’interaction :

  • la créativité (chacun propose, chacun suit librement ses associations d’idées)
  • le retour d’expérience (une personne raconte)
  • la présentation (une personne expose quelque chose qu’elle a élaboré)
  • la réflexion (une personne réflechit à voit haute)
  • l’argumentation (deux personnes débatent)
  • la meta-communication dans le message élaboré (que vont penser les équipes si on met ça dans le wiki de transformation)
  • les concepts (on essaie d’établir un consensus sur un ensemble de concepts)
  • le paradigme (on essaie d’établir un consensus sur le cadre même de la réflexion)
  • la méta-communication sur l’interaction (on parle de la réunion qui a lieu)
  • la méta-communication sur la relation (on parle des rôles et rapports entre les participants)
  • l’humour
  • …

Les modes changent beaucoup plus vite à partir de 3 coach, et l’ensemble est instable.

Ensuite, je ne pense pas que cela soit un problème d’ego. Je ne pense pas non plus qu’il s’agisse de rigidité intellectuelle, nous sommes tous souples et ouverts. Je pense plutôt à une déformation naturelle.
Le coach est là pour mettre son client, son équipe en mouvement (même en coaching non-directif il y a un transfert d’énergie). Un coach a toujours quelque chose d’intéressant à dire, un recadrage, une reformulation, pour faire progresser.
Difficile de s’arrêter de jouer quand on est en coulisse.

Du coup, il me semble que la nature de la réunion doit dicter le casting.

  • ce qu’il vaut mieux préparer seul
    • élaboration d’un contenu non structuré
  • ce qu’il vaut mieux préparer à deux
    • revue de détail d’une présentation
    • structuration, articulation d’un contenu
  • ce qu’il vaut mieux préparer à plus de 2
    • partage
    • brainstorming très « ouvert », très en amont
    • planification
Par ailleurs, nous nous réfrenons tous :-)
Ca me rappelle « The secrets of consulting » de l’excellent Gerald Weinberg : la meilleure façon de raccourcir la durée d’une réunion à laquelle on participe c’est de se taire.
Publié dans Agile, Efficacité, Humain | 5 commentaires

Réunions (1/..)

Publié le 12 août 2011 par pierrefauvel

Voici ce que nous faisons (ou devrions faire) sur nos réunions. C’est assez bateau mais cela va mieux en le disant :

Avant

  • Une invitation est envoyée : date et heure de début, durée, agenda, contexte (supports, lien vers le compte rendu des réunions précédentes)
  • L’animateur de la réunion arrive à l’avance, et s’assure du matériel : le cas échéant vidéo projecteur, paper board, whiteboard, marqueurs, post-its, papier krafts, stylos, portable branché sur le cable vidéo, sur son alimentation, télécommande du portable.
  • L’animateur dispose les tables dans la configuration qu’il a conçue si ce n’est pas la configuration standard de la salle
  • L’animateur affiche au mur les rappels des principes de la réunion (open space, brainstorming, …)
  • Les participants arrivent en ayant pris connaissance du contexte qui leur a été fourni en pièces jointes de l’invitation
  • Les réunions sont préparées par les acteurs : finalisation des actions attendues (notamment collecte d’information)

Début

  • La réunion démarre à l’heure prévue (même si tout le monde n’est pas là), cela poussera chacun à venir à l’heure
  • L’animateur rappelle l’objet de la réunion et propose l’agenda, qui restera visible pendant toute la réunion

Pendant

  • La réunion a un time keeper. Il rythme la réunion avec dynamisme. Il surveille le temps qui reste par rapport à la vitesse constatée. N’est pas forcément l’animateur, mais gagne à l’être, notamment si l’animateur est un facilitateur et pas un opérationnel.
  • La réunion a un seul animateur, pas plus
  • La réunion a un secrétaire qui produira le compte rendu ou édite les documents. N’est pas forcément l’animateur.
  • Pendant la réunion, un indicateur de l’avancement et du temps restant est évalué et partagé
  • Une seule conversation est tenue à la fois (pas d’aparté)
  • Des pauses (de durée stricte) ont lieu, donc le reste du temps les participants ne s’absentent pas de la réunion
  • On note les sujets hors agenda, mais on ne les traite pas
  • A part le secrétaire, personne n’a son portable ouvert. les documents à partager avec le groupe auront été transmis au secrétaire au préalable
  • On ne se coupe pas la parole
  • On ne monopolise pas le temps de parole (on ne parle pas plus de 2min sans passer la main)
  • Tout le monde a le droit à la parole
  • Tout le monde a le devoir de participer
  • Les conversations qui s’éternisent et qui ne sont pas bloquantes pour la poursuite de la réunion sont arrêtées par l’animateur, qui les note pour qu’elles soient traitées à part
  • L’animateur formalise tout le long de la réunion les tâches (qui, quoi, pour quand)
  • Au fil des sujets l’animateur fait le point sur les tâches des réunions précédentes

Fin

  • L’animateur collecte les informations : prend en photo les murs de post-its, roule les papier kraft, prend en photo le whiteboard, récupère les papiers du paperboard
  • L’animateur (aidé par certains participants) remet en état la salle : efface le white board, remet les tables en place, …
  • La réunion se termine à l’heure prévue (même si on n’a pas fini dans les temps), cela poussera le groupe à apprendre à gérer son temps
  • La réunion donne lieu à un compte rendu de décision diffusé à tous, en plus d’une éventuelle mise à jour de supports (backlogs, …)

Après = Avant

A suivre…

PS: Plus j’y pense, et plus j’ai envie de relire « Collaboration Explained: Facilitation Skills for Software Project Leaders » de l’excellente Jean Tabaka.

Publié dans Efficacité, Humain | 1 commentaire

Agile, Lean, CMMI : Amélioration, Norme, Evaluation

Publié le 12 mai 2011 par pierrefauvel

Les méthodes Agile :
Le projet tend à s’améliorer

  • L’équipe apprend à s’organiser sous les contraintes du projet, et cet apprentissage est rythmé par les rétrospectives.
  • Que dire des autres projets agiles au sein de la même organisation ? Une communauté agile émerge quand l’organisation déploie l’agilité, des échanges ont lieu, mais je ne suis pas sûr qu’une norme émerge, il s’agit plus de retours d’expérience (essais et erreur).
  • Chaque projet est libre de ses choix, tout en bénéficiant de retours d’expérience des autres projets
  • Il n’y a pas de niveau d’agilité dans l’absolu, car il n’existe pas dans la « nature » de modèle agile standard.
  • S’il y a des audits par un coach agiles, c’est par l’observation et non par l’étude de preuves écrites.

L’approche CMMI :
L’organisation apprend à s’améliorer.

  • Elle décrit ses processus, apprend à les exécuter, les contrôler, les optimiser. Des dérogations justifiées sont cependant possibles.
  • Son apprentissage est rythmé par les évaluations (par exemple Scampi), et sanctionné par un niveau (que l’on gagne pour 3 ans), car il existe un modèle CMMI standard décrivant ce que l’on s’attend à ce qu’une organisation mature gère (pas forcément comment elle le met fait)
  • Les évaluations reposent sur la traçabilité (la collecte de preuves sous forme de documents).

Lean Software Development
Des pratiques d’amélioration continue issues du manufacturing, qui s’étendent à la conception de produits (Lean Product Development) et pourquoi pas au software (Lean Software development).

  • Elimination des gaspillages (à tous les niveaux)
  • Rangement du poste de travail (et par extension du code et du référentiel documentaire)
  • Optimisation globale et non locale à une activité.
  • Etc…

Il ne s’agit pas forcément d’un processus structurée mais plus d’une grille (d’une méthodologie ?) d’identification d’axes d’amélioration et des techniques allant dans ce sens.

Je rêve de projets agiles qui s’améliorent en appliquant les grilles Lean à leurs rétrospectives, au sein d’une organisation
qui applique un CMMI ajusté (par rapport aux preuves, par exemple),et qui anime une communauté de pratiques agiles,et utilisera en particulier la possibilité de décrire, pour chaque règle ou pratique qu’elle aura cru bon de formaliser, dans quelle configuration projet on doit ou ne doit pas l’utiliser.

L’organisation elle même s’appliquera Lean, pour améliorer son organisation par exemple.

Publié dans Agile | Laisser un commentaire

Je soutiens le référentiel « Institut Agile »

Publié le 4 mai 2011 par pierrefauvel

(et bravo à Laurent Bossavit qui a fondé et anime ce vénérable institut)

Publié dans Agile | Laisser un commentaire

Open Space Technology – La communauté agile chez X (REX)

Publié le 3 avril 2011 par pierrefauvel

Nous avons appliqué le principe de l’Open Space Technology (ou Forum Ouvert) chez X. Je vous livre ci dessous ce que nous avons fait et ce que nous n’avons pas bien fait (je vous laisse deviner) :

AVANT
– préparer la salle (chaises, post-it vierges, instructions, numéros des salles, rôles)

PENDANT
– café, jus d’orange pour chauffer l’ambiance
– speech d’introduction par le sponsor du forum ouvert (objectifs)
– speech de présentation des modalités du forum ouvert (par Jean-Claude)
– collecte des sujets : les membres de l’assistance se levent, montent sur l’estrade, disent leur sujet, collent leur postit
– organisation : regroupements des post-its
– vote : chaque membre de l’assistance vote pour 3 groupes de post-its
– sélection des 8 groupes ayant reçu le plus de votes, affectation aux sales et aux animateurs
– 4 x 2 sessions dans 4 salles. L’animateur anime, ne donne pas d’avis, note les idées.
– debrief à l’ensemble en 3 minutes par session par l’animateur
– plan d’action immédiat
– rétrospective
– roti
– pendant toute la durée : profiter de l’expérience

APRES
– récuperer les post-it géant en marquant sur chacun le nom de la session & un numéro qd il y en a plusieurs
– ranger les salles avec le public
– debrief à chaud, plan d’action court terme
– saisir sous informatique (xmind puis word) les idées, et constater la richesse du résultat
– débrief à froid, plan d’action long terme

Sensations :
– vraiment très sympa
– Jean-Claude sait insuffler beaucoup d’énergie, maîtrise le format, maîtrise l’agenda et le timing (cf son article sur QualityStreet)
– grande mobilité du public
– intéressant de voir que l’on peut avoir 50% du public par moments et 2 personnes à d’autres moments

Publié dans Agile | Laisser un commentaire

Prez « Indicateurs agiles » : Rex

Publié le 26 mars 2011 par pierrefauvel

Un (modeste) retour d’expérience récente de présentation interactive à la CARA

Ce que j’ai fait et ce que je n’ai pas fait (je vous laisse deviner)

AVANT

  • faire une pub ciblée avant
  • se mettre d’accord clairement sur qui fait quoi (en préparation, et pendant la conf)
  • bûcher son sujet
  • non vraiment, bûcher son sujet pour être parfaitement clair dans les explications que vous donnerez
  • et le bûcher aussi pour pouvoir inter-agir avec vos pairs, si vous en avez dans l’assistance
  • penser l’articulation de la présentation (un plan simple et clair)
  • éviter l’abstrait
  • épurer ses slides à la présentation zen
  • lire, relire, re-relire, compléter, affiner, alléger, en remettant plusieurs fois votre ouvrage sur le métier, et en s’y prenant suffisamment à l’avance

PENDANT

  • prévoir 50% de discussion
  • lancer la discussion très tôt (prévoir des alternances de présentation et de question)
  • ajuster le tir quand on voit que ça démarre mal (ne pas coller à l’organisation prévue si elle n’est pas pertinente)
  • gérer la cohérence avec votre idée de la conf et ce que dit le co-présentant (pas toujours évident)
  • gérer votre fatigue (c’est plus simple en co-présentant)
  • gérer les bavards
  • gérer les silencieux
  • gérer le temps
  • rester présent tout le long

APRES

  • obtenir un retour de l’assistance
  • profiter du pot qui suit pour rencontrer, échanger (sans se limiter au sujet)
  • obtenir un débriefing détaillé d’un proche

TOUT LE TEMPS

  • Surtout profiter de l’expérience !
Publié dans Agile | Laisser un commentaire

Distinguer, regrouper, articuler

Publié le 14 février 2011 par pierrefauvel

Quand on est plongé dans un contexte, avec ses particularités (et ses concessions dues à l’organigramme), on perd un peu le nord, la vision claire, les concepts et les rôles se mélangent ou se scindent artificiellement

Distinguer

  • Exemple 1 : le product owner doit gèrer le « quoi », l’équipe (animée par le scrum master) doit gérer le « comment ». Le product owner exprime des besoins, des histoires utilisateurs, l’équipe fait des maquettes et des suggestions. On se laisse par exemple facilement embarquer dans des situations où c’est le product owner qui fait des maquettes (ne serait-ce que pour échanger avec les utilisateurs), avec les implications que cela peut avoir en terme de faisabilité et de coût.
  • Exemple 2 : dans le cadre d’un contrat, l’estimation « vendue » qui correspond plus à une évaluation du prix que le client est prêt à payer pour la fonctionnalité et l’estimation par l’équipe, qui vient souvent plus tard et qui correspond au coût de réalisation objectif, à la complexité réelle.

Regrouper

  • Exemple 3 : les tests. Quand on implémente une fonctionnalité à base de flux, on est bien obligé de la tester sur des fichiers de données, dans le cadre même des tests unitaires ou d’assemblage des différentes couches. A quoi bon séparer dans ce cas les tests dits « fonctionnels » ou d’intégration et les tests unitaires ? Une approche à base de fitnesse réconcilie les deux, en fournissant à l’équipe les données avec lesquelles tester. Mais cela suppose que l’on admette qu’il y a une étape de test unitaire et une étape de test d’intégration.

Articuler
Exemple 4 :  On entend tout et n’importe quo sur XP, Scrum et Lean Software Development, sans parler de Software Craftmanship.

  • Scrum est venu après XP, ceux qui l’appliquent s’inspirent souvent de XP pour les sujets que Scrum ne couvre pas.
    Scrum ne couvre pas tout (en particulier par les activités d’ingéniérie), pour lesquelles certaines pratiques xp restent pertinentes. Il faut aussi considérer les pratiques plus modernes (TDD, TDR), voire Software Craftmanship.
  • Scrum est un processus de développement, ce que XP faisait de manière plus diffuse, moins formelle.
  • Scrum et XP viennent en partie du Toyota Way, repris de manière peut-être plus directe par Lean Software Development.
  • Scrum est plus adapté pour les developments (orienté quantité de valeur métier que l’on arrive à faire rentrer dans un plan de charge), Lean (en particulier l’approche Kanban (pull) ) pour la maintenance (orienté délai de prise en compte des demandes métier).
  • Certains débats sur Software Craftsmanship le voient comme un mouvement post-agile. D’autres comme une approche hyper-rétrograde. Selon moi, le Software Craftsmanship est dans la continuité de XP : une réflexion innovante sur les pratiques d’ingéniérie. Le débat avec l’agilité consiste « juste » à trouver un équilibre (enfin) entre livrer de l’utile au plus vite et maîtriser la capacité à livrer de l’utile par la suite.
  • Etc..

Chers lecteurs, à vos claviers !

Publié dans Agile, Pensée | Laisser un commentaire

Offres, Centres de Compétences et Business Unit

Publié le 3 février 2011 par pierrefauvel

Une offre c’est une marque, un produit (ou une famille de produit). Elle a une unité, une cohérence. Elle a une valeur ajoutée par rapport à la concurrence. Elle a un marché, i.e. un ensemble de clients types intéressés par l’offre. Elle a donc une dimension spécifique pour les clients de son marché, que l’on va mettre en avant au moment de démarcher les clients. Pour produire une offre, il faut savoir la produire, et savoir la produire de mieux en mieux (pour être de moins en moins cher). Capitaliser, produire du code réutilisable, voire des modèles de données réutilisable, des livrables type, …

Un collaborateur d’une SSII (à part peut-être les plus seniors ou les managers) se spécialise plus ou moins par plateforme ( jee / .net / php ), voire par produits. Il est naturel de recenser les collaborateurs experts en weblogic portal, ou plus généralement en portail, animer leur réflexion, leurs échanges, leur veille techno, le code réutilisable, les frameworks maison. Naturellement donc les effectifs devraient appartenir à une (ou plusieurs) cellules de veille, cellules archi, … appelons ça « centres de compétences ». Rien ne rend nécessaire de confondre l’offre et le centre de compétence. Un centre de compétence « portail & CMS » pourrait servir plusieurs offres.

Enfin, il y a l’approche manageriale. Chiffre d’affaire, marge, intercontrat. Pour piloter « numériquement » l’activité, il faut des frontières autour d’entités, chacune étant supposée rentable. A la base il y a le projet (avec un chef de projet dont le variable dépend de l’issue du projet), mais dont la durée de vie est limitée. L’entité stable est la « business unit » qui regroupe quelques dizaines de  collaborateurs et qui doit être auto suffisante, quitte à « sous-traiter » pour d’autres business unit. A sa tête, un manager, dont le variable dépend (entre autres) des chiffres de la business unit. Les business unit s’empilent (business unit, département, agence, groupe). Il n’est pas évident que les offres doivent toutes être matérialisées par une business unit (avec des collaborateurs exclusivement dédiés). Pourquoi pas une approche matricielle ? Un centre de compétence peut être transverse, aussi (mais difficile alors d’en garantir le budget, la pérénité).

De la claire articulation entre ces 3 concepts (catalogue d’offres, liste des centres de compétence, hiérarchie des business unit) dans une organisation dépend :

  • la pertinence de l’action commerciale et d’avant vente sur les offres, et donc leur pourcentage de réussite
  • la formation continue, l’émulation des collaborateurs et un faible turnover
  • la rentabilité gagnée en focalisant les énergies du management vers la rentabilité d’un périmètre clair

Exemple d’offres : par secteur (l’assurance, les labos pharmaceutiques) et/ou par problématique (le tunning de performance, les applis de gestion de contrat d’assurance)

Exemple de centre de compétences : la mobilité, la « stack » Spring, l’AMOA, la TRA, …

Une approche cohérente serait d’avoir des centres de compétence assez larges, qui contribueraient chacun à un certain nombre d’offres (s’appuyant potentiellement sur plusieurs centres).

Après, reste :

  • à trouver la bonne organisation en business unit pour répartir les gens (au moins par centre de compétence, mais ce n’est même pas évident. Mes missions sont variées et couvrent plusieurs centres)
  • à mettre en place un suivi quantitatif des offres : investissement, effort de prospection, résultats, chiffre d’affaire, … mais même ça c’est discutable : pourquoi une bu ne prendrait-elle pas le risque d’investir lourdement sur une offre peu viable au début (parce que c’est l’avenir, parce que l’on dispose de la compétence…) en la financant par les autres ?

Tout ceci a surement l’air un peu banal, mais « quand on est dedans », il n’est pas toujours facile d’y voir clair.

Publié dans Entreprise | Laisser un commentaire

Inception

Publié le 29 janvier 2011 par pierrefauvel

Il ne s’agit pas du film, plutôt du sens qu’avait le mot dans les phases du Rational Unified Process mais appliqué à tout activité intellectuelle.

Les livres sur le brainstorming, une technique de créativité collectivent, illustrent bien à mes yeux le processus très particulier de l’inception, l’étincelle initiale d’un projet, qu’il soit une oeuvre ou un projet informatique.

D’abord un cadre. Qu’essaie-t-on de résoudre. Quelles contraintes se donne-t-on (temps, forme, … )

Ensuite les idées arrivent, et par une étrange combinatoire se multiplient. Deux idées proches engendrent une troisième qui va plus loin. Deux idées contraires engendrent un nouvel axe de réflexion, un contraste. On fait appel à d’autres domaines (des idées qui ont été utiles dans un autre contexte).

Après cette phase d’expansion, une phase de contraction. Les idées s’organisent. On identifie des catégories, des sous-catégorie. On classe, on enrichit la classification. En classant, les idées se confrontent, s’enrichissent encore. La classification permet d’identifier des lacunes, d’où de nouvelles idées. Des idées sont fusionnées, d’autres éliminées, d’autres articulées (besoin, solution du besoin, solution du besoin de la solution du besoin, …). Avec l’ordre apparaissent des axes, une carte, et donc la possibilité de vérifier l’exhaustivité, la cohérence, et d’enrichir le tout, et d’avoir le même niveau d’approfondissement pour tout.

Je vois deux façons de tenir un blog. La première (qui n’est pas la même) consiste à rédiger des articles structurés, fouillés (après l’inception). La seconde (qui est ma ligne ici) consiste à prendre un frémissement, et de le jeter en pâture à la multitude pour recevoir en retour des échos, déformés, enrichis. L’inconvénient c’est que mes articles ne sont pas aboutis. L’avantage c’est qu’ils ne sont pas aboutis ;-)

En fait, je transcris des demi-dialogues, comme si je retranscrivais une ligne sur deux d’une conversation à la machine à café. Un appel assumé à des échanges (pour avoir les autres lignes).

Publié dans Pensée | Laisser un commentaire

Reorganisation d’un organigramme par offres

Publié le 14 janvier 2011 par pierrefauvel

Périodiquement, les SSII se réorganisent (pour être plus efficaces, pour mieux attaquer le marché, pour mieux servir les clients, …). Parfois, une mouche les pique et elles se réorganisent en « offre ». J’ai vécu ça plusieurs fois, avec un certain scepticisme.

La direction décide de structurer l’organigramme en reflet du catalogue d’offres (une offre ca peut être une valeur ajoutée spécifique pour un secteur d’activité (ex:les entreprises de logistique ou les organismes de santé), pour une problématique (ex: la mobilité ou les portails), pour une famille d’activités (ex: le conseil/audit en processus ou l’amélioration des performances)). Le principe est que l’organigramme doit refléter la stratégie de l’entreprise qui est de mettre l’accent sur un certain nombre d’offres. Tout le monde rame dans le sens voulu par la direction, les offres se développent.

Pour moi, les offres (définies par le marketing et le bon sens des consultants de terrain) devraient être considérées comme un besoin auquel on répond par un certain nombre de solutions (des pools de compétence). Les assurances et les logisticiens ont tous les deux des problématiques de flux. Peut-être serait-il plus pertinent d’avoir un pôle de compétence « flux » (talend, etc…) qui servirait à 2 offres ?

Il faut bien un « porteur » de l’offre, détaché (si possible à temps plein) sur l’offre pour coordonner les efforts des différents pôles, objectivé sur les résultats de l’offre et doté du pouvoir d’objectiver les collaborateurs qu’il sollicite. Là où j’ai plus de mal c’est l’idée que ces offres soient coulées dans le marbre d’un organigramme, qui ne va pas changer souvent. Il faudrait un écosystème plus vivant, une notion d’incubation (prouver avec un petit peu de moyens la pertinence d’une offre).

Là où les collaborateurs ont du mal c’est l’idée d’être spécialisés sur une offre. C’est sympa la mobilité, mais bon de là à en faire pendant 3 ans ? Alors qu’il y a un spectre tellement riche de projets possibles. Vous me direz que la vocation d’une SSII n’est pas de balader les collaborateurs en les maintenant dans un état de perpétuels débutants. Vous me direz que les collaborateurs seront bien contents de pouvoir mettre « expert mobilité » sur leur CV. OK. Pourtant l’inquiétude est souvent palpable. Vais-je devoir me spécialiser ? Peut-être que les modalités d’entrée/sortie dans une offre devraient être éclaircies. Peut-être devrait-on pouvoir être rattaché à 2 entités ?

Imaginons que je veuille développer plus avant une offre de coaching agile tout en « finançant » cet effort par des missions plus classiques d’architecte ou de scrum master. Comment le puis-je dans un organigramme par offre ? Et pour quelle raison le porteur de mon offre « de base » aurait intérêt à financer l’autre ? Il faudrait clarifier le processus de définition des offres, d’allocation de budget, et, surtout, le rendre plus fluide, plus transparent. Créer des communautés spontanées, et non à l’initiative des managers, avec un budget inspiré des 20% de Google.

Qu’est-ce qui permet de gagner en efficacité ? un savoir faire, des livrables type adaptés, des guides de référence adaptés, parfois des composants et des frameworks, des processus et outils adaptés. Une organisation qui spécialise les équipe n’est pas garante d’une amélioration de l’efficacité. La condition sine qua non est l’investissement dans la capitalisation, son organisation, son contrôle, son adaptation au contexte, une bonne compréhension (et un intéressement) de chacun. Et la capitalisation est d’autant plus visible et effective qu’il y a de mouvement (entrées ou sorties). C’est un peu comme d’éviter l’appropriation du code. Alors oui, un spécialiste du RIA serait plus efficace. Mais jusqu’à quand, s’il s’ennuie ? Et puis on progresse en expliquant son savoir.

Enfin, qu’est-ce qui permet de toucher au mieux les clients ? Une bonne remontée par les acteurs du terrain (même les développeurs), qui au contact des clients sentent les préoccupations du moment et les spécificités d’un contexte. Collecter ces remontées, synthétiser des propositions, les confronter a quelques clients, ou dans des conférences, etc… Bref une agilité dans l’élaboration d’un produit innovant et approprié. Cette agilité doit être communautaire (les remontées de 10 valent 100 fois l’a remontée d’un seul).

Une bonne vieille organisation matricielle, avec une colonne par offre et une ligne par pôle de compétence, ça a aussi du charme, non ?

Je consommé trop d’agilité je pense : j’ai presque envie de dire : laissez l’entreprise s’organiser comme en l’entend, à chaque niveau sur la base des remontées des acteurs du niveau inférieur. Après, c’est peut-être ça qui se passe, mais tout est souvent si opaque…

Publié dans Entreprise | Laisser un commentaire

Quelques idées en vrac

Publié le 17 décembre 2010 par pierrefauvel

J’ai assisté à une réunion de présentation des évolutions de « skills », nom de code pour nos pratiques CMMI à SQLI. Comment souvent, ce genre de réunion est une source d’inspiration, même si les idées ne sont pas toujours liées à ce qui est présenté.

Quelques idées en vrac :

  • C’est une erreur de dissocier conception fonctionnelle (spécifications fonctionnelles détaillées) et technique (dossier d’architecture applicative, …). Un projet doit être conçu dans sa globalité. Faire des itérations de synchronisation entre le fonctionnel et le technique ?
  • Distinguer « product breakdown structure » (la décomposition fonctionnelle ou technique de l’application à produire) et « work breakdown structure » (la décomposition du travail à réaliser pour produire)
  • Distinguer reste à faire et valeur restant à acquérir. Je réconcilie les deux en comptant mon reste à faire en heures idéales et en évaluant la vélocité en heures idéales. La valeur acquise devrait sans doute être évaluée en faisant intervenir une quantification de la valeur et pas seulement l’estimation en charge.
  • « Design to cost » et « Time to market « : deux raisons pour simplifier (et réduire) au maximum ce qui est livré. Contrainte de coût ou contrainte de délai. Comme par hasard (coût, délai, qualité)
  • Notion de tracabilité prédictive (vers l’avant). Indiquer a priori quelles exigences devront faire l’objet d’une mention dans le DAT ou dans les specs (et contrôler cette mention une fois le livrable produit)
  • Notion de tracabilité multiple : pour être complètement couverte, telle exigence doit être mentionnée dans le DAT, dans les specs, dans les tests, … (évaluer un niveau de couverture)
  • Y a-t-il une différence de nature entre le paramétrage et le codage spécifique dans le cadre d’un framework avec suffisamment de valeur ajoutée ?
  • Comment trouver une mesure unique de complexité des tâches, alors que l’on fait intervenir des activités très différentes (spécification, conception, implémentation & tu, tests d’intégration, …) Peut-être que la seule mesure réelle est le temps idéal. Un peu l’impression d’additionner des choux et des tire bouchons, mais bon.
Publié dans Agile | 1 commentaire

Le coût et le prix

Publié le 19 novembre 2010 par pierrefauvel

Quand l’équipe estime en temps idéal des développements, elle estime la complexité de construction, bref le coût de production.

Implicitement ou explicitement, le product owner estimera lui en points, quelque chose qu’il lie confusément au service rendu, aux tâches simplifiées, aux économies futures dues à un surcroit de productivité ou au gain de compétitivité avec des fonctionnalités nouvelles. Il pense s’appuyer aussi sur une vision de la complexité de réalisation, mais celle-ci est approximative. Il pense avoir une vision du coût, mais finalement ce qui compte c’est l’analyse de la valeur perçue, bref du prix qu’il est prêt à payer.

Dans tous les cas, il y a un mismatch entre le prix accordé à une user story (ce que je veux bien payer, basé sur ce qu’elle m’apporte) et son coût (ce qu’il faut payer pour l’obtenir). Sans parler des cas où le product owner prétend chiffrer lui même la complexité.

Cela vaut aussi pour la priorité : priorité demandée par le product owner (fonctionnalités dont j’ai besoin opérationnellement), priorité de réalisation (contraintes, fonctionnalités dont j’ai besoin pour tester, pour des économies d’échelle).

Pour les priorités, la réconciliation est relativement simple : le product owner fixe les grandes lignes, l’équipe s’organise dans ce cadre en déplaçant les user story d’une itération à l’autre mais en respectant la priorité des release.

Ca ce gâte quand on discute lotissement en releases, en introduisant les estimations. Le débat est plus compliqué, passionnel.

Il faut intégrer d’autres facteurs, comme la confiance (initiale, puis méritée) qu’à le product owner dans la capacité de l’équipe à avancer, dans la bonne fois de la DSI. Elle s’appuie bien sûr sur l’historique.

Il y a aussi la maîtrise de la « dette technique » de façon à ne pas mettre en danger la productivité future pour des gains à court terme.

Publié dans Agile | Laisser un commentaire