Every victory is only the price of admission to a more difficult problem.
Henry Kissinger
Mois : février 2014
La boite à outil du coach agile
Besoin d’étoffer votre boite à outil de coaching ? Voici des conseils avisés de la part de nos pairs !
Des outils de coaching pour améliorer la dynamique de votre équipe
Cette présentation de JF Hélie et Guillaume Duquesnay a été donnée à Agile France 2012
20 coaching tips in my agile suitcase
Cette fois c’est Yves Hanoulles qui nous délivre une série de recommandations.
Agile coaching workshop
Workshop monté par Craig Smith
Du chef de projet au coach agile
Ces deux vidéos nous ont propos&ées par Lissa Adkins. Il s’agit d’une retranscription d’un workshop donné à Chicogo en 2008 lors d’un Scrum GatherinG
Il s’agit de réflexions à propos de ce que cela signifie réellement de devenir coach agile.
Solution focus
S’intéresser à la solution plutôt qu’au problème et en rechercher les prémisses dans la réalité présente, tel est la ligne directrice du Solution Focus. Vous pouvez aussi vous reporter à la note de lecture que j’avais rédigé sur Coaching Plain & Simple.
Wu Wei Coaching
Je le place ici par pure curiosité. Car en fait, je n’ai toujours pas compris de quoi il retournait ! “Wu Wei” signifie “sans action”. Et en fait, comme il est indiqué à la fin de cette présentation, celle-ci ne vous aidera pas à comprendre ce que c’est !
Scrum Galette 2014
La Scrum Galette, c’est la variante de la Scrum Beer de début d’année où l’on partage la Galette des Rois. J’avais “subtilement” suggéré à Arnaud d’organiser la chose en m’engageant à participer à l’achat desdites galettes.
Je ne savais pas que cela allait m’occasionner la première grosse galère de ce début d’année : entre les problèmes de transports, un voyageur malade bloquant le traffic métro, d’interminables escaliers et une adresse de pâtisserie erronée, mon périple allait me coûter 2h30 et un quasi-arêt cardiaque 🙂
J’arrivais donc avec tranquilement 1h20 de retard, mais avec ma galette !
Small Talks
Comme toujours, ces discussions en petits groupes sont passionnantes ! Bien entendu, nous avons évoqué le Scrum Day 2014 qui aura lieu cette année à Disneyland.
D’un point de vue plus personnel, cela m’a permis d’échanger avec Jean-Baptiste que je croisais de loin depuis un certain temps sans avoir fait connaissance. L’occasion d’évoquer l’agilité dans la communauté PHP et l’affinité (ou la non affinité) de certaines communautés techniques avec l’agilité… On a parlé technique aussi avec les bases NoSQL. Car si on se demande si certaines technologies sont plus “agile compatibles” que d’autres, la réponse est hélas : oui !
L’agilité et les grandes sociétés de service
Autre sujet de grand intérêt : l’agilité et les “grosses boutiques”, vous savez, les Atos, Cap Gemini, Altran, etc. J’avoue mon ignorance à leur sujet : je les croisent peu (un peu plus ces temps-ci, en fait) et elles ne m’ont jamais intéressé. Mais ce sont des acteurs majeurs de l’informatique Française et je ne trouve pas très pertinent de me désintéresser de la question. Avec un avis de l’intérieur, c’est tout de suite plus éclairant.
Je perçois aujourd’hui un discours venant de ces sociétés pour montrer qu’elles existent dans le monde de l’agilité. En vérité, on ne les croisent pas dans la communauté agile, et je pense avoir une bonne connaissance de ce qui s’y passe ! Cela ressemble plus à une tentative d’occuper un terrain grandissant qui ne les intéressent pas vraiment mais qu’ils ne veulent pas voir échapper. C’est un avis subjectif (le mien) dont je dois dire qu’il n’est pas très étayé, hormis l’absence de ces grands noms des rendez-vous agiles.
La politique de ces grands groupes est complètement orientée aujourd’hui vers des réductions de coûts :
- Offshoring et Nearshoring
- Pyramide des âges très évasée vers le bas
- Focus quasi-exclusif sur le taux d’occupation des consultants.
- Minimum de préoccupation sur la formation et aucune sur le développement personnel.
Autant dire que l’on est très loin de ce qui m’importe ! Et il est aussi certain que de telles orientations ne font pas remonter ces sociétés dans mon estime. Pour autant, ces orientations ne sont pas à considérer comme des souhaits délibérés, mais comme le reflet des orientations du marché.
Je m’explique.
Les grands appels d’offre qui sont le business de ces grandes compagnies sont aujourd’hui, encore et toujours dominés par les forfaits fermés avec cahier des charges en amont, rejet des risques sur le prestataire et recherche du moins-disant. Toujours le même truc stupide depuis des dizaines d’années, ça ne marche pas, ça génère des avenants monstrueux (que ces grosses boutiques savent gérer pour rentrer dans leur mise de fond), quand ça ne finit pas au tribunal.
Les grandes sociétés de service sont complètement adaptées au business qui se présentent à elles. D’où le focus sur la réduction des coûts, la gestion du revenu via le change management au détriement de la qualité et de la satisfaction client. Oh, ces derniers points sont bien évoqués dans les appels d’offre, mais ne rentrent jamais en ligne de compte dans la sélection du prestataire, ils sont donc à juste titre ignorés par les répondants !
Eh oui, la ligne de conduite de ces grandes compagnies ne sont que le signe des temps. Elles s’adaptent au marché.
Notre espoir, qui se concrétise progressivement, est que les institutionnels demandent de plus en plus d’agile, du vrai ! Ce sera alors une mutation à mener pour ces grandes sociétés qui vont courir derrière des clients dont le niveau de maturité est plus élevé et sauront bien jauger ce qu’on leur propose. Cela commence déjà. Nous allons vivre une période intéressante.
Un peu de légèreté pour terminer…
Avec un peu de chance nous pourrons tenir un rythme mensuel pour nos Scrum Beers. J’aimerais bien. Ce sont des moments conviviaux, avec des échanges qui stimulent la réflexion.
Malgré qu’elle soit largement floue (la faute à un éclairage insuffisant), je ne peux résister à terminer sur cette image de Laurence couronnée par Arnaud !
A room without books is like a body without a soul.
Marcus Tullius Ciceron
Meetup Evernote entre amis
Pierre Journel n’organise plus aussi souvent les Meetup Evernote qu’il en avait l’habitude. Il faut dire que sa nouvelle aventure, faire de La Chaine Guitare une startup l’occupe énormément. Dans ce contexte, nous devons lui être reconnaissant de parvenir à distraire du temps pour organiser épisodiquement ces rencontres.
Cette rencontre-ci ciblait plutôt les nouveaux venus à la plateforme de prise de notes, donc pas des gens comme moi en principe. Mais outre le plaisir que j’ai à me rendre à ces rencontres, j’y découvre invariablement de nouvelles choses.
Le tour de l’application desktop
Tout d’abord le tour de l’application Evernote Mac pour les débutants. On s’arrête un peu sur la nouvelle fonction diaporama, ou la possibilité de créer une table des matières par simple multi-selection de notes ! S’en suit un nouveau round de l’éternelle question : tags ou carnets ?
En ce qui me concerne, j’avoue utiliser les tags avec moins de conviction qu’hier et utiliser un peu plus de carnets. En fait, j’ai l’impression que Pierre fait comme moi sur un point : il créé un carnet quand il s’aperçoit qu’il finit par écrire beaucoup de notes sous le même thème. De toute façon, c’est clairement la recherche full text qui nous sert le plus à retrouver nos notes ! Le retour des participants sur les tags est :
- Une grande discipline dans leurs usages : toujours les utiliser, sans les multiplier à priori.
- Concevoir le système de tags selon l’usage que l’on en aura dans 2 ans ! J’avoue que ce dernier point me pose problème : c’est typiquement le genre de question que je ne prétenderais jamais être capable de répondre !
En parlant de recherches, Pierre nous montre une fonctionnalité que j’ignorais : la possibilité de faire des recherches full text, mais spécifiques :
- Sur des tags : “tag:xxx”
- Sur des carnets : “notebook:xxx”
- Dans les titres : “intitle:xxx”
Pierre nous montre aussi la création de raccourcis dans la partie gauche. Je n’ai jamais pensé à utiliser cela, pas sûr que je m’y mettre… Nous voyons aussi l’interfaçage avec skitch pour modifier les images : ça il faudra que j’essaie !
Je découvre aussi en passant la fonction de lecture orale du texte avec Evernote Clearly (dont je me sers beaucoup pour récupérer poprement des posts qui m’intéressent).
L’actualité Evernote
Pas de grandes nouveautés aujourd’hui dans les fonctionnalités coeur. Evernote semble très occupé avec du cleanup de code. Nous avons évoqué le post de Jason Kincaid auquel à fait suite une réponse de Phil Libin ( ) ! Evernote va concentrer ses forces sur la qualité et la stabilité du code en 2014.
Evernote doit rester simple, efficace, fiable et performant, donc j’approuve en partie ce choix. Par contre, certaines fonctionnalités font partie de ma liste au Père Noel:
- La possibilité de générer un texte converti depuis une note manuscrite. J’en avais parlé dans mon essai du Livescribe, nous en avons reparlé ce soir.
- La possibilité de créer des carnets d’index, référençant des notes figurant dans des carnets. Ce serait utile pour synchroniser des carnets sur mobile. Pierre nous a décrit comment il déplace les notes dans un carnet “offline” pour cela, l’obligeant ainsi à redéplacer plus tard sa note dans l’autre sens ! Pierre en parle d’ailleurs dans la dernière émission de son Podcast sur La Chaine Eléphant.
Démonstration du Livescribe Sky
C’est ma partie. Je ne vais pas vous refaire l’essai que j’ai déjà posté ici. J’avais amené tout le matériel, y compris les carnets. Je n’ai malheureusement pas été capable de connecter le stylo au Wifi local. Tout comme on avait pu jouer au voyeurs avec les notes de Pierre, on a pu faire la même chose avec les miennes. Egalité !
Fin de soirée
Une très bonne soirée, même si je suis arrivé un peu en retard. Pierre a été un peu plus rapide que moi pour poster son compte-rendu.
Je fais une partie du chemin de retour avec l’un des participants. Et je m’apperçois qu’il s’agit de Guillaume Vendé, le co-animateur du Podcast niplife ! Ca ne vous dit peut-être rien, mais je suis un (très) fidèle du grand frère de la famille, c’est à dire niptech podcast. Guillaume et Pierre se connaissent car ce dernier avaité té le premier invité de niplife où il avait été question de GTD.
C’est tout pour aujourd’hui, en espérant ne pas se languir encore un an pour le prochain meetup.
Note de lecture : La Revanche du Rameur, par Dominique Dupagne
Note 7 ; Des maux inhérents aux hiérarchies du pouvoir à la médecine 2.0
Dominique Dupagne est une figure de la médecine 2.0 en France, on pouvait s’attendre à le voir concocter un livre sur ce sujet. Oh bien sûr, le texte rejoint son sujet de prédilection à un moment donné. Pourtant ce n’est pas le sujet principal de l’ouvrage. Ce livre traite de l’oppression des hiérarchies et plus précisément de l’oppression des hiérarchies des mâles dominants (les femelles étant épargnées par cette quête absurde du pouvoir).
Ce livre a donc trait au fonctionnement de nos sociétés et de nos organisations, ou plutôt de leurs dysfonctionnements. Car l’auteur nous révèle que cette structure pyramidale recèle en elle les germes de sa propre destruction. Mais à ceux qui prétendent que ce fonctionnement n’est pas naturel, Dominique Dupagne nous assène qu’au contraire cet ordre des choses est profondément ancré chez les primates : le mâle pouvant, par sa nature, prétendre à une descendance « illimitée » (ce qui n’est pas le cas des femelles), il s’ensuit une compétition pour la domination ouvrant l’accès aux femelles et à la nourriture. Les arcanes du pouvoir actuel sont une directe incarnation des primates que nous fûmes il y a plus d’un million d’années. Remplaçons la nourriture par l’argent et les femmes par … eh bien toujours les femmes ! Et ce modèle se réplique partout : dans l’entreprise et même les associations ! L’homme a peut-être évolué, mais ses comportements fondamentaux sont toujours au point mort.
L’auteur illustre abondement les fruits de cette organisation : déshumanisation, « standardisation » absurde, systèmes de contrôle qualité sans finalité cohérente (ou sans finalité du tout, d’ailleurs). Bien sûr le monde de la médecine sert abondement à illustrer le propos, avec les dysfonctionnements du système hospitalier, par exemple. Mais aussi par le lobbying des laboratoires, comme dans l’affaire du Mediator qui est largement décortiqué dans ces pages.
Face à ce constat sévère, la seconde partie fait contrepoint : c’est la recherche des solutions. Et pour trouver des solutions, il faut bien comprendre le problème. L’auteur commence par un parallèle avec le système immunitaire qui, loin de concevoir des solutions complexes fonctionne par adaptabilité et convergence. C’est un mode de fonctionnement qui a trait aux systèmes complexes. Et c’est bien de cela dont nous parlons ! La voie qu’explore Dominique Dupagne (et qui nous rapproche de la médecine 2.0) est celle des réseaux sociaux, la force de la connaissance répartie chez les acteurs d’une communauté à comparer à celle d’une élite qui prétendrait détenir la vérité.
Sur ces points, l’enthousiasme de l’auteur me semble exagérer, et bien qu’il se défende de faire, comme il dit, une hagiographie de Google, c’est tout de même ce qu’il fait. Le paysage qu’il dépeint semble idyllique, alors qu’il est loin de l’être ! Maintenant, on ne peut reprocher à l’auteur de défendre ses idées, voir ses croisades : celle d’un Web 2.0 qui pourrait mettre fin aux hégémonies des hiérarchies au pouvoir !
La troisième partie est consacrée au « futur qui marche », où comment on peut trouver aujourd’hui les prémices d’une solution effective. La première qu’énonce l’auteur me fera nécessairement plaisir : il s’agit de l’agilité (et aussi de l’open-source). Les prémices plus éloignées ont trait à la restructuration de l’entreprise et à l’importance de ce que l’on appelle souvent les « liens faibles ». Il s’agit de dynamiques d’entreprise différentes promues entre autre par le Stoos Network. J’aurais pensé que Dominique Dupagne aurait évoqué le sociocratie à plus long terme, mais il a préféré évoquer l’hétérarchie.
Suivre le propos de l’auteur n’est pas évident, surtout au début de l’ouvrage où l’on ne comprend pas vraiment où il veut nous emmener. Mais tout comme il est un orateur hors pair, Dominique Dupagne écrit très, très bien ! Au final le livre n’est pas seulement riche d’enseignement et d’informations. Il est passionnant, éclairant et inspirant. Bref, lisez-le !
Référence complète : La Revanche du Rameur – Dominique Dupagne – Michel Lafon 2012 – ISBN : 978-2-7499-1587-6
Si les faits ne correspondent pas à la théorie, changez les faits.
Albert Einstein
Agile Playground #12
Cela faisait un moment que l’Agile Playground m’échappait. La faute à un agenda difficile à concilier. C’était réglé pour cette fois. Nous nous retrouvions de nouveau dans les locaux de CLT pour cette nouvelle édition.
Au programme un jeu (et un seul) : Au tableau ! Ce jeu a largement été promu par Alex Boutin, bien qu’il n’en soit pas l’auteur.
Le but du jeu est simple : on nous donne la situation d’un portefeuille de projets, et à partir de là il faut trouver la forme de “management visuel” donnant le meilleur impact. 2 itérations de 20 minutes sont prévues, entrecoupées d’une dizaine de minutes de rétrospective. Nous n’étions pas nombreux, nous avons donc formé 3 équipes de 6 ou 7 personnes.
L’une des équipe disposait d’une table
Les deux autres utilisaient une tenture adhésive. Avec pas mal de difficultés à faire tenir dessus ce que nous voulions.
Petit (gros) biais de l’exercice : y participaient des personnes rompues au management Visuel ou au Kanban. Le résultat de la première itération montrait des résultats plutôt très convergents, avec quelques particularismes locaux.
La seconde itération intégrait bien de nouveaux éléments, mais qui ne posaient guère de problème à des habitués. Au final, l’inspiration transverse aidant, les résultats se montraient réellement semblables !
Il y avait peu à dire sur les directions prises par chaqune des solutions. La discussions de fin a plutôt porté sur les différentes dynamiques de groupes, je pense que ce n’était pas dans la cible de l’exercice. J’en tire quelques conclusions :
- L’exercice est plutôt destiné aux novices. Cela n’est pas si porteur de le faire avec des vétérans. De plus, les niveaux hétérogènes ont mal marché dans notre cas. Probablement de notre faute.
- Il faut limiter le nombre de personnes par tableau. Nous étions 7, c’est beaucoup trop : on ne peut pas travailler autour du tableau en si grand nombre. Je dirais que 4 est le maximum.
- Nous aurions dû en profiter pour délirer plus, faire un Kanban circulaire avec des swimlanes en forme de part de camembert ou d’autres choses dans le genre. Non seulement nous nous serions plus amusé, mais il y aurait même pu y avoir des choses inattendues à en retirer !
Venez comme vous êtes au FKUG !
“venez comme vous êtes”, c’était le thème de cette première rencontre des affiionados de Kanban ! Au programme : 2 présentations chez “un grand de l’assurance dont le nom commence par A” et “l’acteur majeur des paris hyppiques en France”. Couthaïere Farfra, à l’origine de ce groupe, assurera la première présentation, ainsi qu’une rapide et efficace présentation du groupe, de ses objectifs et de son organisation.
A force de trainer mes guêtres dans diverses réunions agiles, on fini par connaitre du monde. C’est mon cas, et débarquer en connaissant déjà une bonne moitié de l’audience est plutôt agréable, on se sent en famille. Cela a aussi son petit côté jubilatoire quand ceux que vous ne connaissez pas vous voient aborder tout le monde comme s’il s’agissait de vieux amis (c’est d’ailleurs le cas pour certains). On s’amuse comme on peut, n’est-ce pas ?
Kanban à grande échelle chez un grand de l’assurance.
Couthaïer nous fait ici un retour sur la mise en place, les pratiques et les impacts d’une mise en place sur un grand plateau de développement impliquant un grand nombre d’équipes, en mode distribué qui plus est : les product owner étant sur un autre site. Cette transition vers Kanban s’est opéré à partir d’un processus “Scrum”. Je mets des guillemets car à la description, il me semble qu’il s’agissait là d’un Scrum “Canada Dry”, customisé pour les besoins du client comme on dit. Chaque fois que j’entends cela, je sais que je ne dois pas m’attendre au meilleurs…
Quoi qu’il en soit, cette mise en place a commencé par un pilote : 2 équipes totalisant 30 personnes (tout compris). L’accompagnement a pris une allure standardisée : 8 semaines à temps plein par coach et par équipe. Chaque coach ne s’occupe que d’une équipe ! Au niveau de a portée du suivi, sont exclus :
- La partie amont : identification et spécification du besoin
- La partie aval, dévolue à la partie “devops” !
Les objectifs sont également clairs :
- La satisfaction du client
- Améliorer la qualité
- Tenir les promesses (!)
La mise en place du Kanban reflète le backlog, avec des passages d’état : MMF >> Acceptée >> Critère d’acceptante >> BDD >> INVEST >> Dévelopment >> Tests
A cela se rajoutent bien sûr la mise en place de limites, qui doivent à terme nous permettre de connaitre la véritable capacité de notre système. La maitrise de cette capacité est en bonne partie subordonnée au fait que les stories entrant dans le système sont relativement homogènes en terme de taille. Dans la pratique, elles sont estimées au stade “INVEST”.
Au Kanban lui-même s’ajoute la mise en place de KPI : ici c’est le “cockpit”. Tout cela est bien beau, mais prends beaucoup de place. En fait, le plus gros problème est là : trouver des murs pour afficher ces Kanbans !
Supprimer les gaspillages
Ils sont subordonnés aux obstacles. Et les obstacles, il faut les surmonter. Ils sont de deux types: les petits obstacles et les gros obstacles.
Pour les petits obstacles, on passe par des fiches Kaisen. La revue des obstacles s’effectue lors du stand-up sur le tableau de suivi des obstacles.
Pour les gros obstacles, on passe par des A3 et des Kata.
Réduire les anomalies
Le pair testing est une activité clé ici, dans le cas présente entre un développeur et un testeur. Les anomalies sont considérées comme critiques : on les traitent sans attendre. Au bout du compte, un ratio d’anomalies très réduit, de l’ordre de 0,7 anomalies par User Stories.
La délocalisation : c’est tellement mieux de se compliquer la vie…
Comme je l’ai évoqué, le “avant”, c’était du Scrum pas vraiment “by the book”. En fait, un mixte qui me semble un peu contre nature entre Scrum (au moins le vocable), CMMi et le near shore. C’est une des difficultés de la chose.
La réponse mise en oeuvre est un Kanban miroir sur le site délocalisé, synchronisé au début du stand-up commun aux différents sites. Cet aspect de synchronisation est un des aspects difficiles. Les outils électroniques n’ont pas ce problème mais leur lacune en terme de visualisation limitée pose d’autres questions…
Tenir les promesses
Le CFD (cumulated flow diagram) est l’outil utilisé à priori pour suivre la machine Kanban. Il donne des indications sur :
- Le débit
- Les goulots d’étranglement
- Les en cours
Cela dit, il n’est pas facile à lire… Le CFD montre verticalement le débit, il peut permettre d’extrapoler une date d’atterrissage et montre aussi les perturbations, là où la monotonie de la courbe est rompue. L’axe horizontal montre les temps de cycle, du moins une approximation de ceux-ci. On peut comparer les deux approches, mais c’est un poil compliqué.
Le suivi du Kanban, c’est aual le suivi d’indicateurs issus de son évolution. Ici ils sont mis à jour hebdomadairement. Un point crucial est que la pertinence des informations reste très subordonnée à l’homogénéité des items qui figurent sur ce Kanban !
Pause éclair
Guère beaucoup de temps pour se dégourdir les jambes, on a à peine 5 minutes pour cela. J’aimerais bien échanger avec certaines personnes. Ce sera pour après, peut-être…
Renaud Chevalier : La conception d’un Kanban en suivant la méthode Morrisseau
Laurent serait fier de son disciple : Renaud va nous faire suivre la mise en place de son Kanban en suivant sa méthode. Il l’apprécie et elle marche. Démonstration.
Cette mise en place a été effectuée chez “l’acteur national majeur des paris hippiques”. Si vous n’avez pas compris,cherchez encore. Il nous faut remonter à Septembre 2012 pour comprendre l’origine de cette mise en place. A l’époque, le projet fait face à deux inquiétudes majeures :
- Un problème de “qualité” de backlog, qui ne donne que 2 sprints de visibilité. En tout cas, c’est rangé dans les problèmes par le management.
- Un risque technologique lié aux choix opérés : Du Java en back-end exposant des services ReST, un front-end en backbone.js et une gestion de contenu accédée en ReST ; c’est du Drupal. Ce n’est pas la mort, mais bon on est chez … af ! C’est vrai… on ne peut pas le dire !
La dessus, la vision macro de ce qui reste à réaliser annonce 1 an de retard ! Branle-bas de combat ! Audit !!
Les propositions issues de l’audit proposent entre autre la mise en place d’un grand Kanban transverse, voilà qui est intéressant ! En plus, ça ne parait pas si difficile, un Kanban. Il est rapidement mis sur pied.
Hélas, trois fois hélas : au bout de 2 semaines seulement, ce Kanban ne vit plus ! Que s’est-il passé ? Renaud décide de reprendre les choses à la base, donc de suivre la démarche de Laurent Morrisseau.
La portée et les objectifs
Justement, on met directement le doigt là où ça a pêché : une portée trop importante de ce Kanban initial ! La portée du Kanban doit être celle où l’équipe est propriétaire du processus. Ce n’était pas le cas du Kanban précédent, remontant trop en amont (dans l’élaboration du besoin) et en aval (dans la partie production / exploitation).
De plus, inutile également de produire un Kanban correspondant à un processus cible. Il faut commencer là où l’on est, avec le processus courant.
Pour matérialiser les objectifs, il faut identifier ceux-ci ainsi que les insatisfactions actuelles. Cela s’est fait sous forme d’interviews.
La nature de la demande
Pour la connaitre, il faut identifier ce qui arrive à l’équipe, ce qui l’alimente. Dans le cas présent, on a :
- Les anomalies en provenance de la QA
- Les demandes du marketing
- Les “stories techniques”
- La dette technique
La question subsidiaire est celle de la taille de ces demandes. Comme on l’a vu précédemment, la qualité du Kanban est subordonné à l’homogéneité des items. Ici, Renaud va utiliser les tailles T-Shirt pour évaluer ces items (S, M, L, XL).
Enfin, pour se faire une idée de la situation actuelle, on procède à 3 analyses:
- Débit par Sprint et par type de demandes
- Débit par sprint et par taille T-Shirt
- Débit par catégorie d’anomalies
Le flux de travail et carte Kanban
Au départ, il faut identifier le workflow spécifique à chaque type de demande. En l’occurrence, chacune des 4 catégories a son propre cycle, seules les demandes marketing rentrant dans les sprints !
4 catégories de demandes, cela veut dire 4 cartes Kanban. Elles diffèrent légèrement en contenu en fonction de leur type, mais les éléments de même nature se retrouvent au même endroit : la rigueur d’organisation est un facteur clé d’efficacité. On affectera aussi une couleur spécifique à chaque type de demande. Nous verrons que cela s’avère très important au niveau du tableau.
Le tableau
Justement, le tableau nous y sommes ! Et l’on commence par déterminer les règles de priorités des demandes, quel que soit leur type. C’est intéressant, car on a coutume de subordonner la priorité au type. Or ici on va utiliser l’évaluation du “cout du délais”. C’est une bonne façon d’éviter de se faire hacker le système en transformant une demande en anomalie, par exemple !
Donc, sur ce tableau, on commence par alimenter le système par type de demande, et le premier triage consiste à réalimenter la suite du tableau par classe de service en utilisant ce facteur de cout du délais. Comme chaque classe de service peut théoriquement contenir n’importe quel type de demande, il est opportun de pouvoir facilement distinguer facilement ces différents types : d’où les couleurs !
Règles, règles…
C’est là que l’on rentre dans le volet pas très “agile mind set” du Kanban. Cela couvre 3 volets :
- Les règles aux interfaces : Quelle règle pour réalimenter le système ? Quel règle pour déclencher la sortie des items ? C’est aussi (surtout) une question diplomatique avec les équipes avec lesquelles on collabore…
- Les règles internes. Elles sont de plusieurs types. La principale est la “definition of done” qui permet à une carte de passer à l’étape suivante. Les autres règles traitent des exceptions (escalade, changement de priorité, annulation, etc.)
- Enfin, la grande question : qui s’occupe du respect des règles. La réponse est : le process manager ! Oui, vous avez bien lu, on a un process manager, comme il y a 20 ans !
La capacité du système
Le système en place, il s’agit maintenant de le monitorer et le “tuner”. Au départ, il faut fixer des limites hautes et basses, de manière plus ou moins empirique au départ. Un point particulier concerne la gestion de la dette technique : on en garde toujours une en cours. C’est un tâche de faible prioité qui peut être interrompue pour répondre à une classe de service de niveau le plus élevé.
Le juste à temps et la cadence
Travailler en mode Kanaban ne signifie pas abandonner complètement les rituels réguliers. En fait chaque rituel a sa propre cadence, et ce n’est pas calé de manière global sur une fin d’itération. En fonction du type de cérémonie, on trouvera des rythmes :
- Journaliers
- Hebdomadaires
- Pluri-hebdomadaires
</FKUG #1>
Si j’ai trouvé la seconde session particulière instructive et bien présentée, je dois dire que globalement le contenu de ce premier rendez-vous valait largement le coup. En fait, il était même mieux que ce à quoi je m’attendais !
Expérience réussie, donc. J’ai hâte d’être au second rendez-vous !
Software Freethinker 
