lean

Lecture au klub : Lean Entreprise

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. Un gros livre. En anglais, ce qui n’a pas attiré les foules. Mais, bien que je fusse le seul à l’avoir lu entièrement (et sur mon smartphone !), la discussion s’est avérée passionnante. Un livre qui présente plein de choses, certaines dont je parle régulièrement sur ce blog et dans mon livre (le développement agile, impact mapping, lean startup, kanban) et d’autres un peu moins (design thinking, value stream mapping, devops).
L’Agilité en mouvement

L’Agilité en mouvement

J’ai la chance de faire partie de la communauté Agile et discuter fréquemment avec ses membres éminents. J’ai aussi le grand plaisir de faire des formations et des prestations d’accompagnement en binômes avec certains d’entre eux. Nous avons des parcours différents, cependant nous avons tous trempé dans le développement de logiciel, plus ou moins selon les sensibilités. Et nous nous sommes retrouvés dans le mouvement agile, certains plus récemment que d’autres, mais tous avec le même enthousiasme pour mettre en œuvre les pratiques agiles tout en partageant les mêmes valeurs et principes.

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 ? Ca 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. Alors, comme j’aime bien essayer rapidement les nouveaux jeux innovants que je découvre et que ce jeu du prénom me semblait très pertinent dans le contexte Intel, je l’ai expérimenté ce matin.

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.

Les photos du TOC

Plutôt que le toc des photos… En attendant le debriefing avec Thierry (disons la rétrospective des animateurs) que nous allons faire dans la semaine, voici les photos de l’atelier Théorie des contraintes (TOC en anglais), présenté jeudi matin lors de l’Agile Tour Toulouse. Un grand merci aux participants.

Limitez le TAF

Ceci est un diagramme de flux cumulé. Celui-ci 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[1].

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.
Le burnup

Le burnup

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. J’avais fait un schéma à la main pas très beau. Maintenant qu’IceScrum produit plein de graphiques, dont le burnup, j’en profite pour réactualiser sa présentation. Le burnup présente 2 courbes : la verte qui est fini la bleue le périmètre du projet Pour chaque sprint, ce graphique demande de collecter 2 valeurs pour construire ces courbes.

Ambiance chez Toyota

Le Lean Software est à la mode. Sa mise en avant se base beaucoup sur l’exemple de la réussite de Toyota dans la production. Bon, après la lecture de cet article sur l’ambiance à l’usine Toyota d’Onnaing, il va falloir modérer sérieusement les références à Toyota en France. Au moins sur un des 7 concepts, qui est : respecter les personnes. Ca montre aussi l’importance du contexte culturel.

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. Je ne vais pas vous raconter les 14 principes du Toyota Way ni les commentaires de Pascal, j’ai été pris de vitesse.

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).

Quel est le meilleur outil agile open source ?

Un indice : ça commence par un I La réponse est sur le site Agile Tools. Il faut lire jusqu’en bas. On voit que l’auteur a essayé IceScrum sérieusement avant de faire ses commentaires. Malheureusement il n’a pas lu mon tutorial concernant la planification des releases, ni celui sur la gestion d’un sprint, qui aident à prendre en main l’outil sur ces aspects. Il faut dire qu’ils n’existent qu’en français.

Direction vers le futur de l'Agile

David Anderson est un visionnaire. Dans sa présentation à Agile2008 disponible sur InfoQ, il donne des directions pour l’Agile tout en expliquant son histoire. C’est 1h30 de très haut niveau. Pour le résumer, l’Agile doit s’ouvrir à l’extérieur, prendre en compte le Lean, se placer au niveau de l’entreprise et s’appuyer sur une notion de maturité des organisations. Pour cela David Anderson met en avant 3 pratiques : le Kanban Real Options CMMI

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 oeuvre 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.

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. La création d’une liste de problèmes (ou backlog de problèmes) permet de les gérer effectivement. C’est la responsabilité du ScrumMaster de les classer par priorité et de faire en sorte qu’ils soient réglés au plus vite. Certains peuvent être du ressort de l’équipe, d’autres ne peuvent avoir une solution qu’avec l’intervention de personnes extérieures, dans d’autres équipes (par exemple, si une équipe support s’occupe de l’environnement de développement) ou au niveau de la direction du projet.
Pas de bottleneck au concert de Robert Plant (ex Led Zeppelin)

Pas de bottleneck au concert de Robert Plant (ex Led Zeppelin)

Et je ne parle pas du jeu du guitariste[1]… Notes [1] 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.
Les courbes de croissance d'un projet (3)

Les courbes de croissance d'un projet (3)

Dernier épisode de la série Le beurdone est simple mais limité en cas de variation de périmètre, le beurneupe montre mieux les changements dans les exigences. Avec une approche Agile, un morceau fonctionnel est complètement développé dans une itération, il n’est pas donc utile de montrer sur une courbe les morceaux qui sont simplement analysés, conçus, codés. Il est cependant intéressant de montrer avec des courbes de croissance multiples les états de ces éléments avant le début de l’itération.
Les courbes de croissance d'un projet (2)

Les courbes de croissance d'un projet (2)

La deuxième partie sur les mesures d’avancement d’un projet. Le beurdone, c’est bien. Le beurneupe à 2 courbes, c’est encore mieux comme l’a bien montré Matthieu dans son commentaire. Les 2 sont le reflet des mesures faites sur des petits éléments qui apportent de la valeur[1]. Le beurneupe est basé sur 2 états de cet élément : identifié pour la courbe du haut, fini pour la courbe du bas. Et si on ajoutait d’autres états ?