Présentation de KARMA à la conférence Frug'Agile
Comment travailler ensemble en gardant un bon karma
Voici le script de la présentation de l’outil KARMA, un outil pour améliorer sa maitrise de l’agilité, donnée pour la conférence Frug’Agile.
Lean
La radicalité agile pour conjurer le faux agile
Il faut bien le dire, le terme radical est susceptible d'en rebuter quelques-uns ; d'autres nous demandent pourquoi avoir conservé agilité dans agilité radicale. Retour sur le choix des mots.
Quand nous avons lancé l’agilité radicale en avril 2020 — c’était pour la keynote à Agile en ligne — dans les échanges avec les participants, nous avons eu quelques remarques sur le choix du mot radical :
radical, c’est un peu extrême !
Radical, c’est comme radis, ça vient de racine.
Lecture au klub : Lean Entreprise
Si la science est largement évoquée, les gens ne sont pas oubliés
Le livre choisi pour le klub d’octobre était donc : Lean Enterprise: How High Performance Organizations Innovate at Scale de Jez Humble, Joanne Molesky, Barry O’Reilly.
L’agilité en mouvement
L'agilité est un outil formidable pour découvrir une façon dynamique de faire les choses. Dynamique dans le sens où il ouvre de nouvelles pistes aux personnes qui réfléchissent à leur façon de travailler
J’avais écrit ce texte il y a quelques mois, en réaction à un article prétendant que l’agilité ne répondait pas aux problématiques abordées ci-dessous, alors que le Lean oui. Je le publie maintenant pour rajouter une couche au billet de Pablo Cow boys et hippies.
C’est le moment.
Lean depuis les tranchées, le draft en VF
Piloter de gros projets avec Kanban, l'histoire de la police suédoise
Henrik Kniberg a publié Lean from the trenches chez The Pragmatic Programmers en fin d’année 2011. Il l’a écrit de façon itérative et a sorti plusieurs versions intermédiaires. C’est une de ces versions, le draft 0.9, que nous avons traduite.
Bien sûr, c’est avec l’accord d’Henrik :
Cette version draft est gratuite. Je l’ai rendue disponible pour ceux qui ont un budget serré et qui ne peuvent pas s’offrir le livre, ou qui souhaitent parcourir le draft pour se faire une idée générale de la portée du livre avant de l’acheter.
Le multi-tâches c'est mal
Combien faut-il de temps pour écrire un prénom ?
Ça dépend.
Ce matin, commençait ma (déjà !) 8ème formation de l’année. Je fais notamment une série de formations Scrum pour les développeurs qui travaillent sur le smartphone d’Intel à Toulouse.
Dans mon fil twitter j’avais vu passer il y a quelques jours la traduction en français du jeu inventé par Henrik Kniberg pour illustrer les méfaits du multi-tâches.
Séminaire 'L'agilité : du projet au programme et à la ligne de produits'
IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits
J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée.
Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Limitez le TAF
Diagramme de flux cumulé
Il a été produit avec l’outil IceScrum. En abscisse on a les sprints. En ordonnée, on a le nombre de stories dans chaque état de son workflow.
Dans cet exemple, les données sont celles du projet IceScrum lui-même. Les sprints durent 2 semaines et représentent environ l’équivalent de 3-4 jours de travail (les membres de l’équipe sont à temps partiel).
Ce type de diagramme a été mis en avant par David Anderson qui promeut le Lean Software et en particulier la pratique du Kanban.
Rétrospective 2009
Pour Scrum et les méthodes agiles, l'année 2009 a été celle de la confirmation
Je vais essayer de faire un bilan de l’année sur quelques aspects qui ont été significatifs de mon point de vue.
La diffusion se poursuit La place de l’agilité et de Scrum dans le développement de logiciel a continué d’augmenter. Cela se voit dans les médias spécialisés. Les grands éditeurs sont désormais aussi porteurs du message agile. On peut dire qu’il y a un buzz, mais au-delà de l’aspect communication, la diffusion se poursuit en France. Concrètement quand je recherche des offres d’emploi Scrum sur un moteur de recherche, j’en trouve maintenant sur plusieurs pages. Le nombre de formations Scrum a nettement cru. Il y a aussi de plus en plus de filières universitaires pratiquant l’enseignement des méthodes agiles.
Le burnup
Mieux que le burndown
Le burndown chart montre bien ce qui reste à faire, mais on n’y voit pas les évolutions de périmètre. Il y a 2 ans, j’avais présenté l’intérêt du burnup à 2 courbes pour pallier ce manque du burndown.
Obeya
Le Lean pour apprendre le japonais ?
Hier j’étais en déplacement à Paris pour une réunion de préparation à l’introduction de l’agilité dans une organisation offshore. J’en ai profité pour assister à la présentation sur le Lean chez Zenika, c’était en soirée. La présentation était assurée par Pascal van Cauwenberghe. J’avais participé à un de ses ateliers au XP Day 2007. Cette fois-ci, c’était sur The Toyota Way.
Pratiques d'équipe française
Ces derniers mois, la région Rhône-Alpes paraît avoir décollé sur l’agilité.
Un club d’agilistes s’est créé. Des blogueurs y apparaissent, comme Alex. Les étapes de l’Agile tour de Valence et Grenoble affichent déjà complet.
Des retours d’expérience y sont publiés, comme celui d’Emmanuel Chenu qui raconte les pratiques mises en place pour faciliter la communication dans son équipe.
L’article qu’il publie est plutôt bluffant quand on sait que cette équipe développe des logiciels temps-réel critiques embarqués pour l’avionique(ce que j’ai fait pendant plusieurs années dans ma vie de développeur).
Du tableau des tâches au Kanban
Vers le ScrumBan
Le Lean est à la mode. Au delà des principes qui ne sont pas discutables, je suis sceptique sur ce que les gens en font vraiment sur le terrain. Le Lean ne constitue pas, pour le logiciel, une méthode fournissant un cadre de mise en œuvre bien définie comme l’est Scrum. Jusqu’à maintenant, le Lean m’est apparu, à travers mes lectures, comme une attitude, présentant plus de principes que de pratiques. J’essaie bien d’appliquer du Lean sur mes projets, mais cela reste ponctuel.
Rétrospective sur l'ingénierie du logiciel
Un œil dans le rétroviseur
La rétrospective, c’est le nom une réunion servant à améliorer le processus. Elle commence par une présentation chronologique de faits passés. Revenir sur le passé pour préparer l’avenir.
Je viens de lire 2 rétrospectives sur le développement de logiciel faits par 2 illustres agilistes.
Mary Poppendieck, la gouroute du Lean, a présenté à Agile2008 Expanding Agile Horizons: The Five Dimensions of Systems Sa présentation fait une large part au passé du génie logiciel.
Le backlog de problèmes
Encore un backlog ?
Le but de la réunion quotidienne, appelée Scrum daily meeting (Scrum) ou StandUp meeting (XP), est d’identifier les problèmes, par la 3ème question posée à chacun.
Pas de bottleneck au concert de Robert Plant (ex Led Zeppelin)
Et je ne parle pas du jeu du guitariste
Bottleneck, en anglais c’est un goulet d’étranglement mais c’est aussi une technique de guitare, d’ailleurs utilisée par Jimmy Page
J’étais hier au concert de Robert Plant and the Strange Sensations au festival de Carcassonne.
La dernière fois que j’ai vu Robert Plant sur scène c’était le 27 mars 1973.
Il était alors le chanteur de Led Zeppelin et c’était au Parc des Expositions de Nancy lors de la fameuse tournée européenne du printemps 73. Le concert de Nancy avait provoqué l’annulation des suivants en France, la moitié des spectateurs[1] sont rentrés sans payer et l’organisateur est parti avec la caisse.
Les courbes de croissance d'un projet
Le beurdone montre la décroissance du reste à faire tandis que le burnup montre la croissance de ce qui est fait.
Cet article décrit les courbes qu’on peut produire à partir d’une estimation des stories en points. Il montre les faiblesses du burndown chart et présente des alternatives. Il introduit des notions venant du Lean, comme le diagramme de flux cumulé, le TAF et le DDD.
Tous les bateaux tous les chapeaux
J'ai assisté la semaine dernière, lors du XP Day, à un atelier sur la théorie des contraintes.
L’atelier Mon processus s’étrangle était animé par Pascal van Cauwenberghe.
Ca commence par une simulation avec 7 volontaires qui vont construire des bateaux et des chapeaux en papier. Chacun joue une rôle particulier : client, analyste, concepteur, plieur, testeur… L’objectif est d’identifier le goulet d’étranglement du processus. La présentation est basée sur la théorie des contraintes.
Le goulet a été facile à identifier et nous avons essayé les techniques pour exploiter la contrainte.
De l'automobile au logiciel
Dans la famille des méthodes agiles, le Lean
Sur France Inter ce matin, on parle de Toyota qui est devenu le numéro 1 mondial de l’automobile. Les interviews associées mettent en avant la préoccupation constante des besoins des automobilistes et la qualité des produits, obtenue grâce à un système de production original. Cette gestion d’entreprise est appelée Lean.
Le Lean est décliné depuis quelques années sur l’industrie du logiciel, en particulier par Mary Poppendieck. Les principes de la pensée Lean sont tout à fait dans l’esprit des méthodes agiles avec une emphase particulière qui est mise sur l’élimination du gaspillage. Le gaspillage[1] est défini comme tout ce qui ne crée pas de valeur pour le client. L’objectif d’une approche agile est de favoriser la simplicité, qui est l’art de maximiser le travail non fait. Dans le développement de logiciel, il existe de nombreux gaspillages qui peuvent être éliminés. J’ai fait en mars un audit chez un éditeur de logiciel où, compte tenu des objectifs à court terme, l’élimination de gaspillages était la possibilité la plus évidente d’améliorer la productivité, la plus facile à mettre en œuvre.
Emergence progressive des exigences
Plutôt que d'essayer de tout figer au début mieux vaut décider au dernier moment possible.
Il est impossible de connaître toutes les exigences[1] dès le début d’un projet. Depuis 20 ans j’ai participé à de nombreuses définitions et spécifications d’exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d’imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d’exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l’avance.