scrumban

Arrêter Scrum pour le flux, un début d’expérience

Suite à ma présentation à Lean Kanban France, j’ai reçu un message de Sophie. Elle accompagne une équipe confrontée à des difficultés avec Scrum qu’elle a aiguillée vers Kanban. Son expérience est intéressante et elle la raconte bien, alors nous avons décidé de la publier. Il s’agit donc d’un billet invité, autrement dit de guest blogging. Voici le message de Sophie de Sophia : Bonjour Claude, Je viens de lire ta présentation “Appliquer Kanban sur Scrum”… j’aurais bien aimé y assister !
Participation à Lean Kanban France

Participation à Lean Kanban France

Appliqué sur Scrum, Kanban permet d’éviter les débordements pendant un sprint. (dessin de Patrice Courtiade) Après avoir passé la journée du lundi avec mes camarades de la Fédération Agile pour notre conversation semestrielle, je participerai le mardi 3 novembre à Lean Kanban France. LKFR une conférence super intéressante avec des orateurs européens (et un américain) de grande qualité. Je présenterai une session à 17h “Appliquer Kanban sur Scrum”, qui reprend les idées évoquées ICI.

Arrêter Scrum pour le flux, mmmmh !

Parmi les raisons évoquées par ceux qui disent “on arrête Scrum pour passer au flux”, certaines m’apparaissent très discutables : les réunions prennent trop de temps, le sprint est un carcan qui met la pression sur les équipes, on déploie à un rythme différent du sprint, alors pourquoi le garder ? En effet, on peut rétorquer que ce ne sont pas des réunions, que si on y regarde de plus près ce sont souvent les estimations qui prennent du temps et qu’on peut tout à fait les supprimer en continuant Scrum.

Chapitre douze

Dans la série Suppléments en ligne de mon livre, voici Adapter Scrum au contexte qui constitue le chapitre 12 de la troisième édition. Le résumé en fin du chapitre Scrum ne se vend pas en pack de 6. Sélection des pratiques et adaptation au contexte sont les deux mamelles de son application sur un projet. Structure du chapitre Voici le plan de ce chapitre (clic pour agrandir).

Préface de Kanban pour l'IT, 1ère partie

La première fois que j’ai parlé de Kanban dans ce blog, c’était en 2008, un billet suite à ma lecture de Scrum-Ban de Corey Ladas. Depuis Kanban a fait son chemin dans l’IT. On en parle de plus en plus dans les conférences. Sur le terrain, je vois de plus en plus d’équipes qui s’y intéressent. Maintenant j’aborde régulièrement de Kanban dans mon blog. Les formations, comme celle de sensibilisation à Toulouse la semaine dernière suscitent de l’intérêt.
Automne tour 2013

Automne tour 2013

Je viens de recevoir la réponse du comité d’organisation d’Agile Grenoble. Ma proposition de session est acceptée. J’avais fait 3 soumissions à des conférences de cet automne. Elles sont retenues toutes les 3 : Kanbanisez votre Scrum pour Lean Kanban France les 3 et 4 octobre, La culture du backlog pour Agile tour Toulouse du 10 octobre, Du gros backlog aux petits bacs limités pour Agile Grenoble du 21 novembre.
Première formation Kanban à Toulouse

Première formation Kanban à Toulouse

Je suis très content d’avoir animé cette formation avec Laurent Morisseau. Un co-training particulièrement enrichissant pour moi et aussi pour les 12 participants, tous satisfaits et même 8 très satisfaits. Voici les témoignages de Cyril, Christophe, Sophie, Kévin et Mathieu : C’était vraiment excellent et très instructif. Un atelier pratique génial pour amorcer la théorie. Utile pour l’IT et en dehors. Excellente maîtrise, contenu riche et clair. Me conforte dans l’utilisation quotidienne de Kanban et lève mes interrogations et doutes.
Kanban, classes de service avec iceScrum

Kanban, classes de service avec iceScrum

La version actuelle d’iceScrum n’implémente pas de véritable Kanban, mais il est possible de s’appuyer sur les facilités de management visuel offertes par l’outil pour, avec quelques astuces, disposer d’un tableau Kanban. Ce tutoriel décrit une façon de faire permettant de gérer un flux des travaux. Elle est adaptée à de petites équipes distribuées. Elle fonctionnera aussi très bien pour une personne seule, je l’ai testée depuis 2 mois. J’avais écrit l’an dernier 2 articles sur comment faire du ScrumBan avec iceScrum.

Les classes de service

Parmi ce qu’apporte Kanban, une notion qui a particulièrement attiré mon attention est la classe de service. Dans son livre Kanban pour l’IT, Laurent Morisseau l’aborde dans le chapitre 17, donc plutôt vers la fin de l’ouvrage, en la considérant comme un “modèle émergent”. Comme j’aime bien essayer les nouveautés, je l’ai appliquée pour mes activités personnelles. Auparavant, je m’étais déjà exercé à : deux pratiques de Scrumban,
La porte des travaux

La porte des travaux

Le jardin, je m’y suis remis et c’est l’époque où il y a plein de choses à faire. L’an dernier, j’avais utilisé iceScrum avec du ScrumBan pour les travaux de jardin. Mais depuis le dernier printemps j’ai changé la porte de mon bureau. Elle est blanche et lisse. Bref, tout à fait apte à y coller des post-it. Et une porte avec des post-it, c’est pratique pour le management visuel. Il y a la porte des feedbacks que j’utilise maintenant -plus ou moins- en formation.

Mise à jour de Scrum

J’ai appris la mise à jour du guide Scrum de Ken Schwaber et Jeff Sutherland quelques jours après avoir envoyé le bon à tirer pour la deuxième édition de Scrum, le guide pratique etc… Damned, me suis-je dit, plus moyen de prendre en compte des changements, s’il y en avait d’importants. J’avais lu la première version du guide lorsque j’écrivais la première édition de mon livre. Lecture rapide, le nombre de pages n’est pas important.

Pratiques de ScrumBan

J’avais écrit au printemps deux articles montrant comment on pouvait mâtiner Scrum avec des notions venant de Kanban. La mise en œuvre de ce ScrumBan était présentée avec un usage d’iceScrum. Quelques mois plus tard, après du feedback d’utilisateurs et une utilisation poussée, j’ai remis à jour les articles : ScrumBan version tâches ScrumBan version stories Ces deux techniques de ScrumBan permettent de suivre des travaux qui arrivent au fil de l’eau, en flux continu.
Rétrospective du SigmaT18

Rétrospective du SigmaT18

Ce soir c’était le SigmaT18 à la Maison des Associations de Toulouse. Ce qui aurait pu mieux se passer Plus de monde ! Nous étions une quinzaine seulement. Le temps froid pour un mois de juin qui n’a pas poussé à continuer les discussions sur la terrasse Le champ ouvert, prévu au programme, qui n’a pas eu lieu, faute de temps disponible (le retour d’expérience s’est terminé à 20h30) et de … Thierry Ce qui a bien marché L’histoire bien racontée et pleine d’enseignements de la startup Webinage La façon de nous montrer l’intérêt du feedback par l’évolution du produit depuis le backlog initial Le partage sur le retour d’expérience, avec les très nombreuses questions qui ont fusé lors de la présentation Le module 2 de la Maison des associations est agréable, la logistique impeccable pour ce type d’événement L’apéro, apporté par Marie-Josée Nous avons une nouvelle adhérente Idée Webinage pour ma mère ?
ScrumBan au canal

ScrumBan au canal

Avec l’épisode ScrumBan au jardin, j’avais présenté une façon de mixer Scrum et Kanban. En voici une autre, toujours dans l’idée de tirer le meilleur des 2. Cette approche est destinée à ceux qui, ayant essayé Scrum, ont trouvé que le cadre des sprints avec son cérémonial était un peu trop contraignant pour leur contexte. Généralement, ce contexte est caractérisé par une équipe légère qui reçoit un flux relativement continu d’entrées.
ScrumBan au jardin

ScrumBan au jardin

Quand je suis au jardin, il m’arrive, pendant que j’y vaque, d’avoir besoin d’un outil et de l’aller chercher. Souvent, je m’arrête en chemin, attiré par une fleur de ciste qui éclot ou par une mauvaise herbe qui dépasse, et je me mets à vaquer à autre chose. J’ai tendance à ne pas finir ce que j’ai commencé. La plupart du temps, cela n’a aucune importance, le jardin, c’est pour le plaisir, pas question de m’imposer quelque contrainte genre du Scrum.
ScrumBan

ScrumBan

Mélange de Scrum et de Kanban, la nouvelle tendance ? Si on se réfère à l’assistance que nous avons eue lors du Scrum Day et aux échos que la présentation a suscités, le ScrumBan[1] est un sujet qui intéresse. Faire une présentation à trois, c’est cool. Et ça laisse le temps de prendre des photos. Pendant que mes petits camarades Antoine et Fabrice vantaient les mérites respectifs de Scrum et Kanban, avant de parler de ScrumBan, j’ai pris ce cliché :

Scrum et Kanban, les 2 sont empiriques

Dans notre présentation au Scrum Day, comment tirer le meilleur de Kanban & Scrum, avant de montrer les différences, nous reviendrons sur les similitudes entre les 2. Parmi celles-ci, le fait que les deux sont empiriques[1]. On peut grossièrement identifier 3 activités concernées par l’empirisme. Planifier en détail La planification détaillée ne se fait pas longtemps à l’avance, mais juste à temps. Pour cela, on découpe ce qu’il y a à faire dans le produit en morceaux (par exemple des stories) et on ne planifie de façon détaillée ces morceaux qu’au moment de les réaliser.

Scrum et les tâches urgentes

Pendant un sprint, une équipe Scrum ne devrait pas, en principe, être perturbée. Cependant il arrive que des perturbations correspondent à des travaux urgents qui ne peuvent pas attendre, alors que faire ? Lors de la réunion de planification du sprint, l’équipe, après avoir identifié les tâches à faire pendant le sprint, s’engage sur un périmètre (constitué par une liste de stories) et sur la qualité avec laquelle elle va le produire (défini par la signification de fini).

Scrum Day France 2011

Le French Scrum User Group organise un événement d’une journée pour la première fois. C’est le Scrum Day qui aura lieu le jeudi 31 Mars 2011. Le programme vient d’être publié et j’ai le plaisir de voir que je suis dedans : avec mes complices Antoine et Fabrice pour un remake de Kanban & Scrum tirer le meilleur des 2, cela se passera le matin, pour une session l’après-midi à 15H45, placée dans le track Scrum-ALM; elle a pour titre “Scrum au-delà du projet, pour des produits et des organisations”.

Travaux pour préparer le backlog

Le Product Owner, et aussi toute l’équipe, doivent anticiper le prochain sprint pendant le sprint courant. Pour qu’un sprint commence dans de bonnes conditions, il convient que chaque story qui rentre dans ce sprint soit prête[1]. La signification de prêt pour une story dépend de l’équipe (comme la signification de fini). En général, cela implique que la story soit estimée, suffisamment petite pour tenir dans le sprint et suffisamment comprise par l’équipe pour être développée.