Archives de Catégorie: Projets et agilité

Post-it war à Innovallée

Par défaut

C’est désormais de notoriété publique, la Post-it War est partie d’une confrontation entre UBISOFT et BNP à Paris et a fait des émules y compris en province. A Lyon Part-Dieu, Boulevard Vivier Merle, les bureaux de part et d’autre du Boulevard se provoquent avec des créations en post-it.

J’avais envie de booster nos équipes agiles à Montbonnot et de promouvoir l’esprit agile, les bureaux voisins avaient fait des petits packman, des mini Lemings… rien de significatif.

J’ai monté un buzz en interne, lancé des piques, incité un collaborateur à faire une première création (un Mégaman)puis tout le monde est venu voir… ça gratouillait un peu partout… jusqu’à ce début octobre je donne un rdv à ceux qui voulaient… j’ai réussi à rassembler sur un nocturne une vingtaine de collabs qui, des équipiers agiles ou non aux Managers commerciaux et aux Directeurs de Projets sont venus tâter du post-it.

J’avais évidemment pris les dispositions, prévenu la sécurité, la Direction, la propriétaires des bureaux qui étaient sur les verrières les plus en vue… préparé un stock de bières et un buffet bio charcut / pain / fromage.

On a commencé à se chauffer avec un paquet de post-its… Esprit équipe auto-organisée : chacun a pris des post-its et des dessins ont vu le jour, travail spontané d’un collaborateur ou d’un binôme, d’un trinôme, sans aucune directive… Voici un aperçu de nos créations réparties dans les bureaux, couloirs, war-rooms, paliers, escaliers, salles de réunions…

OPEN POST-IT CREATIONS

Quelques traces de nos créations réparties dans les bureaux, les escaliers et paliers.

On s’est chauffés avec des petits worns, packman, megaman, panthère rose très réussie… et puis on s’est lancé dans une grande fresque DONKEY KONG sur la verrière d’entrée, haute de 3 étages et très visible depuis un rond point et une route très empruntée… de quoi mettre un peu d’ambiance chez nos voisins 😉 Nous partimes 3… et finirent une dizaine sur cette grande fresque, chacun venant renforcer l’équipe initiatrice, encore une fois de façons spontanée.


On s’est bien marrés, on était content de notre création… les boss ont été super fiers de l’équipe qui du coup se sent valorisée… même le journal d’INNOVALEE parle de nous !!! Inespéré !

Notre Direction Régionale joue le jeu, pousse l’info à OPENMAG, le journal interne, ça crée un buzz dans les autres entités OPEN… notre bureau de Lyon se prépare à renchérir… le Directeur Régional a bien envie de retrousser ses manches et de coller des post-its… fever !
Comme quoi, une petite initiative locale peut faire des vagues 😉

A+

Jean

Lequel est le plus « agile » ? Blog ou wiki ??

Par défaut

Petite réflexion sur les outils en vogue sur le web 2.0 et sur la contribution de la communauté agile.

Le nombre de blogs sur la toile va croissant, y compris dans le monde agile. Chacun y va de son apport avec sa logique éditoriale, certains favorisant les retours d’expérience, d’autres les notes d’humeur, une vision de l’avenir, une philosophie du SI, un rapprochement avec les logiques héritées de l’industrie nippone… On peut s’abonner aux articles de plusieurs blog, suivre les flux RSS au travers d’un agrégateur style netvibes, commenter et noter les articles, commenter les commentaires … faire un article sur son blog en citant l’article d’un autre blog… sans oublier de twitter vers tout et réciproquement 😉

Effectivement le web 2.0 donne la main aux rédacteurs de tout poils et la toile se tisse avec des liens qui se croisent dans tous les sens. De sorte qu’il devient fastidieux, chronophage voire impossible de suivre tout ce qui est publié sur un thème, commentaires compris… Le coût pour se maintenir au courant des dernières publications devient prohibitif !!! Cela rappelle ce qui est advenu de l’informatique des grands comptes après des années d’empilage d’applications de toutes technologies, avec redondances fonctionnelles, interfaces multiples en entrée et en sortie… Quand la complexité devient exponentielle, le coût de maintenance devient prohibitif… il devient nécessaire d’urbaniser le SI. Alors, faut-il urbaniser l’édition on-line ?? Le wiki n’est-il pas en ce sens une préfiguration de solution ?

En ce qui concerne la communauté agile, je suis surpris de voir que les blogs pullulent et non les wikis qui me semblent beaucoup plus proches des valeurs agiles, deux d’entre elles en particulier :

  • L’interaction avec les personnes : est plus féconde dans le wiki (on écrit ensemble comme en pair programing) que dans le blog (j’écris un article, vous commentez mais l’article ne s’améliore pas…, vous pouvez aussi écrire un « contre-article » sur votre propre blog pour réagir et exposer un propos complet)
  • Davantage un produit opérationnel qu’une documentation pléthorique : de même, un wiki permet de consolider les apport et offre une vision complète, là ou une somme de blogs, commentaires et forums apporte une liste pléthorique de documentation électronique sans qu’aucune synthèse ne soit faite…

Cette vision se retrouve également au niveau des principes du manifeste agile :

  • Notre première priorité est de satisfaire le client (LECTEUR) en livrant tôt et régulièrement des logiciels (POSTS) utiles : l’avantage du wiki est qu’il est publié et évolue en permanence, alors que pour un blog, on édite un post quand il est bien ficelé, complet… on livre donc potentiellement moins souvent. Twitter ou un wiki semblent plus adaptés.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client : de même, dans un blog, une fois le post écrit, plus de changement… seulement des commentaires. Un wiki évolue en permanence…
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte : rejoint les points précédents
  • Les experts métier et les développeurs doivent collaborer quotidiennement au projet : l’aspect collaboratif me semble beaucoup plus évident sur un wiki que sur un blog, même un blog muti-éditeurs (où chacun publie ses billets).
  • La méthode la plus efficace pour transmettre l’information est une conversation en face à face : ce qui se cache derrière le « face à face » est sans barrières… or il y a moins de barrières et frontières dans un wiki que dans un blog (entre l’éditeur et les lecteurs, l’article et les commentaires)
  • Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment : c’est l’une des problématiques des blogs individuels : cela consomme un temps pour chacun pour avoir l’idée, la formaliser, la publier… un wiki par les contributions des autres apporte stimulation, idées croisées… et à la fois réduit la contribution à une idée, quelques mots, au lieu d’avoir un article complet à écrire.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité : en matière d’idées, il est plus facile de viser l’excellence à plusieurs (on se corrige, pense mieux…) et en pouvant retoucher, améliorer l’article (wiki) que sur un article mono-rédacteur figé (blog)
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle : la simplicité est très difficile à atteindre en particulier en un seul coup. Plus facile de tendre vers la simplicité en remettant l’ouvrage sur le métier… en prenant du recul, remettant en cause régulièrement ce qu’on considérait comme acquis… qui mieux que le wiki permet de revenir en arrière, de simplifier ? Quant au fait de maximiser la quantité de travail à ne pas faire, on peut faire le parallèle avec l’idée de maximiser la quantité de texte à ne pas lire : le wiki synthétise les idées contrairement aux blogs et forums où il faut lire le propos puis toutes les questions réponses, certaines étant souvent redondantes, incomplètes…
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent : il s’agit ici de l’architecture du wiki, l’organisation des idées… avec des liens internes et externes. Wikipédia me semble avoir une structure et une conception plus intéressante qu’une collection de plusieurs milliers de blogs…
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens : le travaille d’équipe me semble plus propre au wiki qu’au blog même multi-rédacteurs (mais rédacteurs individuels derrière un blog commun).

Aussi, pour aller au bout de la logique, j’ai eu l’idée de lancer un wiki pour contribuer à plusieurs à l’écriture d’un retour d’expérience consolidé et vivant permettant à des internautes qui aimeraient basculer en agile de comprendre comment y aller… Je l’ai baptise TRANSITION AGILE. Déjà 4 contributeurs m’ont proposé de confronter nos idées et écrire à plusieurs. Vos contributions sont les bienvenues. Pour l’instant, la contribution est sur login / mot de passe pour pouvoir être régulée. La lecture du wiki est ouverte au public. Cela pourra évoluer avec le temps selon l’usage et ma maîtrise de l’outil.

Bonne lecture.

Jean

Appel à contributions : projets agiles

Par défaut

Dans le cadre d’Agile Grenoble 2010, je vais animer une session avec Jean-François Jagodzinski sur la gestion de portefeuilles de projets agiles. Je suis à la recherche de contacts dans des sociétés ayant tout ou partie de leurs projets gérés en agile. Dans ce cadre, je cherche des contacts avec les portfolio ou program managers pour voir comment ils gèrent la répartition des ressources entre les projets.

Si vous êtes concernés ou si vous connaissez des sociétés et des personnes travaillant dans des environnement fortement agiles (au moins une partie significative des projets), je suis preneur des contacts. Le résultat sera publié sur un wiki et présenté à Agile grenoble 2010.

Des patates et des sucres

Par défaut

Hier soir, le Club Agile Rhône-Alpes s’est réuni comme à l’accoutumée pour l’une de ses « rencontres autour de l’agilité » fort sympathiques. Nous étions 18 professionnels à venir partager nos pratiques, nous ressourcer, nous ouvrir à une nouvelle vision de notre monde.

Emmanuel Etasse et Jean-François Jagodzinski m’ont demandé si je pouvais animer la session. Grand honneur pour moi qui ait rejoint le CARA tout récemment, que d’avoir une tribune dans un monde où je me sens encore tout petit. J’ai donc essayé d’apporter ma pierre à la communauté. Ou plutôt ma patate…

FORMATION DE FORMATEURS

J’ai eu la chance de suivre ce printemps une formation de formateurs délivrée par Jean-Denys Joubert au cours de laquelle j’ai puisé de nouvelles manières d’animer de manière décalée. En l’occurrence, d’utiliser des « jeux d’enfants » pour permettre aux adultes de prendre conscience de leur rapport à l’autre, à la collaboration, à la compétition, à la sécurisation de l’équipe et du résultat, à la gestion du temps, à la fixation et à l’atteinte d’objectifs, à l’amélioration continue, à l’innovation de rupture…  Nous avons réussi à évoquer tous ces sujets et partager nos impressions à partir de deux outils projectifs : des patates et des sucres en morceaux.

Comme nous avions 17 joueurs, nous avons travaillé en deux équipes de 8 et 9 joueurs qui se sont d’elles-mêmes mises en compétition sans que cela soit l’objectif des séquences proposées.

LA PATATE

Le jeu de balle ou jeu de la patate est un outil projectif sur la stratégie d’objectif, la prise de risque, le progrès continu, l’innovation par la rupture, la collaboration, la gestion du temps, le challenge. Avec un objet simple et une consigne simple, l’équipe dispose de peu de temps pour trouver une solution au problème. Elle teste son idée et mesure sa performance. Elle joue une seconde fois dans le même contexte et essaye de faire un peu mieux. Elle y arrive. Puis une nouvelle consigne ordonne de faire 2 à 10 fois mieux ! Une rupture. L’équipe y parvient aussi. Ce jeu qui n’est pas sans rappeler le travail agile en sprints nous questionne en particulier sur les manières dont nous animons les rétrospectives : chacun peut-il s’exprimer ? comment naissent les nouvelles idées ? apporte-t-on assez de sang neuf dans l’équipe pour ouvrir de nouveaux horizons, s’autoriser à envisager qu’il est possible de faire 2 à 10 fois mieux en changeant radicalement ?

LES SUCRES

Le jeu des sucres ou cubes est un jeu qui réalise un cycle complet de trois itérations. Chaque joueur doit estimer le nombre d’étages de la tour qu’il est capable de construire dans le temps imparti. Puis vient le chrono : la pression monte avec les étages et avec le temps qui s’égrène mais dans le stress, on ne sait plus combien il reste de temps. A quelques secondes de la fin, on essaye de faire mieux, d’ajouter un étage et patatras. Le chrono s’arrête, on compte les étages et les écroulements. Rires, satisfactions et frustrations se côtoient. « Je n’aurais pas dû… » Chacun s’exprime sur la manière dont il a fixé son objectif, comment il a géré la phase de réalisation avec ses coups de stress et ce qu’il éprouve face à son résultat. On y rencontre des prudents, des têtes brûlées etc. Comme dans la vraie vie, comme dans un planning poker…  Pour l’itération suivante, on adapte sa stratégie et son objectif, sa méthode aussi… on se compare à sa propre performance ou à celle des autres joueurs, c’est à chacun son karma. Deuxième pari, deuxième jeu, deuxième résultat… A-t-on fait mieux ? Dans l’absolu en nombre d’étages, en atteinte de l’objectif ? Mieux que les autres ? Puis vient le temps où l’on n’est plus chacun pour soi mais tous en équipe à chercher à atteindre l’objectif global. A chaque équipe sa stratégie, ses règles de solidarité implicites ou explicites… Si on fait le parallèle avec SCRUM, cela ressemble à plusieurs itérations avec chaque fois son planning poker, sa phase de réalisation et sa rétrospective. On voit l’importance des temps d’échange et ce que change dans la fixation et l’atteinte d’objectifs le passage d’une équipe ou chacun pense en fonction de lui-même à une équipe où chacun contribue à la réflexion et à la fixation et à l’atteinte d’objectifs communs. Dans l’une des deux équipes en lice, le temps de préparation a permis de réduire les risques, de calmer les têtes brûlées. Ils ont utilisé un secret : ils ont partagé la réponse à la question « je serai content si… » ; ils ont visé la satisfaction collective de savoir mesurer sa capacité de production (vélocité) et le fait de remplir le contrat dans le confort et sans risque (pour eux et pour le donneur d’ordre) plutôt que de viser d’avoir la plus haute tour et de compenser les faiblesses des uns par la force supposée des autres. Ils ont donc visé un nombre d’étages sur lequel chacun se sentait sans risque : confortable, pas le plus haut possible, car le « mieux est l’ennemi du bien » ; un sucre de plus et un édifice qui semblait solide s’écroule une seconde avant le gong. Chacun travaillant dans sa zone de confort, le contrat de solidarité a pu rester implicite. L’autre équipe était plus centrée sur le fait de faire mieux que les voisins au lieu de viser son confort. Elle s’est également plus centrée sur la prouesse technique (nombre d’étages) que sur la satisfaction du contrat rempli (avec bonus à l’appui). De fait, chacun a visé son objectif maximum atteint dans les tours précédant en s’imaginant qu’on ne pouvait pas revenir en arrière. Pour eux, le maximum d’avant devenait si ce n’est le minimum d’aujourd’hui, au moins le confort théorique acceptable. Or pour certains, c’était trop risqué  : avant la fin du chrono, l’un des joueurs rapporte qu’il lui manquait un étage… Au lieu d’avouer son risque d’écroulement et de demander à ses équipiers de compenser la fragilité de sa tour par un étage de plus sur une autre tour… il a tenté le diable et cela s’est terminé par l’écroulement de sa tour qui n’a pu être compensé par ses équipiers.

En synthèse, ce jeu des sucres est un révélateur efficace des personnalités qui composent l’équipe et de la manière dont l’équipe s’auto-organise.

De ce point de vue, ces deux heures de team-building et de partage me semblent tout à fait intéressantes dans le contexte d’équipes projet, en particulier agiles !

Un grand merci à tous les participants du CARA, à Manu et Jean-François qui m’ont donné la chance d’animer cette session et à Jean-Denys pour ses précieux outils que je ne saurais trop vous recommander

Jean

Agile or not agile ??

Par défaut

Alors que l’agilité est sous les feux de la rampe, Scrum par ci, Scrum par là… la professionnalisation de la gestion de projet continue sa course folle avec les deux références mondiales que sont le PMI et Prince2. Le nombre de certifiés du PMI en particulier PMP s’envole à plus de 330.000 certifiés dans le monde. Les recrutements d’informaticiens font de plus en plus référence à l’agilité… les études et articles de tous genres font l’apologie de la gestion de projet

Derrière tout ce grand tintamarre, il y a plusieurs questions clés qui se posent

  1. Les maîtres d’ouvrages / customers sont-ils pris en compte dans ce grand mouvement de professionnalisation ? Que se passe-t-il si seuls les équipes informatiques se professionnalisent ? Cela ne déséquilibre-t-il pas un peu plus la relation entre le client et IT (MOA / MOE) ??
  2. Selon Forrester Research, 35% des compagnies gèrent des projets en « agile ». La connaissance de l’agilité n’est plus facultative. Mais son application est facultative. Toute organisation est-elle prête à passer à l’agilité ? Suffit-il d’envoyer une équipe projet en formation pour réussir un projet agile ??

Aujourd’hui, même si l’agilité fait beaucoup parler d’elle, elle n’est pas applicable simplement, facilement, dans tous les environnements : en effet, il ne s’agit pas de simples petites évolutions par rapport à une méthode Merise ou à des standards PMI / Prince2… C’est un changement profond de paradigme. Bien sûr, il y a toujours une définition des besoins, un développement, des tests… Mais c’est la logique globale qui change : pas de chef de projet mais une équipe égalitaire, pas un « groupe d’utilisateurs » qui décide après des semaines de débat mais un seul product owner qui doit décider seul chaque instant de chaque jour en échange constant avec l’équipe informatique agile… Pas un cahier des charges global mais une liste de fonctions priorisées…

En bref, le passage à l’agilité requiert des pré-requis culturels (droit à l’erreur pour faciliter la prise de décision par le product owner, gestion des risques, changement de méthode), managériaux (pas de chef de projet mais une équipe, un scrum master, un product owner), organisationnels etc. qui ne sont pas donnés à toutes les organisations, sans oublier une souplesse (agilité ?;-), un esprit d’équipe, une capacité à décider chez les participants au projet…

A ce propos, le PMI vient de publier quelques slides intéressants pour s’interroger sur la pertinence de l’agilité dans le cas de tel ou tel projet de telle ou telle organisation. C’est un premier niveau de lecture intéressant qui ne prétend pas à l’exhaustivité et peut bien entendu être complété. http://www.pmi.org/Resources/Pages/Agile.aspx

Bonne lecture.

Jean

Amusant comme l’agilité change tout…

Par défaut

On parle de gestion de « projets agiles« . Cela sonne bizarrement… pourquoi ?

La notion de projet s’entend avec un début et une fin… En discutant avec JF Jagodzinski (coach agile et co-fondateur du CARA / club agile rhône-alpes), j’avais entendu dire qu’il n’y avait pas de fin dans un projet agile… cela me taraudait car alors ce ne pouvait plus être un « projet » au sens de la définition internationale (voir le référentiel PMBOK du Project Managelent Institute).

Dans la mouvance agile, on parle aussi du rapprochement avec la logique lean… (cf le blog d’Alexandre Boutin) qui est celle du progrès continu (donc sans fin). Là encore, je me demandais si on ne confondait pas le mode projet et la maintenance applicative qui suit une logique de priorisation et d’amélioration continue.

Mais il y a une différence à mes yeux entre le projet et la maintenance : j’ai dans l’idée qu’un projet doit donner naissance à quelque chose de nouveau, d’unique et qui n’existe pas encore, alors que la maintenance est plutôt synonyme d’entretien de quelque chose qui devrait marcher et ne fonctionne plus.

Bref ! N’est-on pas en train de changer la vision du monde ? Faire du projet sans début et sans fin ? Pour aller plus loin sur ce thème, je vous recommande la lecture du blog de Ole Morten Amundsen qui publie  un article intitulé « the continuouses » et détaille tout ce qui d’une logique unitaire et séquentielle tombe dans une logique continue jusqu’ici dévolue aux opérations…

Bonne lecture

The Continuouses (via Ole Morten Amundsen)

I love creating software! I want to deliver business value efficiently over time. I’ll share my thoughts with you on what it takes to carry out that. This blog post is about continuous processes, which of them I feel are the most important ones and what their added values are. Finally, I will talk about the one continuous process to rule them all, find them, bring them all and in happiness bind them. Yeah, don’t you already desire it? Anyways, I … Read More

via Ole Morten Amundsen