Au passage et avant ce texte, nous avons traduit celui-ci par le biais d’un google doc, je rappelle que c’est vraiment un outil très utile pour une manipulation simultanée en commun. J’ai cependant découvert que depuis le début de la traduction celle-ci n’avait pas cessée de changer, de se transformer, d’évoluer. Et au bout d’un moment, pas forcément en mieux. Une sorte d’entropie naturelle… les microchangements on fait perdre du sens au texte (à mes yeux). Je prends donc le parti de vous proposer le texte de la révision du 9 janvier à 22h30 (à l’heure où j’écris ces lignes, il y a eu 8 changements depuis…).

Le réseau Stoos

Aujourd’hui, si on réfléchi à la manière dont sont gérées les organisations, on constate que la situation n’est vraiment pas brillante. On y observe trop souvent des raisonnements simplistes appliqués de façon mécanique, les entreprises étant bien plus intéressées par le prix de leurs actions que par le bonheur de leurs clients, et des employés – ceux qui possèdent la véritable connaissance du métier – dont les préconisations sont généralement ignorées par leurs chefs. L’actuelle crise économique n’est que le résultat et le reflet de cet état des lieux : les inégalités s’accroissent, les faillites se multiplient, et partout la désillusion se répand.

Il doit y avoir une meilleure façon de faire.

En janvier 2012, nous – un groupe de 21 personnes aux profils variés dont des cadres supérieurs, des managers, des business strategists, des universitaires, et des acteurs du développement agile et lean, en provenance de 4 continents – nous sommes réunis à Stoos, en Suisse. Nous pensons avoir trouvé des pistes, une base commune pour obtenir cette meilleure façon de faire. Par exemple, nous croyons que les organisations devraient se transformer en un réseau apprenant composé de personnes amenées à créer de la valeur et que le rôle des leaders devrait être de soutenir cet organisme vivant plutôt que de le gérer comme une machine.Plus important, nous nous engageons à continuer notre travail, notre réflexion, ici et en ligne. Un défi de cet importance nécessite beaucoup de coeur et d’idées. Nous aimerions entendre votre voix et connaître votre expérience. Aidez cette réflexion à avancer en nous rejoignant sur le groupe Linkedin et sur twitter avec le hashtag #stoos.

[ Le lien vers le document mutant et officiel ]

C’est donc le départ d’une initiative passionnante et probablement salutaire. En tant que membre fondateur d’une petite société de conseil (9 membres à ce jour) : smartview, j’essaye depuis le début de l’aventure d’appliquer l’idée générale des valeurs défendues par le stoos network, car elles sont aussi les miennes. J’y arrive, mais pas toujours. Je progresse, comme tout le monde. Ca aussi, comme d’habitude, c’est passionnant : devoir confronter ses idées à la réalité.

Les idées lancées par Stoos ne me paraissent pas si originales ou novatrices que cela (je suis gonflé, je dois juste ne pas avoir assez de recul ou de neurones). Mais peu importe, là n’est pas l’important. Pour une fois elles sont “officialisées” et un mouvement et une réflexion de plus grande ampleur ont démarrés. Je vous encourage à les rejoindre.

Seul bémol, le groupe à l’origine du Stoos network semble attendre suite à la dynamique qu’il a généré au sein du “réseau” (de nombreux inscrits au groupe linkedin, des tweets en pagaille, etc.) qu’il produise lui-même des résultats. En accord en cela avec la grande idée que c’est ce réseau organique qui a le vrai pouvoir et qui peut générer de la valeur. Mais cette attente de création ex-nihilo (à partir de rien) parait quelque peu artificielle. Nous manquons d’appui concret, et nous aurions envie que justement ces personnes présentes à Stoos nous montrent comment avancer. On pourrait croire que nous nous plaçons toujours dans l’ancien modèle attendant “du haut” les bonnes indications. Mais pas du tout, l’impression donnée est plutôt : nous avons réfléchis, maintenant les gueux, agissez… J’attends aussi de ces personnes qu’ils agissent comme des mentors, par l’exemple. Ce n’est qu’un bémol, et je suppose qu’il sera vite balayé par des actions concrêtes à venir. Si je peux y contribuer je le ferai, si vous le pouvez, n’hésitez pas.

Le  stoos network s’étoffe au fil des jours. Consultez les idées déjà émises, participez.

Bon allons-y avec des pincettes. Il s’agit d’appliquer des préceptes bouddhistes au management. Gasp. re-gasp. Si j’ai lu ce bouquin c’est que l’un de mes associés me l’a conseillé. Il retrouve en partie dans ces préceptes notre façon de faire. Je ne peux pas le contre-dire. Si lui-même a lu ce livre c’est que l’un de nos clients lui a conseillé : “vous faites du Karmic Management !”. Avant de se sentir honoré il fallait jeter un œil à cette chose.

Si j’exclus les côtés mystiques mais rigolos, notamment les sagesses antiques qui ouvrent les chapitres :  ”Pas cela, ni cela non plus”, “la ligne qui nous sépare est artificielle”, “tes problèmes sont ta voie”, “aucune action n’est jamais perdue” ; ou les aspects mercantiles qui achèvent le livre (tel séminaire, tel livre, tel session, voire une hot-line karmic, etc.), j’y trouve des choses intéressantes. Notamment l’idée forte du Karmic Management qui veut que toutes les réussites que vous allez pouvoir promouvoir, générer, réaliser autour de vous augmenteront votre propre réussite.

Je ne sais pas si cela “marche”. Je sais que je fonctionne ainsi et que j’ai souvent pu avoir la bonne surprise de voir des succès découler de ces engagements. Autre idée formulée de façon intéressante : les problèmes sont vos amis. Car ils mettent en évidence les obstacles qui vous empêcheront de réussir vos projets. Il faut donc les embrasser pleinement et dès qu’ils se présentent. Ce point est à rapprocher de l’introduction de Scrum dans une organisation : c’est un révélateur des problèmes sous-jacents de l’entreprise (j’essaye d’être assez agile pour retomber sur mes pieds… ).

amazon ?

]]> http://www.areyouagile.com/2010/08/fiche-de-lecture-karmic-management-roachmcnallygordon/feed/ 1 http://www.areyouagile.com/2009/09/scrum-un-ecueil-pour-les-ssii-et-kanban/ http://www.areyouagile.com/2009/09/scrum-un-ecueil-pour-les-ssii-et-kanban/#comments Sun, 20 Sep 2009 08:36:42 +0000 pablo http://www.areyouagile.com/?p=126

Kanban board

Appliquer Scrum n’est pas simple, surtout pour les SSII. L’un des principaux facteurs dont je souffre actuellement est la stabilité des équipes. les impératifs de production, eux-mêmes menés par des impératifs financiers règnent trop souvent en maîtres, et c’est normal. C’est aussi le signe me direz-vous que les processus et les méthodes ne sont pas assez matures puisqu’au moindre coup de vent (un gros contrat signé, une régie déclenchée pour un élément clef de l’équipe, etc.) ils volent en éclats. Je ne peux pas vous contre-dire. Je n’ai pas eu la chance de connaitre une entreprise qui -quelque soit le contexte (la crise par exemple)-  soit capable de maintenir coûte que coûte l’intégralité de ses processus tout en les faisant progresser (ces derniers mots sont importants sinon c’est la fossilisation qui vous guette).

Aujourd’hui beaucoup de SSII se jettent sur les méthodes agiles car elles ont le vent en poupe. Elles se heurtent à de nombreuses problématiques avec, pour n’en citer que quelques unes :

• la contractualisation (le  problème majeur actuellement, puisque ce n’est que le début de leur offre dans ce domaine, et que c’est un élément très fondateur,),  ils leur faut trouver une troisème voie entre le forfait et la régie (merci Christophe).
• la redistribution des rôles : le client (product owner) est responsable, l’équipe (team) est responsable, le Chef de projet disparaît, il était le responsable, le fusible, Atlas qui portait le projet (accessoirement avec le directeur de projet) ; le Scrummaster apparaît, il est un facilitateur, mais nullement un responsable.
• la stabilité des équipes durant les sprints, les itérations, est nécessaire.
• la maturité des clients et des équipes, personne n’est interchangeable, chaque collaborateur est différent d’un autre, etc.

Les SSII entament donc un difficile périple. Aujourd’hui si je regarde l’un des projets que je pousse vers l’agilité je me heurte de plein fouet à la difficulté de la stabilité de l’équipe. Il ne s’agit pas d’un projet client, mais d’un projet interne. Il est d’autant plus saccadé. Sa priorité est difficile à établir. Les ressources affluent (fin de projets clients) et elles refluent (signature de projets clients). Moi même je ne peux avoir qu’une activité chaotique à son encontre. Appliquer les fondements de Scrum dans ce contexte devient très compliqué. Mais l’agilité c’est aussi une dynamique de l’adaptation. Je me tourne donc aujourd’hui pour ce projet vers Kanban.

Pourquoi ? Il me propose des valeurs qui sont en adéquations avec mes besoins (certains sont aussi associées à Scrum), ne pas développer de fonctionnalité que personne ne va utiliser, ne pas écrire plus de specs qu’il n’y aura de code, ne pas écrire plus de code que je ne puisse tester, ne pas tester plus de code que je ne puisse déployer. Très concrètement ne pouvant bâtir une équipe stable, ne pouvant garantir de daily scrum journalier, n’ayant pas assez de garanties sur la pérennité de mon équipe, etc. je vais me focaliser sur ce que j’imagine être l’essentiel de la pratique Kanban et à partir de là reconstruire un processus agile (si cela marche). Soyons clair, il permet surtout de simplifier excessivement le processus, et si cela fonctionne il me permettra de rebondir sur quelque chose de plus puissant. Ceci dans le cadre de ce projet.

Je ne sais plus où (ah si, ici)  j’ai lu cet exemple mais en gros, de façon imagée : je pose des portes sur une voiture (Kanban vient -encore- de Toyota), j’ai un tas de 10 portes devant moi, lorsque j’arrive à la 5ème porte je vois une étiquette sur la voiture (étiquette = kanban en japonais). L’étiquette m’indique que je dois prévenir la personne qui fabrique les portes de me fabriquer 10 portes supplémentaires. Je trouve cette personne et lui demande 10 portes supplémentaires. Elle arrête la tâche qu’elle était en train de réaliser, et commence à fabriquer 10 portes supplémentaires. Elle savait que je passerais, mais travaillait sur autre chose. Je retourne à mon assemblage. Lorsque je finis presque mon tas de 10 portes, la personne a qui j’avais demandé les nouvelles portes arrive, elle dépose les portes, et naturellement, sur la 5ème, au milieu du tas, une petite étiquette est présente.etc.

Ici, sur ce fameux projet interne, je dispose d’un backlog et d’une équipe fluctuante dont la disponibilité est fluctuante.Ma difficulté est le WIP (Work in progress). Je ne dois pas avoir un membre de l’équipe qui démarre quelque chose et qui malheureusement ne peut l’achever (pour x raisons). Sinon je me retrouve avec une tâche de coordination (du nouveau membre remplacé par l’ancien), de transfert de compétences (du nouveau …) , et potentiellement de rework (le nouveau membre de l’équipe aborde différemment la résolution de sa tâche). Bref 3 plaies essentielles sources de gaspillage.

Mon objectif est de définir des User Story (ou MMF : minimal marketable feature) assez compactes et assez indépendantes les unes des autres pour qu’elles puissent être abordées unitairement et assez rapidement : pour ne pas risquer de perdre l’acteur qui l’a prise en charge, pour qu’il puisse appréhender la MMF rapidement. Avoir assez de visibilité sur l’ensemble des MMF pour qu’elles puissent s’enchainer et constituer de la valeur ajoutée. Faire des livraisons plus rapidement, plus rythmées. Quand un flux régulier sera mis en place j’aurais mis en place un premier niveau d’efficacité. L’objectif de ce flux est de réussir à créer un rythme et une régulation entre les différentes tâches liées au projet, en limitant au maximum le “work in progress” car c’est lui qui m’empêche de livrer régulièrement et qui rigidifie la marche du projet. Chaque tâche s’emboite avec d’autres, ou peut en déclencher d’autres sans que les personnes qui aient la charge de ces autres tâches ne soient impactées. Elles ont donc du “temps libre” pour leurs autres activités (sachant qu’ici le procédé est inversé, c’est quand elles ont du temps libre qu’elles se consacrent au projet “interne”) . Enfin il est plus aisé d’intervenir sur le projet quand chaque tâche est plus compacte (ceci n’est malheureusement pas si simple et pas si souvent vrai).

D’ici là, et si j’atteins ce but… nous en reparlerons.

Pour en savoir plus sur Kanban, appelez Google, ou utilisez cette page de cet excellent blog : targetprocess : kanban.