C'est un must have pour un scrum master et toutes les parties prenantes qui se lancent dans l'aventure Scrum. D'ailleurs le succès de la première édition est là pour le confirmer. Alors bonne chance pour cette seconde édition!
vendredi 23 septembre 2011
Scrum : Le guide pratique - 2ème édition
Pour la sortie de cette seconde édition, Claude m'a envoyé son livre
J'ai été vraiment agréablement surpris par la clarté du texte et son exhaustivité, sa maîtrise de Scrum fait la différence. Claude a enrichi cette seconde édition notamment d'un chapitre sur Scrum a grande échelle.Il n'évite aucun thème sur lesquels on me challenge lors de mes formations Scrum.
C'est un must have pour un scrum master et toutes les parties prenantes qui se lancent dans l'aventure Scrum. D'ailleurs le succès de la première édition est là pour le confirmer. Alors bonne chance pour cette seconde édition!
C'est un must have pour un scrum master et toutes les parties prenantes qui se lancent dans l'aventure Scrum. D'ailleurs le succès de la première édition est là pour le confirmer. Alors bonne chance pour cette seconde édition!
dimanche 18 septembre 2011
Obeya Lean-Kanban
Je serais orateur à Agile Tour Rennes et Vannes cette année. Je vous propose à cette occasion une nouvelle session sur les Obeya Lean-Kanban.
Sans en dire plus maintenant, voici ce que cela va donner:
Obeya Lean-Kanban
Alors si le sujet vous intéresse, rendez-vous à Agile Tour!
jeudi 8 septembre 2011
Atelier Kanban, l'injection d'éléments
J'utilise lors des formations Kanban un atelier assez ludique que j'ai présenté déjà plusieurs fois sur ce blog et en conférence également:
Un des points à suivre est la stratégie d'injection d'éléments dans le système Kanban.
Quand et pourquoi l'équipe choisie d'injecter plutôt tel ou tel élément?
Une des première réponse est les classes de service, qui permet de catégoriser les éléments. Mais personnellement, j'introduis les classes de services après avoir fait l'atelier. Donc ils se servent peu de cette information.
Nous faisons 4 petites rétrospectives pendant l'atelier et je demande aux équipes de décrire leur stratégie.
Il est intéressant de noter qu'elle s'affine au cours de l'atelier et change selon le contexte du jeu (ou l'état de leur système).
Au départ, la priorisation est généralement liée uniquement à la valeur - en l’occurrence le nombre de nouveaux inscrits que la story apporte.
Rapidement, la priorisation s'affine et prend également en compte le coût total de la story (celui-ci étant détaillé pour les activités de conception, développement et test).
Valeur métier sur le coût, c'est la base de la priorisation agile, viennent ensuite les contraintes de dates fixes dans le jeu.
Pas convaincu? essayez donc l'atelier Le jeu de la valeur métier!
Théorie des contraintes
Il se trouve que les tests sont, par conception de l'atelier, un goulot d'étranglement, à plusieurs reprises. Alors une bonne majorité des équipes priorise rapidement par la valeur et le coût des tests, c'est à dire par le coût du goulot d’étranglement plus que le coût total. Cette approche pleine de bon sens est une des conclusions de la théorie des contraintes. Cela donne également une piste pour optimiser notre effort d'estimation.
Takt time
Hier, lors d'une formation intra, l'une des deux équipes n'a pas explorée cette piste d'optimisation mais une autre assez étonnante: Une alternance de story peu coûteuse et coûteuse. l'objectif étant de stabiliser le système. Cela m'a interpellé car c'est une des pratiques Lean pour stabiliser les chaînes de production d'alterner les séquences longues et courtes de travail. Cette séquence étant calculée sur la base du Takt time. Le Kanban étant l'autre outil permettant de stabiliser le système. Je n'avais pas encore pensé ou su exploiter cela dans nos systèmes.
Pour finir l'histoire, cette équipe n'a pas gagnée mais elle avait les cartes de contrôles de temps de cycle ayant le moins de variabilité. A méditer donc.
Intéressé? mes prochaines formations Kanban : Rennes le 23 Septembre, Paris le 28 Octobre
Quand et pourquoi l'équipe choisie d'injecter plutôt tel ou tel élément?
Une des première réponse est les classes de service, qui permet de catégoriser les éléments. Mais personnellement, j'introduis les classes de services après avoir fait l'atelier. Donc ils se servent peu de cette information.
Nous faisons 4 petites rétrospectives pendant l'atelier et je demande aux équipes de décrire leur stratégie.
Il est intéressant de noter qu'elle s'affine au cours de l'atelier et change selon le contexte du jeu (ou l'état de leur système).
Au départ, la priorisation est généralement liée uniquement à la valeur - en l’occurrence le nombre de nouveaux inscrits que la story apporte.
Rapidement, la priorisation s'affine et prend également en compte le coût total de la story (celui-ci étant détaillé pour les activités de conception, développement et test).
Valeur métier sur le coût, c'est la base de la priorisation agile, viennent ensuite les contraintes de dates fixes dans le jeu.
Pas convaincu? essayez donc l'atelier Le jeu de la valeur métier!
Théorie des contraintes
Il se trouve que les tests sont, par conception de l'atelier, un goulot d'étranglement, à plusieurs reprises. Alors une bonne majorité des équipes priorise rapidement par la valeur et le coût des tests, c'est à dire par le coût du goulot d’étranglement plus que le coût total. Cette approche pleine de bon sens est une des conclusions de la théorie des contraintes. Cela donne également une piste pour optimiser notre effort d'estimation.
Takt time
Hier, lors d'une formation intra, l'une des deux équipes n'a pas explorée cette piste d'optimisation mais une autre assez étonnante: Une alternance de story peu coûteuse et coûteuse. l'objectif étant de stabiliser le système. Cela m'a interpellé car c'est une des pratiques Lean pour stabiliser les chaînes de production d'alterner les séquences longues et courtes de travail. Cette séquence étant calculée sur la base du Takt time. Le Kanban étant l'autre outil permettant de stabiliser le système. Je n'avais pas encore pensé ou su exploiter cela dans nos systèmes.
Pour finir l'histoire, cette équipe n'a pas gagnée mais elle avait les cartes de contrôles de temps de cycle ayant le moins de variabilité. A méditer donc.
Intéressé? mes prochaines formations Kanban : Rennes le 23 Septembre, Paris le 28 Octobre
mardi 6 septembre 2011
Agile Tour Rennes
Ça y est! Le programme d'Agile Tour Rennes est quasi finalisé. Les inscriptions en ligne sont ouvertes ici. 22 sessions vous sont proposées orientées sur l'agilité pas mal d'ateliers, également du Lean & Kanban et pas mal de nouveautés, et toujours des standards d'Agile Tour Rennes:
Je présenterais à cette occasion une session Lean-Kanban sur l'Obeya Kanban.
Et mon flux, c'est du goulet?
Initialiser à une démarche Kanban est simple. Il n'y a qu'à lire les principes du Kanban:
On visualise donc notre processus avec un tableau kanban (avec un petit k) et on met des limites sur les états de notre processus: un tableau de taches et un nombre limité de points de complexité pour l'itération, défini par l'équipe. On partage la définition de prêt et de fini avec toute l'équipe. Et on s'améliore au rythme des rétrospectives.
Pas de quoi s'affoler donc! On fait déjà tout ça avec l'agilité. Y a qu'à même dire qu'on fait tous du Kanban.
D'ailleurs, au dernier sondage du French SUG, 28% des interviewés annonçait en faire.
En passant, 14% annoncent faire du Lean Software Developpement. Merci les gars pour la vanne, ça détend!
Alors que vient faire le principe "Mesurer et gérer le flux de travail" dans tout ça?
On passe à un développement en flux, au-delà du flux de valeur ou du flux de travail. Mais de manière étonnante, je n'ai pas trouvé ou retenu (mais toi lecteur, peut-être en connais-tu?) de bonne définition du développement en flux bien que différents auteurs en parlent sur les thèmes du Lean Software Developpement, du Kanban bien sur, du Scrum Ban, ... et bien sur dans le livre de Reinertsen sur le développement en flux de produit.
Cela revient à travailler sur une pièce en continue, l'unité de travail, qui va constituer le flux :
A l'usage, le fait qu'elle apporte de la valeur n'est pas techniquement le plus important pour mettre en place du flux, c'est plus que cet élément soit un vecteur de communication pour tous les acteurs, qu'il fasse sens pour chacun pour que cette unité soit adoptée par tous. Cal va donc dépendre de votre contexte bien sur, histoire utilisateur, cas d'utilisation, ticket d'incident, anomalie, ... et de votre granularité MMF, MVP, ...
Essayer de passer à un développement en flux change la donne et c'est difficile. Pour y arriver on va parler de choses que l'on connaît déjà : taille des batchs, limites sur le TAF, cadence, mais également de file d'attente, de buffer, de variabilité, de synchronisation...
Et effectivement, cela nécessite une mesure et un contrôle différents à la fois plus élémentaire, en suivant le temps de cycle de chaque pièce; régulier en contrôlant le débit du flux, facteur de santé du flux; et plus global avec les courbes de valeurs cumulées (suivi cumulé du nombre de pièces dans mon système par état) pour une analyse plus systémique.
Et là, les modèles de type Théorie des contraintes vont nous être bien utile pour comprendre et améliorer.
Alors, pensez-vous développer en flux?
On peut effectivement faire du Kanban sans développement en flux et rester sur un système tiré. La mécanique Kanban permet cela. Et le Lean également:
- Visualiser le processus
- Limiter le travail en cours à la capacité de l’équipe
- Mesurer et gérer le flux de travail
- Rendre les caractéristiques du processus explicite
- S’améliorer de manière collaborative
On visualise donc notre processus avec un tableau kanban (avec un petit k) et on met des limites sur les états de notre processus: un tableau de taches et un nombre limité de points de complexité pour l'itération, défini par l'équipe. On partage la définition de prêt et de fini avec toute l'équipe. Et on s'améliore au rythme des rétrospectives.
Pas de quoi s'affoler donc! On fait déjà tout ça avec l'agilité. Y a qu'à même dire qu'on fait tous du Kanban.
D'ailleurs, au dernier sondage du French SUG, 28% des interviewés annonçait en faire.
En passant, 14% annoncent faire du Lean Software Developpement. Merci les gars pour la vanne, ça détend!
Alors que vient faire le principe "Mesurer et gérer le flux de travail" dans tout ça?
On passe à un développement en flux, au-delà du flux de valeur ou du flux de travail. Mais de manière étonnante, je n'ai pas trouvé ou retenu (mais toi lecteur, peut-être en connais-tu?) de bonne définition du développement en flux bien que différents auteurs en parlent sur les thèmes du Lean Software Developpement, du Kanban bien sur, du Scrum Ban, ... et bien sur dans le livre de Reinertsen sur le développement en flux de produit.
Cela revient à travailler sur une pièce en continue, l'unité de travail, qui va constituer le flux :
Ensemble d'éléments évoluant dans un sens communEt qui apporte de la valeur et faire en sorte qu'elle parcourt notre processus de réalisation le plus vite et de manière la plus fluide possible.
A l'usage, le fait qu'elle apporte de la valeur n'est pas techniquement le plus important pour mettre en place du flux, c'est plus que cet élément soit un vecteur de communication pour tous les acteurs, qu'il fasse sens pour chacun pour que cette unité soit adoptée par tous. Cal va donc dépendre de votre contexte bien sur, histoire utilisateur, cas d'utilisation, ticket d'incident, anomalie, ... et de votre granularité MMF, MVP, ...
Essayer de passer à un développement en flux change la donne et c'est difficile. Pour y arriver on va parler de choses que l'on connaît déjà : taille des batchs, limites sur le TAF, cadence, mais également de file d'attente, de buffer, de variabilité, de synchronisation...
Et effectivement, cela nécessite une mesure et un contrôle différents à la fois plus élémentaire, en suivant le temps de cycle de chaque pièce; régulier en contrôlant le débit du flux, facteur de santé du flux; et plus global avec les courbes de valeurs cumulées (suivi cumulé du nombre de pièces dans mon système par état) pour une analyse plus systémique.
Et là, les modèles de type Théorie des contraintes vont nous être bien utile pour comprendre et améliorer.
Alors, pensez-vous développer en flux?
On peut effectivement faire du Kanban sans développement en flux et rester sur un système tiré. La mécanique Kanban permet cela. Et le Lean également:
Flow is important. Leveling, flow when you can, pull when you can't. [...] But that's just technique, it's a way to reveal problems, nothing more.[The Lean Manager p 33]Mais pour avoir pu mettre en place du flux à plusieurs reprises, c'est un outil d'apprentissage réel et un révélateur d'obstacles et d'opportunités d'amélioration bien plus important que le système tiré, et qui demande une discipline au quotidien. Et c'est bien sa finalité de contrainte le système toujours un peu plus pour apprendre et s'améliorer.
Inscription à :
Commentaires (Atom)