KanbanAndScrum FR

Kanban et Scrum tirer le meilleur des deux
Henrik Kniberg & Mattias Skarin Prfac par Mary Poppendieck & David Anderson Traduit par Claude Aubry, Frdric Faure, Antoine Vernois & Fabrice Aimetti
2010 C4Media Inc. Tous droits rservs. C4Media, Editeur de InfoQ.com. Ce livre fait partie de la collection des livres de la socit InfoQ spcialise dans le dveloppement de logiciel. Pour toute information ou commande de ce livre ou d'un autre livre de la socit InfoQ, prire de contacter books@c4media.com. Aucune partie de cette publication ne peut tre reproduite, stocke ou transmise sous quelque forme que ce soit ou par quelque moyen, lectronique, mcanique, photocopie, enregistrement, numrisation ou tout autre, sauf en vertu des articles 107 ou 108 de la loi sur le droit de reproduction (Copyright Act) des Etats-Unis promulgue en 1976 et avec l'autorisation pralable crite de l'diteur. Les appellations utilises par les entreprises pour distinguer leurs produits sont communment appeles des marques. Dans tous les cas o C4Media Inc. est amen porter plainte les noms des produits apparatront en initiales majuscules ou en LETTRES CAPITALES. Les lecteurs devront toutefois contacter les socits concernes pour obtenir des informations plus compltes concernant les marques et leur enregistrement. Rdacteur en Chef : Diana Plesa Illustration de la Couverture : Bistrian Iosip Composition: Accurance Bibliothque du Congrs pour la publication de donnes : ISBN: 978-0-557-13832-6 Imprim aux Etats-Unis
Sommaire
PREFACE DE MARY POPPENDIECK .............................................. vi PREFACE DE DAVID ANDERSON................................................... vii INTRODUCTION.................................................................................. xii 1ERE PARTIE - COMPARAISON........................................................ 1 1. Que sont Scrum et Kanban ? .................................................................. 3 2. Quels sont les liens entre Scrum et Kanban ?......................................... 7 3. Scrum impose des rles........................................................................ 13 4. Scrum impose des itrations de dure fixe........................................... 15 5. Kanban limite le TAF chaque tape du workflow, Scrum limite le TAF chaque itration ...................................................................... 17 6. Les deux sont empiriques..................................................................... 19 7. Scrum autorise peu de changement dans une itration......................... 27 8. Le tableau Scrum est rinitialis chaque dbut ditration ................ 29 9. Scrum impose des quipes multidisciplinaires..................................... 31 10. Les lments du backlog Scrum doivent tenir dans le sprint ............. 33 11. Scrum impose estimation et vlocit.................................................. 35 12. Les deux permettent de travailler sur plusieurs produits simultanment37 13. Les deux sont Lean et Agile............................................................... 39 14. Des diffrences mineures ................................................................... 41 15. Tableau Scrum vs Tableau Kanban un exemple moins trivial ........ 45 16. Rsum de Scrum vs Kanban............................................................. 53 2EME PARTIE ETUDE DE CAS ..................................................... 57 17. Le mtier dexploitant ........................................................................ 59 18. Pourquoi diable changer ? .................................................................. 61 19. Par o commencer ? ........................................................................... 63 20. Pour sy mettre ................................................................................... 65 21. Mise en ordre de marche des quipes................................................. 67 22. Impliquer les parties prenantes........................................................... 69 23. Construire le premier tableau ............................................................. 71 24. Fixer une limite de travail en cours la premire fois .......................... 75
25. Respecter la limite de TAF ................................................................ 77 26. Quelles tches afficher sur le tableau ? .............................................. 79 27. Comment estimer ? ............................................................................ 81 28. Alors, comment avons-nous travaill, concrtement ?....................... 83 29. Trouver un concept de planning qui fonctionne................................. 87 30. Quoi mesurer ? ................................................................................... 91 31. Comment les choses ont commenc changer .................................. 95 32. Leons apprises ................................................................................ 101 POINTS A RETENIR.......................................................................... 105 LES AUTEURS.................................................................................... 107 LES TRADUCTEURS......................................................................... 109
INTRODUCTION | v
Glossaire
Ajout par les traducteurs pour permettre aux lecteurs de comprendre les choix de traduction de certains termes anglais. kanban Kanban Mot japonais signifiant tiquette (ou fiche-signal). Pratique (ou outil de processus pour reprendre la dfinition d'Henrik Kniberg) base sur l'utilisation de kanban pour matrialiser des informations sur le processus. Temps de cycle. Minimum Marketable Feature. Fonctionnalit minimale qui a de la valeur pour lutilisateur. En anglais, la mle. Dans ce livre, Scrum est utilis pour dsigner la mthode agile (ou outil de processus pour reprendre la terminologie d'Henrik Kniberg) et scrum pour la runion quotidienne d'une quipe. endroit o sont placs les kanban (Board en anglais). Avec Scrum, on parle de tableau des tches. Travail Finir (WIP : work in progress en anglais). Kanban limite le TAF, c'est dire le nombre de travaux faire dans une tape du processus. Par raccourci, on dira TAF de 2 pour une limite 2 kanban dans une colonne du tableau. Bloc de temps dure fixe. Work In Progress = Travaux en cours. Traduit par TAF.
Lead time MMF scrum
Tableau TAF
Timeboxed WIP
Prface de Mary Poppendieck

Henrik Kniberg fait partie des rares personnes qui peuvent extraire l'essence d'une situation complique, faire le tri entre les ides importantes et celles qui sont accessoires, et fournir une explication limpide incroyablement facile comprendre. Dans ce livre, Henrik fait un travail brillant pour expliquer les diffrences entre Scrum et Kanban. Il prcise clairement que ce sont seulement des outils, et que ce qui vous importe vraiment est d'avoir une bote outils complte, de comprendre les points forts et les limites de chaque outil et d'acqurir la manire de les utiliser. Avec ce livre, vous apprendrez ce qu'est Kanban, ses forces et ses limites, et quand l'utiliser. Vous apprendrez galement comment et quand Kanban peut amliorer Scrum, ou tout autre outil que vous utilisez. Henrik montre clairement que le plus important n'est pas l'outil avec lequel vous commencez, mais la faon dont vous amliorez constamment son utilisation et comment vous dveloppez progressivement votre ensemble d'outils. La deuxime partie de ce livre, crite par Mattias Skarin, rend la lecture encore plus instructive pour le praticien travers l'application de Scrum et Kanban en situation relle. Vous y trouverez un exemple montrant la faon dont ces outils ont t utiliss, un par un et ensemble, pour amliorer un processus de dveloppement logiciel. Vous remarquerez qu'il n'y a pas une unique meilleure manire de faire les choses ; c'est vous seul de rflchir et de dcouvrir - en fonction de votre contexte quelle est votre prochaine tape vers un meilleur processus de dveloppement logiciel. Mary Poppendieck
Prface de David Anderson

Kanban est bas sur une ide trs simple : le nombre de travaux faire (TAF) dans un processus doit tre limit, donc une nouvelle tche ne peut tre ajoute que si une autre est, au pralable, termine ou utilise la demande d'un processus aval. Le kanban (littralement la fiche-signal) est un signal visuel produit pour indiquer qu'un nouveau travail peut tre entrepris parce que les travaux en cours n'excdent pas la limite fixe. Cela ne semble pas trs rvolutionnaire et on ne s'attend pas ce que cela affecte fortement la performance, la culture, la capacit et la maturit d'une quipe et de son organisation environnante. Ce qui est surprenant c'est que cela arrive ! Kanban ressemble un petit changement et pourtant il bouleverse l'entreprise. En fait, Kanban est une approche de gestion du changement. Ce n'est ni un processus de dveloppement ou de gestion du cycle de vie d'un logiciel ni une mthodologie de gestion de projet. Vous pouvez commencer appliquer le principe de Kanban en partant de la faon dont vous travaillez actuellement. Vous commencez par spcifier votre processus en cartographiant sa chane de valeur et vous dfinissez des limites de TAF pour chaque tape de ce processus. Vous pouvez alors lancer le flux de travail en l'entranant travers le systme lorsque des signaux kanban sont gnrs. Kanban s'avre utile aux quipes qui dveloppent du logiciel avec des mthodes agiles, mais est aussi de plus en plus appliqu par les quipes qui suivent une approche plus traditionnelle. Kanban fait partie du cadre de l'approche Lean, qui a pour but de s'adapter la culture des organisations et favorise l'amlioration continue. Parce que le TAF est limit dans un systme Kanban, tout ce qui se bloque, pour une raison quelconque, a tendance engorger le systme. Si trop d'lments de travail se bloquent, tout le processus finit par s'arrter.
Alors toute l'quipe (et l'ensemble de l'organisation) se concentre sur la rsolution du problme, le dblocage de l'lment concern et le rtablissement du flux de travail. Kanban emploie un mcanisme de contrle visuel pour suivre le flux de travail qui circule travers les diffrentes tapes de la chane de valeur. On utilise typiquement un tableau blanc avec des post-its ou un systme lectronique mural. La meilleure pratique est probablement de combiner les deux. La transparence gnre contribue aussi au changement de culture. Les mthodes agiles apportent des bnfices en favorisant la transparence sur l'avancement des travaux en cours et termins et en produisant de nouveaux indicateurs, comme la vlocit (la quantit de travail ralise dans une itration). Toutefois, Kanban va un peu plus loin et assure la transparence dans le processus et son flux. Kanban expose les goulets d'tranglement, les files d'attente, la variabilit et le gaspillage. Toutes ces choses qui influent sur la performance de l'organisation en termes de mesure des lments valeur ajoute produits et de temps de cycle ncessaire pour les produire. Aux membres de l'quipe et aux intervenants externes, Kanban offre la visibilit sur l'effet de leurs actions (ou inactions). Ainsi, les premires tudes de cas ont montr que Kanban modifie les comportements et encourage une plus grande collaboration au sein des organisations. La visibilit sur les goulets d'tranglement, les gaspillages et le manque de rgularit, ainsi que leur impact, encourage aussi les dbats sur les progrs possibles et les quipes commencent rapidement mettre en uvre des tches d'amlioration de leurs processus. En consquence, Kanban encourage l'volution progressive des processus existants et cette volution correspond globalement aux valeurs de l'Agilit et du Lean. Kanban n'exige pas de rvolutionner de fond en comble la faon dont les gens travaillent, il encourage plutt un changement progressif. Le changement est compris et adopt par consensus parmi les employs et leurs collaborateurs. Kanban, bas sur un systme flux tir, encourage galement un engagement au plus tard, la fois sur la priorisation du travail et la livraison du travail en cours. Typiquement, les quipes vont convenir d'une frquence pour rencontrer les parties prenantes et dcider sur quoi travailler dans la suite. Ces runions peuvent tre tenues rgulirement
INTRODUCTION | ix
parce qu'elles sont gnralement trs courtes. Une question trs simple peut y tre aborde, quelque chose comme : Depuis notre dernire runion, deux crneaux de travail se sont librs. Notre temps de cycle actuel jusqu' la livraison est de 6 semaines. Quelles sont les 2 choses que vous aimeriez voir livres dans 6 semaines ?. Cela a une double incidence. Poser une question simple se traduit gnralement par une rponse de bonne qualit obtenue rapidement et permettant de maintenir une runion courte. La nature de cette question signifie que l'engagement de sur quoi travailler est retard jusqu'au dernier instant. Cela amliore l'agilit en grant les exigences, en raccourcissant les temps de cycle de l'engagement la livraison et en liminant le travail de remise niveau puisque le risque d'un changement dans les priorits sera minimis. Un dernier mot sur Kanban est que l'effet de limiter le TAF assure la prdictibilit du temps de cycle et produit des livrables de meilleure qualit. L'approche Arrter la chane lorsque des obstacles et des bugs sont dtects semble aussi encourager un haut niveau de qualit et une baisse rapide du retravail. Bien que tout cela apparaisse vident avec les explications merveilleusement claires fournies dans ce livre, comment nous en sommes arrivs l reste obscur. Kanban n'a pas t conu en un seul aprs-midi par quelque incroyable manifestation. Au lieu de cela, il est apparu sur plusieurs annes. Un grand nombre de ses profonds impacts psychologiques et sociologiques sur la culture, la capacit et la maturit des organisations n'avaient pas t imagins. Ils ont plutt t dcouverts. Bon nombre des rsultats obtenus avec Kanban sont contre-intuitifs. Ce qui semble tre une approche trs mcanique - limiter le TAF et tirer le flux de travail - a effectivement eu des effets profonds sur les gens et la faon dont ils interagissent et collaborent entre eux. Je n'avais pas prvu cela, ni d'ailleurs quiconque aux premiers jours de son implication dans Kanban. J'ai appliqu ce qui est devenu Kanban comme une approche du changement entranant une rsistance minimale. C'tait clair pour moi ds 2003. Je l'ai aussi mis en uvre pour ses bnfices mcaniques. la mme poque, j'tais en train de dcouvrir les applications des techniques Lean et, si la gestion du TAF avait un sens, le limiter en avait encore plus. Ainsi en 2004, j'ai dcid d'essayer de mettre en uvre un systme flux
ix
tir partir des premiers principes. J'en ai eu l'opportunit lorsqu'un directeur de Microsoft m'approcha et me demanda de l'aider changer son quipe en charge des mises jour de maintenance sur les applications informatiques internes. La premire mise en uvre tait base sur la Thorie des Contraintes d'un systme flux tir connue sous le nom de Drum-Buffer-Rope. a a t un norme succs : le temps de cycle a chut de 92%, le dbit a t multipli au moins par 3 et la prdictibilit (respect de la date d'chance) affichait un trs acceptable 98%. En 2005, Donald Reinertsen m'a convaincu de mettre en uvre un systme Kanban plus grande chelle. J'en ai eu l'occasion en 2006 lorsque j'ai pris en charge le Dpartement d'ingnierie logiciel chez Corbis Seattle. En 2007, j'ai commenc communiquer sur les rsultats. La premire prsentation a t faite au New Product Development Summit Chicago en Mai 2007. J'ai poursuivi avec un Open Space lors de l'Agile 2007 Washington DC en aot. 25 personnes taient prsentes. 3 d'entre elles taient de Yahoo! Aaron Sanders, Karl Scotland et Joe Arnold. Ils rentrrent en Californie, en Inde et au Royaume-Uni pour mettre en uvre Kanban avec leurs quipes, qui taient dj aux prises avec Scrum. Ils ont galement lanc un groupe de discussion Yahoo! qui, au moment o j'cris, a presque 800 membres. Kanban commenait se propager et les premiers pratiquants partageaient leurs retours d'exprience. Aujourd'hui, en 2009, Kanban est de plus en plus adopt et de nombreux retours remontent du terrain. Nous avons beaucoup appris sur Kanban dans les 5 annes passes et nous continuons tous apprendre chaque jour davantage. J'ai consacr mes propres travaux la pratique de Kanban, crire sur Kanban, parler de Kanban et rflchir sur Kanban afin de mieux le comprendre et l'expliquer aux autres. J'ai volontairement laiss de ct le fait de comparer Kanban avec les mthodes agiles existantes, mme si, en 2008, certains de mes efforts ont t consacrs expliquer pourquoi Kanban mritait d'tre considr comme une approche agile. J'ai laiss d'autres, qui avaient une exprience plus large, le soin de rpondre des questions comme Comment Kanban se compare-t-il Scrum ? Je suis trs heureux qu'Henrik Kniberg et Mattias Skarin aient merg comme des leaders dans ce domaine. Vous, les praticiens, avez besoin d'informations afin de prendre des dcisions claires et d'avancer dans votre travail. Henrik et Mattias sont au service de vos besoins, et
INTRODUCTION | xi
d'une manire que je n'aurais jamais pu mettre en uvre. Je suis particulirement impressionn par l'approche rflchie d'Henrik en matire de comparaison et de livrable factuel et neutre. Ses dessins et illustrations sont particulirement perspicaces et vous permettent souvent d'conomiser beaucoup de temps de lecture. L'tude de cas faite sur le terrain par Mattias est importante car elle dmontre que Kanban est beaucoup plus qu'une thorie : il vous montre par l'exemple comment Kanban pourrait vous tre utile dans votre organisation. J'espre que vous apprcierez ce livre comparant Kanban avec Scrum et qu'il vous donnera un meilleur aperu sur l'Agilit en gnral et sur Kanban et Scrum en particulier. Si vous voulez en savoir plus sur Kanban, je vous invite visiter notre site web communautaire, The Limited WIP Society, http://www.limitedwipsociety.org/ David J. Anderson Sequim, Washington, Etats-Unis 8 Juillet 2009
xi
Introduction
Nous n'avons pas l'habitude d'crire des livres. Nous prfrons passer notre temps au fond des tranches aider les clients optimiser, dboguer et remanier leur processus de dveloppement et leur organisation. Cependant, ces derniers temps, nous avons clairement remarqu une tendance et nous souhaitions vous faire part de quelques rflexions sur ce sujet. Voici un exemple typique : Claude : Nicolas : Finalement nous sommes passs Scrum ! Et comment a va ?
Claude : Eh bien, cest beaucoup mieux que ce que nous avions avant Nicolas : mais ?
Claude : mais en fait je suis dans une quipe de support & maintenance. Nicolas : Oui, et alors ?
Claude : a nous plat de mettre en uvre les principes de priorisation du backlog de produit, d'quipe autoorganise, de scrums quotidiens, de rtrospectives, Nicolas : Claude : Nicolas : Et donc, quel est le problme ? Nous ne parvenons pas tenir nos sprints. Pourquoi a ?
Claude : Parce cest dur de sengager sur un planning de deux semaines. Le principe de litration na pas beaucoup de sens pour nous, nous travaillons juste sur ce qui est le plus urgent chaque jour. Peut-tre faudrait-il rduire les sprints une semaine ?
Nicolas : Pouvez-vous vous engager sur une semaine de travail ? Va-t-on vous laisser travailler en paix pendant une semaine ? Claude : Pas vraiment, de nouveaux problmes surviennent chaque jour. Peut-tre que si nous rduisions les sprints 1 jour Nicolas : Est-ce que vous arrivez rsoudre vos problmes en moins dune journe ? Claude : Non, cela prend parfois plusieurs jours.
Nicolas : Donc cela ne fonctionnera pas mieux avec des sprints de 1 journe. Avez-vous envisag de vous passer des sprints ? Claude : Eh bien, franchement, on aimerait bien. Mais est-ce que cela ne va pas contre Scrum ? Nicolas : Scrum est juste un outil. Cest vous qui choisissez quand et comment lutiliser. Nen soyez pas esclave ! Claude : Nicolas : Que devons-nous faire alors ? Avez-vous entendu parler de Kanban ?
Claude : Quest-ce que cest ? Quelle est la diffrence avec Scrum ? Nicolas : Lisez ce livre !
Claude : Mais jaime beaucoup les autres principes de Scrum, est-ce quil faut vraiment changer ? Nicolas : Claude : Nicolas : Non, vous pouvez combiner les deux techniques ! Ah bon ? Et comment ? Il suffit de lire la suite
INTRODUCTION | xv
Objectif de ce livre
Si vous vous intressez aux mthodes agiles pour le dveloppement de logiciel, vous avez probablement entendu parler de Scrum, et vous avez peut-tre galement entendu parler de Kanban. La question que nous entendons de plus en plus souvent est C'est quoi Kanban, quelle diffrence avec Scrum ? Sont-ils complmentaires et de quelle faon ? Dans quels cas peuvent-ils rentrer en conflit ? Le but de ce livre est de vous donner une vision plus claire qui vous permettra de comprendre comment Kanban et Scrum peuvent tre utiles dans votre environnement de travail. Faites-nous savoir si nous avons russi !
xv
1re Partie - Comparaison

Cette premire partie du livre consiste en un essai de comparaison objective et pratique de Scrum et Kanban. Il s'agit d'une petite mise jour de la version de l'article original Kanban vs Scrum publi en avril 2009. Cet article tant devenu populaire, j'ai alors dcid d'en faire un livre et j'ai demand mon collgue Mattias de l'enrichir avec une tude de cas depuis les tranches de l'un de nos clients. Excellent boulot ! Vous pouvez passer directement la Partie II si vous prfrez commencer par l'tude de cas, je ne serai pas vex. En fait, peut-tre juste un peu.
/Henrik Kniberg
1
Que sont Scrum et Kanban ?
OK, essayons de rsumer Scrum et Kanban, chacun en moins de 100 mots.
Scrum en bref
Divisez votre organisation en petites quipes multidisciplinaires et auto-organises.
Divisez votre travail en une liste de petits livrables concrets. Triez cette liste par priorit et estimez la taille relative de chaque lment.
4 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX
Divisez le temps en petites itrations de dure fixe (appeles des sprints et durant habituellement de 1 4 semaines) et faites une dmonstration lissue de chaque sprint avec un produit potentiellement livrable.
Optimisez le planning de la version et mettez jour les priorits en collaboration avec le client, sur la base de ce que vous avez appris aprs chaque sprint. Optimisez le processus en organisant une rtrospective aprs chaque sprint.
Ainsi, au lieu d'avoir un grand groupe passant beaucoup de temps sur la construction d'une grande chose, nous avons une petite quipe passant un peu de temps construire une petite chose mais intgrant rgulirement pour voir l'ensemble. 150 mots on y est presque. Pour plus de dtails consultez Scrum and XP from the Trenches1. Le livre est disponible gratuitement en ligne. Je connais lauteur, il est sympa http://www.crisp.se/ScrumAndXpFromTheTrenches.html Pour plus de liens http://www.crisp.se/scrum sur Scrum, je vous renvoie sur
Kanban en bref
Visualisez le workflow : o Divisez votre travail, dcrivez chaque lment sur une fiche et mettez-la au mur.
NdT : le livre a t traduit en franais : http://www.infoq.com/resource/news/2007/06/scrum-xpbook/en/resources/ScrumAndXpFromTheTrenches_French.pdf
QUE SONT SCRUM ET KANBAN ? | 5
Tracez des colonnes et donnez-leur le nom des tapes du workflow pour y placer les lments de travail.
Limitez le TAF : fixez des limites prcises indiquant combien dlments peuvent tre placs dans chaque tape du workflow.
Mesurez le temps de cycle (temps moyen pour traiter compltement un lment, appel lead time en anglais), optimisez le processus pour que le temps de cycle soit aussi court et prvisible que possible.
Vous trouverez des liens utiles sur Kanban : http://www.crisp.se/kanban
2
Quels sont les liens entre Scrum et Kanban ?
Scrum et Kanban sont tous les deux des outils de processus
Outil = nimporte quoi pouvant tre utilis pour accomplir une tche ou atteindre un but. Processus = faon dont vous travaillez. Scrum et Kanban sont des outils de processus en ce sens quils vous aident travailler plus efficacement en vous disant, dans une certaine mesure, quoi faire. Java est un outil, il vous fournit un moyen plus simple de programmer un ordinateur. Une brosse dent est aussi un outil, elle vous aide atteindre vos dents afin de pouvoir les nettoyer.
Comparer les outils pour mieux les comprendre et non pour les juger
Couteau et fourchette : quel est le meilleur outil ?
Cette question n'a pas trop de sens, n'est-ce pas ? Parce que la rponse dpend de votre contexte. Pour manger des boulettes de viande, la fourchette est probablement le meilleur choix. Pour hacher des champignons, le couteau est probablement le meilleur choix. Pour jouer
7
du tambour sur la table, les deux feront l'affaire. Pour manger un steak, vous aurez vraisemblablement besoin d'utiliser les deux outils ensemble. Pour manger du riz, eh bien certains prfrent la fourchette tandis que d'autres prfrent les baguettes.
Donc, en comparant des outils, on se doit d'tre prudent. Comparez pour mieux comprendre et non pour juger.
Aucun outil n'est complet, aucun outil n'est parfait

Comme tout outil, Scrum et Kanban ne sont ni parfaits ni complets. Ils ne vous disent pas tout ce que vous avez faire, ils vous fournissent juste quelques contraintes et quelques directives. Par exemple, Scrum vous contraint avoir des itrations de dure fixe et des quipes multidisciplinaires, et Kanban vous contraint utiliser des tableaux visibles et limiter la taille de vos files d'attente. Fait intressant, l'intrt d'un outil est qu'il limite les options. Un outil de processus qui vous permet de faire nimporte quoi n'est pas trs utile. On pourrait appeler ce processus Faire Nimporte Quoi ou mme Faire La Bonne Chose. Le processus Faire La Bonne Chose est garanti pour marcher, c'est comme une baguette magique ! Si a ne marche pas, c'est parce que vous n'tes manifestement pas en train d'appliquer le processus Utiliser les bons outils vous aide russir, mais ce n'est pas une garantie de succs pour autant. Il n'est pas facile de discerner entre la russite/lchec dun projet et la russite/l'chec dun outil. Un projet peut russir grce un trs bon outil. Un projet peut russir malgr un mauvais outil. Un projet peut chouer cause dun mauvais outil. Un projet peut chouer malgr un trs bon outil.
QUELS SONT LES LIENS ENTRE SCRUM ET KANBAN ? | 9
Scrum est plus normatif que Kanban

On peut comparer les outils en regardant le nombre de rgles quils fournissent. Normatif signifie plus de rgles suivre et adaptatif signifie moins de rgles suivre. 100% de normatif signifie que vous n'avez pas besoin d'utiliser votre cerveau, il y a une rgle pour tout. 100% dadaptatif quivaut faire nimporte quoi, il n'y a aucune rgle ni aucune contrainte. Comme vous pouvez le deviner, les deux extrmes de l'chelle sont ridicules. Les mthodes agiles sont parfois qualifies de mthodes lgres, en particulier parce qu'elles sont moins normatives que les mthodes traditionnelles. Dailleurs, le premier principe du Manifeste Agile est Les Individus et leurs Interactions plutt que les Processus et les Outils. Scrum et Kanban sont tous les deux trs adaptatifs, mais, relativement parlant, Scrum est plus normatif que Kanban. Scrum vous donne plus de contraintes et par consquent vous laisse moins de possibilits. Par exemple Scrum prescrit l'utilisation d'itrations de dure fixe, Kanban ne le fait pas. Comparons quelques outils sur une chelle normatif vs adaptatif :
RUP est assez normatif avec plus de 30 rles, plus de 20 activits et plus de 70 artefacts ; une norme quantit de choses apprendre. Vous n'tes cependant pas cens tout utiliser, RUP encourage slectionner le sousensemble adapt votre projet. Malheureusement, cela semble tre difficile dans la pratique. Hmmmm aurons-nous besoin de l'artefact
Conclusion de l'Audit des Configurations ? Aurons-nous besoin dun rle de Responsable de contrle du changement ? Pas sr, mais prenons les juste au cas o. Cest une des raisons pour lesquelles les implmentations de RUP sont finalement gnralement trs lourdes par rapport des mthodes agiles telles que Scrum et XP. XP (eXtreme Programming) est plus normatif que Scrum. Il inclut une majorit des rgles de Scrum + un ensemble de pratiques dingnierie bien spcifiques telles que le dveloppement pilot par les tests et la programmation en binme. Scrum est moins normatif que XP puisquil ne recommande aucune pratique dingnierie particulire. Scrum est plus normatif que Kanban cependant, car il impose des choses telles que les itrations et les quipes multidisciplinaires. Une des diffrences principales entre Scrum et RUP est quavec RUP vous vous retrouvez avec beaucoup trop de choses et vous tes cens supprimer ce dont vous navez pas besoin. Avec Scrum, vous partez petit, et vous tes cens ajouter ce qui manque. Kanban laisse tout ouvert. Les seules contraintes sont de Visualiser Votre Workflow et de Limiter Votre TAF. Tout prs du Faire Nimporte Quoi, mais tonnamment puissant.
Ne vous limitez pas lemploi dun seul outil !

Combinez les outils dont vous avez besoin ! Je peux difficilement imaginer une quipe Scrum russir sans inclure la plupart des lments de XP, par exemple. Beaucoup d'quipes Kanban font des scrums quotidiens (une pratique Scrum de runion avec l'quipe debout). Certaines quipes Scrum rdigent leurs lments de backlog sous forme de cas d'utilisation (une pratique RUP) ou limitent la taille de leurs files d'attente (une pratique Kanban). Prenez tout ce qui peut marcher pour vous. Musashi (clbre samoura du XVIIe sicle, connu pour sa technique de combat deux sabres) le disait plus lgamment : Ne vous attachez pas une seule arme ou un seul style de combat en particulier.
QUELS SONT LES LIENS ENTRE SCRUM ET KANBAN ? | 11
Ne vous attachez pas une seule arme ou un seul style de combat en particulier.
- Miyamoto Musashi
Faites cependant attention aux contraintes de chaque outil. Par exemple, si vous utilisez Scrum et dcidez de cesser d'utiliser les sprints de dure fixe (ou tout autre aspect central de Scrum), alors ne dites pas que vous utilisez Scrum. Scrum est assez minimaliste tel qu'il est, alors si vous supprimez quelque chose et que vous appelez encore a du Scrum, le mot sera dnu de sens et crera de la confusion. Appelez-a par exemple inspir de Scrum ou sous-ensemble de Scrum ou encore Scrumayonnaise
3
Scrum impose des rles
Scrum est bas sur 3 rles : le Product Owner (qui donne la vision du produit et dfinit les priorits), l'quipe (qui dveloppe le produit) et le ScrumMaster (qui supprime les obstacles et guide la conduite du processus). Kanban ne prescrit aucun rle. Cela ne signifie pas que vous ne pouvez pas ou ne devez pas avoir un rle de Product Owner dans Kanban ! Cela signifie simplement que vous n'tes pas oblig. Avec Scrum et Kanban vous tes libre d'ajouter tous les rles supplmentaires dont vous avez besoin. Soyez cependant prudent lorsque vous ajoutez des rles. Assurez-vous que les rles supplmentaires apportent effectivement une valeur ajoute et n'entrent pas en conflit avec d'autres lments du processus. tes-vous sr d'avoir besoin d'un rle de Chef de Projet ? Dans un grand projet c'est peut-tre une bonne ide, peut-tre que cela aidera les nombreuses quipes et les Product Owners se synchroniser entre eux. Dans un petit projet, ce rle pourrait tre du gaspillage, ou pire, pourrait conduire une sous-optimisation et du micro-management. L'tat d'esprit gnral dans Scrum et Kanban est maximiser le minimalisme. Donc en cas de doute, commencer avec le minimum. Dans le reste du livre, j'utiliserai le terme Product Owner pour parler de la personne qui fixe les priorits d'une quipe, quel que soit le processus utilis.
13
4
Scrum impose des itrations de dure fixe
Scrum est bas sur des itrations de dure fixe, appeles sprints. Vous pouvez choisir la dure du sprint, mais l'ide gnrale est de conserver la mme dure sur une priode de temps significative et ainsi d'tablir un rythme de travail. Dbut de sprint : un backlog de sprint est cr, c'est--dire que l'quipe extrait plusieurs lments spcifiques du backlog de produit, sur la base des priorits fixes par le Product Owner et la quantit dlments que l'quipe pense pouvoir traiter dans ce sprint. En cours de sprint : l'quipe se concentre sur la ralisation les lments sur lesquels elle s'est engage. Le primtre du sprint est fixe. Fin de sprint : lquipe organise la dmonstration du produit pour les parties prenantes concernes, le produit doit tre potentiellement livrable (c'est--dire test et prt tre dploy). L'quipe fait ensuite une rtrospective pour discuter de son processus et l'amliorer.
Ainsi, un sprint Scrum reprsente un rythme de travail unique de dure fixe et combinant trois activits diffrentes : la planification, l'amlioration des processus, et (idalement) la livraison dune version. Avec Kanban, les itrations de dure fixe ne sont pas imposes. Vous pouvez choisir quel moment faire de la planification, de lamlioration des processus et livrer des versions. Vous pouvez faire ces activits sur une base rgulire (livraison tous les lundis) ou la demande (livraison chaque fois que nous avons quelque chose dutile livrer).
quipe n (rythme unique) 1

Nous pratiquons des itrations comme les sprints de Scrum
15
quipe n (trois rythmes) 2

Nous avons trois rythmes diffrents. Chaque semaine, nous livrons ce qui est prt tre livr. Toutes les deux semaines, nous avons une runion de planification, de mise jour de nos priorits et des plannings de livraison. Toutes les quatre semaines, nous avons une runion (rtrospective) pour amliorer nos processus.
quipe n (rythme essentiellement pilot par les 3 vnements)

Nous dclenchons une runion de planification chaque fois que nous commenons ne plus rien avoir faire. Nous dclenchons la livraison dune version ds que nous disposons dun ensemble de MMF (Minimum Marketable Feature = fonctionnalit minimale apportant de la valeur lutilisateur). Nous dclenchons spontanment un cercle de qualit chaque fois que nous tombons sur un mme problme pour la deuxime fois. Nous faisons aussi une rtrospective plus approfondie toutes les quatre semaines.
5
Kanban limite le TAF chaque tape du workflow, Scrum limite le TAF chaque itration
Avec Scrum, le backlog de sprint montre les tches qui doivent tre excutes au cours de l'itration (= sprint en langage Scrum). Il est gnralement concrtis par des post-it colls sur un mur, que l'on appelle tableau Scrum ou tableau des tches. Alors, quelle est la diffrence entre un tableau Scrum et un tableau Kanban ? Commenons avec un projet trs simple pour comparer les deux:
Dans les deux cas, nous suivons la progression dun groupe dlments travers un workflow. Nous avons dfini trois tats : faire, En cours, et Termin. Vous pouvez dfinir autant dtats que vous voulez certaines quipes ajoutent des tats tels que Intgr, Test, Livr, Noubliez cependant pas le principe maximaliser le minimalisme. Alors, quelle est la diffrence entre ces deux exemples de tableaux ? Ouaip le petit 2 dans la colonne du milieu sur le tableau Kanban. C'est tout. Ce chiffre 2 signifie que il n'y a pas plus de 2 lments dans cette colonne un instant donn. Avec Scrum, il n'existe pas de rgle empchant l'quipe de mettre tous les lments dans la colonne En cours en mme temps ! Toutefois, la limite est implicite puisque le primtre du sprint est fig. Dans ce cas, la limite
17
implicite est de 4, car il y a seulement 4 lments dans l'ensemble du tableau. Donc Scrum limite le TAF indirectement, alors que Kanban limite le TAF directement. La plupart des quipes Scrum finissent par apprendre que c'est une mauvaise ide d'avoir un trop grand nombre dlments en cours, et dveloppent une culture visant terminer les lments commencs avant den dmarrer de nouveaux. Certaines ont mme dcid de limiter explicitement le nombre dlments autoriss dans la colonne En cours et donc - tadaaa ! le tableau Scrum est devenu un tableau Kanban ! Ainsi, Scrum et Kanban limitent tous les deux le TAF, mais de manire diffrente. Les quipes Scrum mesurent habituellement une vlocit le nombre d'lments (ou units correspondantes telles que les story points) raliss par sprint. Une fois que lquipe connat sa vlocit, cela devient sa limite de TAF (ou tout au moins une indication). La plupart du temps, une quipe qui a une vlocit moyenne de 10 ne traitera pas plus de 10 lments (ou story points) au cours dun sprint. Ainsi, avec Scrum, le TAF est limit par unit de temps. Avec Kanban, le TAF est limit par tape du workflow. Dans l'exemple Kanban ci-dessus, 2 lments au plus peuvent tre dans l'tat En cours un moment donn, indpendamment de toute dure. Vous avez besoin de dfinir la limite appliquer chaque tat du workflow, sachant que l'ide gnrale est de limiter le TAF de tous les tats, en commenant le plus tt possible et en terminant le plus tard possible dans le flux de valeur. Donc dans l'exemple ci-dessus, nous devrions ajouter une limite TAF ltat faire (ou tout autre nom que vous donnez votre file d'entre). Une fois que nous avons dfini nos limites de TAF, nous pouvons commencer mesurer et estimer le temps de cycle, c'est--dire le temps qu'il faut un lment, en moyenne, pour traverser tout le tableau. Disposer de temps de cycle prdictibles nous permet de nous engager sur des niveaux de service (en anglais SLA : Service Level Agreement) et de planifier de faon raliste les livraisons. Si la taille des lments varie de faon spectaculaire alors il est possible d'envisager de dfinir les limites de TAF en story points, ou tout autre unit de taille que vous utilisez. Certaines quipes prfrent investir du temps re-dcouper en lments d' peu prs la mme taille ce qui permet d'viter ce type de considration et rduit le temps pass estimer les choses (vous pourriez mme considrer que passer du temps estimer est un gaspillage). Il est plus facile de crer un systme fluide si les lments sont peu prs de la mme taille.
6
Les deux sont empiriques
Imaginez qu'il y ait des boutons sur ces compteurs, et que vous puissiez configurer votre processus en tournant simplement ces boutons. Je veux une haute capacit, un temps de cycle faible et une prdictibilit leve. Je vais donc tourner les boutons sur 10, 1, 10 et 10, respectivement. Ce ne serait pas gant ? Malheureusement, il n'y a pas de boutons de contrle de ce type. Aucun que je connaisse du moins. Faites-moi savoir si vous en trouvez. Au lieu de cela, ce que nous avons, c'est un tas de boutons de contrle indirect.
Scrum et Kanban sont tous les deux empiriques dans le sens o vous exprimentez le processus puis l'adaptez votre environnement de travail. En fait, vous devez l'exprimenter. Ni Scrum ni Kanban ne sont destins fournir toutes les rponses ils vous donnent juste un ensemble de contraintes pour piloter votre propre processus d'amlioration.
19
Scrum explique que vous devez disposer dquipes multidisciplinaires. Donc, qui devrait tre dans quelle quipe ? Si vous ne savez pas, exprimentez-le. Scrum avance que c'est l'quipe qui choisit la quantit de travail raliser dans un sprint. Donc, quelle quantit de travail peut-elle faire ? Si vous ne savez pas, exprimentez-le. Kanban dit que vous devez limiter le TAF. Donc, quelle doit tre cette limite ? Si vous ne savez pas, exprimentez-le.
Comme je l'ai mentionn plus haut, Kanban vous impose moins de contraintes que Scrum. Ce qui signifie que vous devez penser ajuster plus de paramtres, tourner plus de boutons. Cela peut tre un dsavantage ou un avantage, en fonction de votre contexte. Lorsque vous ouvrez linterface de configuration d'un logiciel, prfrez-vous avoir 3 options ou 100 options de paramtrage ? Probablement quelque part entre les deux. Cela dpend de ce que vous souhaitez paramtrer et de la comprhension que vous avez de l'outil. Alors, disons que nous allons rduire la limite de TAF, en se basant sur l'hypothse que cela amliorera notre processus. On observe ensuite comment les choses telles que la capacit, le temps de cycle, la qualit et la prdictibilit voluent. partir des rsultats, nous en tirons des conclusions, puis nous changeons encore d'autres choses, amliorant constamment notre processus. Il y a plusieurs noms pour cela. Kaizen (amlioration continue dans le langage Lean), Inspection & Adaptation (dans le langage Scrum), Processus de Contrle Empirique, ou pourquoi pas La Mthode Scientifique. L'lment le plus critique est le feedback. Changer quelque chose Dcouvrez comment cela s'est pass Tirez-en des leons Changez encore quelque chose. D'une manire gnrale, le feedback doit tre le plus rapide possible, afin que vous puissiez adapter votre processus rapidement. Avec Scrum, le feedback est rythm par le sprint. Il y a plus court, cependant, surtout si vous combinez avec XP (eXtreme Programming) :
LES DEUX SONT EMPIRIQUES | 21
Lorsqu'il est correctement appliqu, le couple Scrum + XP vous offre de nombreuses possibilits de feedback forte valeur ajoute. Le feedback interne - la programmation en binme permet un feedback en quelques secondes. Les anomalies sont dtectes et rsolues dans les secondes qui suivent leur apparition (H, cette variable n'est pas cense valoir 3 ?). Autrement dit, il s'agit d'un feedback pour la question Sommes-nous en train de bien construire le produit ?. La feedback externe - le sprint permet un feedback en quelques semaines. Autrement dit, il s'agit d'un feedback la question Sommes-nous en train de construire le bon produit ?. Qu'en est-il de Kanban alors ? Eh bien, tout d'abord vous pouvez (et probablement vous devriez) utiliser tous les types de feedback mentionns ci-dessus dans votre processus que vous utilisiez Kanban ou non. Ce que Kanban vous offre alors, ce sont des mesures temps rel trs utiles. Temps de cycle moyen. Mis jour chaque fois qu'un lment atteint l'tat Termin (ou le nom que vous donnez votre colonne la plus droite). Les goulets d'tranglement. Un symptme connu apparait lorsque la colonne X est bourr d'items tandis que la colonne X+1 est vide. Recherchez dans ce cas des bulles d'air dans votre tableau.
Ce qui est intressant, concernant les mesures en temps rel, c'est que vous pouvez choisir la dure de votre feedback, base sur la frquence laquelle vous tes prt analyser les mesures et apporter des modifications. Un feedback trop long signifie que votre amlioration du processus se fera lentement. Un feedback trop rapide fait que votre processus n'aura peut tre pas le temps de se stabiliser entre chaque changement, ce qui peut causer du gaspillage.
En fait, vous pouvez galement exprimenter la dure du feedback un peu comme un mta-feedback. Bon, je n'irai pas plus loin sur ce sujet.
Exemple : exprimentez les limites de TAF avec Kanban

Lun des moyens typiques dajustement de Kanban est la limite du TAF. Alors, comment pouvons-nous savoir si l'on a vu juste ? Disons que nous avons une quipe de 4 personnes, et que nous dcidons de commencer par une limite de TAF 1.
Chaque fois que nous commenons travailler sur un lment, nous ne pouvons pas dmarrer un nouvel lment tant que le premier nest pas Termin. Donc, cela va trs vite. Super ! Mais il s'avre que c'est le plus souvent impossible pour 4 personnes de travailler sur le mme lment (dans cet exemple), donc nous aurons des gens inactifs. Si cela ne se produit quune fois ce n'est pas un problme, mais si cela se produit rgulirement, le temps de cycle moyen va augmenter. Fondamentalement, un TAF de 1 signifie que les lments vont rapidement traverser ltat En cours, par contre ils vont rester coincs dans ltat faire plus longtemps que ncessaire, de sorte que le temps de cycle total (= temps de traverse du workflow complet) sera inutilement lev. Alors, si un TAF de 1 est trop faible, quest-ce-que cela donne avec un TAF de 8 ?
Cela fonctionne mieux pendant un temps. Nous constatons que le travail en binme est plus rapide en moyenne. Ainsi avec une quipe de 4 personnes, nous avons habituellement 2 lments dans ltat En cours un moment donn. Un TAF de 8 est juste une limite haute, donc si on le baisse cest mieux ! Imaginez maintenant que nous rencontrions un problme avec le serveur d'intgration, donc nous ne pouvons pas finir de traiter les lments (notre dfinition de Termin comprend l'intgration). Ce genre de problme arrive parfois, non ?
Puisque nous ne pouvons pas terminer les lments D et E, nous commenons travailler sur l'lment F. Nous ne pouvons pas non plus intgrer celui-ci, donc nous intgrons un nouvel lment G. Au bout d'un moment, nous atteignons notre limite Kanban - 8 lments dans En cours.
ce stade, nous ne pouvons plus ajouter d'lments. H, nous ferions mieux de rgler ce problme de serveur d'intgration ! La limite de TAF nous a invit ragir et corriger le goulet d'tranglement au lieu d'empiler du travail non fini. C'est pas mal. Mais si la limite de TAF tait de 4, nous aurions ragi beaucoup plus tt, nous donnant ainsi un meilleur temps de cycle moyen. Donc c'est un quilibre trouver. Nous mesurons le temps de cycle moyen et essayons d'ajuster constamment nos limites de TAF pour optimiser le temps de cycle.
Au bout dun moment, on peut constater que des lments s'entassent dans ltat faire. Peut-tre serait-il temps d'ajouter une limite de TAF cet endroit galement. Dailleurs pourquoi avons-nous besoin d'une colonne faire ? Eh bien, si le client tait toujours disponible pour dire lquipe quoi faire la fois suivante, alors la colonne faire ne serait pas ncessaire. Mais dans notre cas, le client n'est pas toujours disponible, de sorte que la colonne faire donne l'quipe un petit buffer de travail.
Exprimentez ! Ou, comme les Scrumologistes le disent : Inspectez & Adaptez !
7
Scrum autorise peu de changement dans une itration
Disons que notre tableau Scrum ressemble cela : Que se passe-t-il si quelqu'un se prsente et souhaite ajouter llment E au tableau ? Une quipe Scrum rpondra typiquement quelque chose comme Non, dsol, nous nous sommes engags sur le primtre A+B+C+D pour ce sprint. Mais n'hsitez pas ajouter llment E au backlog du produit. Si le Product Owner estime que cest un lment de forte priorit, nous le traiterons dans le sprint suivant. Des sprints de bonne dure donnent l'quipe tout juste assez de temps pour obtenir une version du produit, tout en permettant au Product Owner de grer et mettre rgulirement jour les priorits.
27
Et que dirait l'quipe Kanban ?
Une quipe Kanban rpondrait : N'hsitez pas ajouter llment E dans la colonne faire. Mais la limite est de 2 pour cette colonne, donc vous devrez dans ce cas retirer C ou D. Nous travaillons en ce moment sur A et B et, ds que nous en aurons la capacit, nous dpilerons un lment de la colonne faire. Ainsi, le temps de rponse (le temps qu'il faut pour rpondre un changement de priorit) d'une quipe Kanban correspond au temps pour retrouver de la capacit traiter, suivant le principe gnral de un lment qui sort = un lment qui rentre (pilotage par les limites du TAF). Le temps de rponse d'une quipe Scrum est en moyenne quivalent la moiti dun sprint. Avec Scrum, le Product Owner ne peut pas toucher au tableau Scrum puisque l'quipe s'est engage sur un ensemble spcifique dlments dans le sprint. Avec Kanban, vous dfinissez vos propres rgles de base prcisant qui est autoris changer quoi sur le tableau. Typiquement, on attribue au Product Owner une colonne faire ou Prt ou Backlog ou Propos lextrme gauche o il peut apporter des changements quand il le veut. Ces deux approches ne sont cependant pas exclusives. Une quipe Scrum peut dcider d'autoriser un Product Owner changer les priorits au milieu dun sprint (mme si cest normalement considr comme une exception). Et une quipe Kanban peut dcider d'ajouter des restrictions sur le moment o les priorits peuvent tre changes. Une quipe Kanban peut mme dcider de sengager sur des itrations de dure fixe avec un primtre fix, tout comme en Scrum.
8
Le tableau Scrum est rinitialis chaque dbut d'itration
Un tableau Scrum ressemble gnralement quelque chose de ce genre au cours des diffrentes tapes d'un sprint. Lorsque le sprint est fini, le tableau est effac et tous les lments sont enlevs. Un nouveau sprint est lanc et aprs la runion de planification du sprint suivant, nous avons un nouveau tableau Scrum, avec de nouveaux lments dans la colonne la plus gauche. Techniquement, il s'agit d'un gaspillage mais pour des quipes Scrum exprimentes, cela ne prend gnralement pas trop de temps, et le processus de rinitialisation du tableau peut apporter un sentiment agrable d'accomplissement et de fin officielle. Un peu comme laver la vaisselle aprs le dner - le faire est une preuve, mais c'est agrable une fois que c'est fait. Avec Kanban, le tableau est gnralement persistant : vous navez donc pas besoin de le rinitialiser et de dmarrer avec autre chose.
29
9
Scrum impose des quipes multidisciplinaires
Un tableau Scrum est dtenu par une et une seule quipe Scrum. Une quipe Scrum est multidisciplinaire, elle contient toutes les comptences ncessaires pour mener bien tous les lments du sprint. Un tableau Scrum est gnralement visible de quiconque intress, mais seule lquipe Scrum peut le modifier : c'est l'outil qui lui permet de matriser ses engagements sur le sprint en cours.
Avec Kanban, les quipes multidisciplinaires sont facultatives, et un tableau peut ne pas tre dtenu par une quipe spcifique. Un tableau est li un workflow unique, pas ncessairement une seule quipe.
31
Voici deux exemples :
Exemple 1 : l'ensemble du tableau est gr par une quipe multidisciplinaire. Comme en Scrum. Exemple 2 : le Product Owner dfinit les priorits dans la colonne 1. Une quipe de dveloppeurs multidisciplinaire dveloppe le produit (colonne 2) et le teste (colonne 3). La livraison (colonne 4) est assure par une quipe de spcialistes. Il y a un lger chevauchement de comptences, donc si lquipe de livraison devient un goulet d'tranglement, lun des dveloppeurs va les aider. Donc, avec Kanban, vous devez typiquement tablir certaines rgles de base dfinissant qui utilise le tableau et comment, puis exprimentez les rgles pour optimiser le flux.
10
Les lments du backlog Scrum doivent tenir dans un sprint
Scrum et Kanban sont tous les deux bass sur le dveloppement incrmental, c'est--dire la division du travail. Une quipe Scrum sengagera uniquement sur des lments qu'elle pense pouvoir traiter dans un sprint (en ayant pralablement dfini le Fini). Si un lment est trop gros pour tenir dans un sprint, l'quipe et le Product Owner essayeront de trouver des moyens de diviser cet lment en plusieurs lments plus petits jusqu ce que cela tienne dans un sprint. Si les lments sont tous globalement gros, les sprint seront plus longs (mais gnralement pas plus de 4 semaines).
Les quipes Kanban essayent de minimiser le temps de cycle moyen et de maximiser le flux, ce qui incite indirectement diviser les lments en plus petits lments. Mais il n'y a pas de rgle explicite indiquant que les lments doivent tre suffisamment petits pour correspondre une dure fixe. Dans le mme tableau nous pourrions avoir un lment qui prend 1 mois traiter et un autre lment qui prend 1 jour.
33
11
Scrum impose estimation et vlocit
En Scrum, les quipes sont censes valuer la taille relative (= quantit de travail) de chaque lment sur lequel elles sengagent. En additionnant la taille de chaque lment termin la fin de chaque sprint, nous obtenons la vlocit. La vlocit est une mesure qui sert estimer la capacit : la quantit dlments que nous pouvons livrer par sprint. Voici un exemple dquipe avec une vlocit moyenne de 8.
Sachant que la vlocit moyenne est de 8, nous pouvons alors prvoir une capacit de 8 pour les lments que nous pourrons traiter dans les prochains sprints, et donc planifier de faon raliste les livraisons. En Kanban, lestimation nest pas impose. Si vous souhaitez vous engager vous devez dcider de la manire de prvoir les choses. Certaines quipes choisissent de faire des estimations et de mesurer la vlocit, tout comme en Scrum. D'autres quipes choisissent de ne pas faire d'estimation, mais essayent de diviser les choses faire en lments d peu prs de la mme taille : ils peuvent alors mesurer la vlocit en terme de nombre dlments traits par unit de temps (par exemple, nombre de fonctionnalits par semaine). Certaines quipes groupent les lments pour obtenir un ensemble de MMF (Minimal Marketable Feature), mesurent le temps de cycle moyen par MMF, et l'utilisent pour tablir des SLA (Service Level Agreements). Exemple de SLA : quand nous nous engageons sur une MMF, elle sera toujours livre dans les 15 jours.
35
Il y a toutes sortes de techniques intressantes pour la planification des livraisons et la gestion des engagements dans le style Kanban, mais aucune technique spcifique nest prescrite ; alors allez-y, essayez diffrentes techniques jusqu' ce que vous en trouviez une qui convient votre contexte. Vous verrez probablement merger de bonnes pratiques au fil du temps.
12
Les deux permettent de travailler sur plusieurs produits simultanment
En Scrum, le Backlog de produit est un nom plutt regrettable, car il implique que tous les lments doivent concerner le mme produit. Voici deux produits, vert et jaune, chacun avec son propre backlog de produit et sa propre quipe :
Que faire si vous n'avez qu'une seule quipe ? Eh bien, envisagez le Backlog de produit plus comme un Backlog d'quipe. Il liste les priorits pour les prochains sprints d'une quipe (ou un ensemble d'quipes). Donc, si cette quipe maintient plusieurs produits, fusionnez les deux produits dans une seule liste. Cela nous oblige tablir des priorits entre les deux produits, ce qui est utile dans certains cas. Il existe plusieurs faons de le faire dans la pratique : Une stratgie serait d'avoir l'quipe ddie un seul produit par sprint :
37
Une autre stratgie serait que l'quipe travaille sur les fonctionnalits des deux produits pendant chaque sprint :
C'est la mme chose en Kanban. Nous pouvons avoir plusieurs produits circulant travers le mme tableau. On pourrait les distinguer l'aide de cartes de diffrentes couleurs :
ou en ajoutant des lignes de nage :
13
Les deux sont Lean et Agile
Je ne vais pas reprendre ici la Pense Lean ni le Manifeste Agile, mais d'une manire gnrale, Scrum et Kanban reposent tous les deux sur les mmes valeurs et principes. Par exemple : Scrum et Kanban sont orients Juste temps (JIT = Just In Time) qui est un principe Lean. Cela signifie que l'quipe choisit le moment et la quantit de travail sur laquelle s'engager, et tire le travail quand elle est prte, plutt que de voir ce travail pouss de l'extrieur. Exactement comme une imprimante qui tire la page suivante uniquement au moment o elle est prte l'imprimer (mme s'il n'y a qu'un petit stock limit de papier qu'elle peut utiliser). Scrum et Kanban sont bass sur une optimisation continue et empirique des processus, qui correspond au principe Kaizen du Lean. Scrum et Kanban mettent l'accent sur la ractivit aux changements plutt quau suivi dun planning (mme si Kanban donne en gnral une rponse plus rapide que Scrum), l'une des quatre valeurs du Manifeste Agile.
et plus encore. D'un autre ct, Scrum nest pas aussi Lean que cela, car il prvoit de grouper la ralisation des lments dans des itrations dure fixe. Mais cela dpend de la dure de votre sprint et de ce que vous comparez. Par rapport un processus traditionnel o l'on intgre et livre 2 4 fois par an, une quipe Scrum dveloppant un produit potentiellement livrable toutes les 2 semaines est trs Lean. Si vous continuez avec des sprints de plus en plus courts, vous vous rapprochez de Kanban. Lorsque vous commencez parler de dure infrieure 1 semaine, vous pouvez envisager de laisser entirement tomber le principe de litration dure fixe.
39
Je l'ai dit prcdemment et je le dis encore. Continuez exprimenter jusqu' ce que vous trouviez ce qui fonctionne pour vous ! Ensuite, continuez encore exprimenter
14
Des diffrences mineures
Voici quelques diffrences qui semblent moins importantes que celles mentionnes prcdemment. Il vaut mieux en prendre conscience tout de mme.
Scrum recommande un backlog produit prioris

En Scrum, la gestion des priorits est toujours faite par le tri du backlog de produit et les changements de priorits prennent effet dans le sprint suivant (pas dans le sprint en cours). En Kanban, vous pouvez choisir n'importe quel mcanisme de priorisation (ou mme aucun), et les changements prennent effet ds que la capacit est disponible (plutt qu un moment fix). Il peut y avoir un backlog de produit ou non et il peut tre prioris ou non. Dans la pratique, cela fait peu de diffrence. Sur un tableau Kanban, la colonne la plus gauche rpond en gnral aux mmes objectifs que le backlog de produit de Scrum. La liste peut-tre ou non trie par ordre de priorit et l'quipe doit dfinir une rgle de dcision pour savoir quels lments traiter/tirer en premier. Exemples de rgles de dcision : Dpiler toujours le premier lment. Prendre toujours l'lment le plus ancien (chaque lment est horodat). Prendre n'importe quel lment. Passer environ 20% pour des lments relatifs la maintenance et 80% pour des nouvelles fonctionnalits. Rpartir la capacit de lquipe de faon peu prs gale entre les produits A et B. Prendre toujours les lments en rouge d'abord, s'il y en a.
41
En Scrum, un backlog de produit peut aussi tre utilis selon un mode Kanban. Nous pouvons limiter sa taille et crer des rgles de dcision pour dire comment le prioriser.
Scrum impose des points quotidiens

Une quipe Scrum tient une courte runion (15 minutes au plus), appele scrum, chaque jour la mme heure et au mme endroit. Le but de cette runion est de faire un point sur ce qui a t fait, de planifier la journe venir et d'identifier tout problme significatif. On l'appelle aussi parfois standup puisqu'elle se tient habituellement debout (pour qu'elle reste courte et qu'elle maintienne un haut niveau de participation). Kanban ne prescrit pas les scrums quotidiens, mme si beaucoup dquipes Kanban semblent tout de mme les faire. Cest une excellente technique quel que soit le processus utilis. En Scrum le format de la runion est ax sur la personne - chaque personne fait son rapport l'une aprs l'autre. De nombreuses quipes Kanban utilisent un format plus orient tableau, en se concentrant sur les goulets d'tranglement et d'autres problmes visibles. Cette approche est plus souple. Si vous avez 4 quipes partageant le mme tableau et menant leurs runions quotidiennes ensemble, il n'est pas ncessaire d'couter tout le monde parler tant que l'on se concentre sur les goulets d'tranglement du tableau.
Scrum recommande des burndown charts

Un burndown chart de sprint montre, sur une base quotidienne, le travail restant raliser pour le sprint courant. L'unit de l'axe Y est celle utilise pour les tches du sprint. Gnralement des heures ou des jours (si l'quipe divise les lments du backlog en tches) ou en story points (si l'quipe ne divise pas les lments). Il existe de nombreuses variantes. En Scrum, les burndown charts constituent lun des principaux outils pour le suivi de la progression d'un sprint.
DES DIFFRENCES MINEURES | 43
Certaines quipes utilisent galement le burndown chart de release, qui suit le mme format mais au niveau de la release : il montre gnralement combien de story points restent faire dans le backlog de produit aprs chaque sprint. L'objectif principal est de se rendre compte facilement et le plus tt possible si nous sommes en retard ou en avance, de sorte que nous pouvons nous adapter. En Kanban, l'emploi des burndown charts n'est pas impos. En fait, aucun type particulier de graphique n'est impos. Mais ils sont bien sr autoriss (y compris les burndowns). Voici un exemple de diagramme de flux cumul. Ce type de diagramme illustre parfaitement la pente de votre flux et la manire dont le TAF impacte votre temps de cycle.
Voici comment cela fonctionne. Chaque jour, faites le total du nombre d'lments dans chaque colonne du tableau Kanban et empilez-les sur l'axe Y. Donc, au 4me jour, il y avait 9 lments dans le tableau. En partant de la colonne la plus droite, il y avait 1 lment en Production, 1 lment en Test, 2 lments en Dv et 5 lments dans le Backlog. En traant, et reliant, ces points tous les jours nous obtenons un beau diagramme comme celui ci-dessus. Les flches verticales et horizontales illustrent la relation entre le TAF et le temps de cycle. La flche horizontale nous montre que les lments ajouts au backlog au 4me jour ont pris en moyenne 6 jours pour atteindre la production. Environ la moiti de ce temps est pass en Test. Nous pouvons voir que si l'on arrivait limiter le TAF en Test et en Backlog, cela permettrait de rduire significativement le temps de cycle.
La pente de la zone bleu fonc nous montre la vlocit (c'est--dire le nombre d'lments dploys par jour). Au fil du temps on peut voir comment une vlocit suprieure peut rduire le temps de cycle, alors qu'un TAF suprieur accrot le temps de cycle. La plupart des organisations souhaitent que les choses aillent plus vite (= rduire le temps de cycle). Malheureusement, beaucoup tombent dans le pige en supposant que cela signifie avoir plus de personnes ou faire des heures supplmentaires. Habituellement, la faon la plus efficace pour que les choses aillent plus rapidement est de lisser le flux et de limiter le travail la capacit disponible, et non en ajoutant des personnes ou en les faisant travailler plus dur. Ce type de diagramme montre pourquoi, et augmente ainsi la probabilit que l'quipe et le management collaborent efficacement. Cela devient encore plus vident si l'on matrialise les files d'attente entre les tats du workflow (par exemple en attente de Test) par rapport aux files de travail (par exemple en cours de Test). Nous voulons absolument minimiser le nombre d'lments sjournant dans les files, et un diagramme de flux cumul nous aide trouver les pistes appropries pour cela.
15
Tableau Scrum vs Tableau Kanban - un exemple moins trivial
En Scrum, le backlog de sprint ne reprsente qu'une partie de la vue complte la partie qui montre ce que l'quipe est en train de faire au cours du sprint. L'autre partie est le backlog de produit la liste des choses que le Product Owner veut avoir dans les prochains sprints. Le Product Owner peut consulter mais ne peut pas toucher au backlog de sprint. Il peut changer le backlog de produit autant de fois quil veut, mais les modifications ne prennent effet (cest--dire affectent le travail en cours) que dans les sprints suivants.
Lorsque le sprint est termin, l'quipe fournit une version potentiellement livrable au Product Owner. Ainsi, l'quipe termine le sprint, fait une revue de sprint, et montre firement les fonctionnalits A, B, C et D au Product Owner. Le Product Owner peut alors dcider s'il convient ou non de livrer cette version du produit. La dernire partie la livraison relle du produit nest habituellement pas incluse dans le sprint, et n'est donc pas visible dans le backlog du sprint. Dans ce scnario, un tableau Kanban pourrait plutt ressembler quelque chose de ce genre :
45
L'ensemble du workflow est reprsent sur le mme tableau : nous ne sommes pas simplement en train de regarder ce quune quipe Scrum est en train de faire dans une itration. Dans l'exemple ci-dessus, la colonne Backlog est juste une liste de souhaits, sans ordre particulier. La colonne Selected contient les lments de priorit haute, avec une limite Kanban 2. Il peut donc y avoir seulement 2 lments de priorit haute un moment donn. Lorsque l'quipe est prte pour commencer travailler sur un nouvel lment, elle dpile llment de plus haute priorit dans la colonne Selected. Le Product Owner peut apporter des modifications aux colonnes Backlog et Selected tout moment, mais pas aux autres colonnes. La colonne Dv (scinde en deux sous-colonnes) montre ce qui est actuellement en cours de dveloppement, avec une limite Kanban 3. En termes rseau, la limite Kanban correspond la bande passante et le temps de cycle correspond au ping (ou temps de rponse). Pourquoi avons-nous scind la colonne Dv en deux sous-colonnes En cours et Fait ? C'est pour donner lquipe de production la visibilit sur les lments qu'ils peuvent mettre en production. La limite Dv 3 est partage entre les deux sous-colonnes. Pourquoi ? Disons qu'il y a 2 lments dans la colonne Fait :
RSUM SCRUM VS KANBAN | 47
Cela signifie qu'il ne peut y avoir quun seul lment dans la colonne En cours. Cela implique qu'il y aura une capacit excdentaire, des dveloppeurs qui pourraient commencer un nouvel lment, mais qui ny sont pas autoriss cause de la limite Kanban. Cela les incite donc fortement aider livrer des choses en production, afin de vider la colonne Fait et maximiser le flux. Cet effet est positif et progressif plus il y a de choses dans la colonne Fait, moins il peut y avoir de choses dans la colonne En cours ce qui permet l'quipe de se concentrer sur de bonnes choses.
Flux une pice

Un flux une pice est une sorte de scnario pour un flux parfait, o un lment traverse le tableau sans jamais tre coinc dans une file d'attente. Cela signifie qu' chaque instant il y a une personne travaillant sur cet lment. Voici quoi pourrait ressembler le tableau dans ce cas :
B est en cours d'laboration, A est sur le point d'tre mis en production. Chaque fois que l'quipe est prte pour traiter l'lment suivant, elle demande au Product Owner ce qui est le plus important et obtient une rponse immdiate. Si ce scnario idal se maintient, nous pouvons nous dbarrasser des deux files d'attente Backlog et Slectionn et rellement obtenir un temps de cycle trs court ! Cory Ladas le dit lgamment : Le processus de planification idal devrait toujours fournir l'quipe de dveloppement la meilleure chose faire le coup suivant, ni plus ni moins. Les limites de TAF sont l pour matriser les problmes, donc si les choses sont fluides les limites de TAF ne sont pas vraiment utiles.
Un jour au pays de Kanban
Est-ce que le tableau Kanban doit ressembler a ?

Non, le tableau ci-dessus tait juste un exemple ! La seule chose que Kanban impose est que le workflow soit visuel et que le TAF soit limit. Le but est de crer un bon dbit travers le systme et de rduire le temps de cycle. Vous devez donc rgulirement soulever des questions telles que : Quelles colonnes devons nous avoir ? Chaque colonne reprsente un tat du workflow, ou une file d'attente (buffer) entre deux tats du workflow. Commencez simple et ajoutez des colonnes seulement si ncessaire. Quelles devraient tre les limites de Kanban ? Lorsque la limite de Kanban pour votre colonne a t atteinte et que vous n'avez rien faire, commencez chercher un goulet d'tranglement en aval (c'est--dire des lments s'empilant la droite du tableau) et aidez traiter ce goulet d'tranglement. S'il n'y a pas de goulet d'tranglement, c'est une indication que la limite Kanban pourrait tre plus faible, puisque la raison d'avoir une limite est de rduire le risque de gnrer des goulets d'tranglement en aval. Si vous remarquez que de nombreux lments stagnent pendant une longue priode sans tre traits, c'est une indication que la limite Kanban pourrait tre trop leve. Limite Kanban trop faible les gens sont inoccups Mauvaise productivit Limite Kanban trop leve tches non traites Mauvais temps de cycle
Les limites Kanban sont-elles strictes ? Certaines quipes les apprhendent comme des rgles strictes ( savoir que l'quipe ne peut pas dpasser une limite), certaines quipes les apprhendent comme des lignes directrices ou des motifs de discussion ( savoir que briser une limite Kanban est autoris, mais cela doit tre une dcision volontaire avec une raison valable). Encore une fois, c'est vous qui choisissez. Je vous ai dit que Kanban n'tait pas trs normatif, n'est-ce pas ?
16
Rsum Scrum vs Kanban
Ressemblances
Les deux sont Lean et Agile. Les deux utilisent le Juste temps. Les deux limitent le TAF. Les deux utilisent la transparence pour piloter l'amlioration des processus. Les deux se concentrent sur la livraison rapide et frquente du produit. Les deux sont fonds sur l'auto-organisation des quipes. Les deux requirent de diviser le travail en lments. Dans les deux cas, le planning de release est continuellement ajust et bas sur des donnes empiriques (vlocit / temps de cycle).
53
Diffrences
Scrum Itrations dure fixe. Kanban Itrations dure fixe optionnelles. Possibilit davoir des rythmes diffrents pour le planning, les versions et lamlioration des processus. Peut-tre pilot par les vnements et non dure fixe. Engagement optionnel.
Lquipe sengage sur une quantit spcifique de travail pour une itration. Utilisation de la Vlocit en tant que mesure par dfaut pour le planning et l'amlioration des processus. quipes multidisciplinaires imposes. Les lments du backlog doivent tre dcoups afin de pouvoir tre traits en 1 sprint. Burndown chart impos. Limitation indirecte du TAF (par sprint). Estimation impose. Impossible dajouter un item en cours ditration. Un backlog de sprint est trait par une seule quipe.
Utilisation du Temps de cycle en tant que mesure par dfaut pour le planning et l'amlioration des processus. quipes multidisciplinaires optionnelles. quipes de spcialistes autorises. Aucune taille impose.
Aucun diagramme particulier impos. Limitation directe du TAF (par tape du workflow). Estimation optionnelle. Possibilit dajouter de nouveaux items chaque fois que la capacit le permet. Un tableau Kanban peut-tre partag par plusieurs quipes ou individus.
Scrum 3 rles imposs (PO/SM/quipe). Le tableau Scrum est rinitialis chaque dbut de sprint. Un backlog de produit prioris impos.
Kanban Aucun rle impos. Un tableau Kanban est persistant. Priorisation optionnelle.
Voil. On y est. Vous connaissez maintenant les diffrences. Mais ce n'est pas encore termin, la meilleure partie va commencer ! Chaussez vos bottes, il est temps de descendre au fond de la mine avec Mattias et de voir quoi cela ressemble en pratique !
2me Partie - tude de cas

Kanban dans la vraie vie
Je vais raconter ici la faon dont nous avons appris nous amliorer grce l'utilisation de Kanban. Lorsque nous avons commenc, nous n'avions pas beaucoup d'informations et Dr Google, pour une fois, nous a laiss les mains vides. Aujourd'hui, Kanban volue avec succs et il existe une base mergente de connaissances. Je vous recommande fortement de jeter un coup d'il sur le travail de David Anderson, par exemple sur les classes de service. C'est ma premire (et ma dernire) annonce (promis !). Quelle que soit la solution que vous dployez, assurez-vous qu'elle rponde vos problmes spcifiques. Voil, c'est fait. Allons-y. Commenons notre histoire. /Mattias Skarin
57
17
Le mtier d'exploitant
Si vous avez dj t d'astreinte 24h/24 et 7j/7, vous avez une bonne ide de ce que l'on ressent lorsqu'il faut grer un environnement de production. On attend de vous d'tre capable de rgler un problme au milieu de la nuit, que vous soyez ou non son origine. Personne ne sait quoi faire, c'est pourquoi on vous appelle. C'est un sacr dfi puisque ce n'est pas vous qui avez construit le matriel, les drivers, le systme d'exploitation ou les logiciels spcifiques. Vos possibilits se limitent le plus souvent confiner le problme en limitant ses impacts et conserver les traces ncessaires, en esprant que la personne responsable du problme dont vous avez t le tmoin soit capable de le reproduire et de le rsoudre. La ractivit et la capacit rsoudre les problmes sont fondamentales, ceci avec rapidit et prcision.
59
18
Pourquoi diable changer ?
En 2008, l'un de nos clients, une socit scandinave de dveloppement de jeux, est pass par toute une srie d'amliorations de ses processus. L'une de ces amliorations concernait le dploiement de Scrum au sein de l'organisation et l'limination progressive des problmes freinant l'quipe dans la livraison du logiciel. Lorsque la livraison du logiciel a commenc devenir plus fluide et que la performance s'est accrue, la pression a commenc monter en aval du ct du ple exploitation. Auparavant, les quipes d'exploitation ne se sentaient pas vraiment concernes, aujourd'hui elles sont de plus en plus impliques et jouent un rle actif dans le processus de dveloppement.
Figure 1. L'organisation du ple exploitation comprenait trois quipes : des administrateurs de base de donnes (DBAs), des administrateurs systmes et un support niveau 2. Se contenter d'aider les quipes de dveloppement n'tait pas suffisant. Si nous avions continu nous concentrer uniquement sur les quipes de dveloppement, cela aurait pu provoquer des retards dans l'amlioration, indispensable, de l'infrastructure, mene par les quipes d'exploitation. L'amlioration tait donc ncessaire dans les deux domaines. En outre, les progrs raliss dans les quipes de dveloppement faisaient que les managers taient de plus en plus sollicits pour aider analyser les (nouvelles) ides et en donner leur feedback. Ils avaient donc de moins en
61
moins de temps pour la priorisation des tches au fil de l'eau et la rsolution des problmes. L'quipe de management a donc ralis qu'elle devait ragir avant que la situation devienne compltement ingrable.
19
19. Par o commencer ?
Un bon point de dpart a t de questionner les quipes de dveloppement, qui sont les clients du service exploitation.
Vision de l'exploitation par les dveloppeurs

Je leur ai pos la question suivante : Quelles sont les trois premires choses qui vous viennent l'esprit quand vous pensez l'exploitation ?. Les rponses les plus frquentes sont : Connaissance variable Trs comptent quand il s'agit de l'infrastructure Ils veulent aider, mais en ralit il est difficile d'obtenir de l'aide Les projets prennent trop de temps Leur workflow est pourri Qu'est-ce qu'ils font ? Beaucoup trop de mails pour que les choses se fassent Difficile contacter
Voil en bref la vision que les dveloppeurs avaient de l'exploitation. Maintenant, comparons a la vision que l'exploitation avait du dveloppement
Vision du dveloppement par l'exploitation
63
Pourquoi n'utilisez-vous pas les avantages de la plate-forme existante ? Faites des versions beaucoup plus simples livrer ! Nous ne comprenons pas que vous produisiez du logiciel de mauvaise qualit ! Ils doivent changer a t le leitmotiv utilis d'un ct comme de l'autre. Il est vident que l'tat d'esprit devait changer pour essayer de rgler les problmes communs. Un point positif : Trs comptent quand il s'agit de l'infrastructure (qui indique une confiance dans les comptences de base de l'exploitant) m'a laiss penser que l'on pouvait dpasser la mentalit nous contre eux si l'on crait les bonnes conditions de travail. liminer la surcharge de travail et se concentrer sur la qualit devenait maintenant un scnario viable.
20
Pour s'y mettre
Il fallait donc s'y mettre, mais par o commencer ? La seule chose que nous savions avec certitude tait que notre point d'arrive serait totalement diffrent de notre point de dpart. Mon parcours est celui d'un dveloppeur donc j'en savais trs peu sur le mtier d'exploitant. Mon propos n'tait pas de remettre tout en cause et de commencer tout changer. Je devais adopter une approche moins conflictuelle qui nous permettrait d'identifier les choses pertinentes, de laisser de ct les choses sans importance et d'apprendre facilement. Les approches possibles taient les suivantes : 1. Scrum, qui fonctionne bien avec les quipes de dveloppement. 2. Kanban, nouveau et non mis en pratique, mais en bonne adquation avec les principes Lean qui nous faisaient dfaut. Lors des discussions avec les managers, Kanban et les principes Lean se sont avrs bien rpondre aux problmatiques que nous essayions de traiter. De leur point de vue, les sprints ne semblaient pas bien adapts, car ils avaient l'habitude de redfinir les priorits quotidiennement. Kanban a donc t logiquement le point de dpart, mme si c'tait un nouveau truc pour nous tous.
65
21
Mise en ordre de marche des quipes
Comment mettre les quipes en ordre de bataille? Il n'y avait pas de manuel pour cela. S'y prendre mal ds le dpart constituait un gros risque. Mis part le risque de se planter sur les axes d'amlioration, les personnes de la plate-forme d'exploitation qui nous avions affaire taient hautement spcialises et qualifies, difficiles remplacer. Se passer d'eux tait une trs mauvaise ide. Devions-nous simplement nous lancer ? ET assumer les consquences au fur et mesure ? Ou mener un atelier avant ? Il tait vident pour nous de dmarrer par l'atelier, mais comment ? C'tait un dfi d'obtenir la participation de toute l'quipe d'exploitation un atelier (qui rpond si quelqu'un appelle ?). Finalement, nous avons dcid de faire un atelier d'une demi-journe, simple et bas sur des mises en situation.
L'atelier
Un des avantages de l'atelier tait de faire remonter trs tt nos problmes la surface. C'tait galement l'occasion de proposer en toute confiance une sance de travail, pendant laquelle les implications pourraient tre discutes directement avec les membres de l'quipe. Soyons clair : tout le monde n'tait pas vraiment enthousiaste l'ide de modifier les mthodes de travail actuelles mais la plupart des membres de l'quipe taient prts essayer. Nous avons donc ralis un atelier dmontrant les principes les plus importants de Kanban avec une simulation petite chelle.
67
Apprendre les principes de base Limiter le travail selon la capacit disponible. Taille d'un lot vs temps de cycle.
Dmo Kanban 3 types de travail : o o o rpondre aux demandes, construire une voiture en lego, concevoir et construire une maison.
Travail en cours vs dbit du flux de travail Thorie des contraintes
3 itrations : o Mesurer la vlocit par type de travail, o Exprimenter et ajuster le TAF. Faire le bilan.
la fin de l'atelier, nous avons fait un vote main leve (sur le principe du Fist of Five2) pour vrifier si les quipes taient prtes se lancer dans la vie relle. Aucune objection n'a alors t souleve et nous avons donc obtenu le feu vert pour aller de l'avant.
NdT : site intressant dtaillant le principe du Fist of Five : http://leadinganswers.typepad.com/leading_answers/2007/02/team_decisi on_m.html
22
Impliquer les parties prenantes
Il tait probable que les parties prenantes seraient galement impactes par la mise en uvre de la dmarche Kanban. Mme si les changements qui allaient avoir lieu taient faits pour amliorer les choses (l'quipe allait bientt rpondre non pour un travail qui ne pourrait tre termin, axer son travail autour de la qualit et de la suppression des choses de trs faible priorit dans le backlog), il tait prfrable d'en discuter avant avec eux. Les parties prenantes les plus proches taient le support de niveau 1 et les managers du dpartement. Ces derniers ayant particip l'atelier, ils taient dj d'accord pour aller de l'avant. Mme chose pour les quipes de dveloppement (qui taient plus ou moins en attente que les choses s'amliorent d'une manire ou d'une autre). Mais, pour une quipe, celle du support, les choses taient diffrentes. Leur problme le plus important tait qu'ils taient surchargs de travail. Ils assuraient notamment le support client et taient soumis des engagements pour rpondre tout type de demande. Ces points allaient probablement changer avec la mise en place de Kanban et l'application des limitations de TAF. Nous sommes donc alls voir les principales parties prenantes pour prsenter notre dmarche, les bnfices attendus et les impacts possibles. mon grand soulagement, nos ides ont t gnralement bien reues, avec parfois une remarque du type super, nous allons enfin pouvoir enterrer ces problmes.
69
23
Construire le premier tableau
Une bonne faon de commencer la construction d'un tableau Kanban est de cartographier les flux de valeur. Il s'agit de visualiser la chane de valeur et de fournir un aperu de l'tat d'avancement des travaux, de l'coulement du flux et du temps pass dans le systme (temps de cycle).
Mais nous avons commenc par quelque chose de beaucoup plus simple ; nous avons dessin avec le manager un simple tableau Kanban sur le papier. Nous l'avons rvis plusieurs fois de suite puis nous avons dmarr avec. Les questions que nous nous sommes poses dans cette phase taient les suivantes : Quels types de travaux ralisons-nous ? Qui les gre ? Devons-nous partager des responsabilits entre les diffrents types de travail ? Comment pouvons-nous faire face une responsabilit partage parmi des comptences spcialises ?
tant donn que les diffrents types de travaux ont des exigences de niveaux de services diffrents (SLAs), il a sembl naturel de laisser chaque quipe le soin de concevoir son propre tableau. Les quipes ont donc labor les colonnes et les lignes elles-mmes.
71
La grande dcision suivante fut de savoir si l'on passait par un partage de responsabilits entre diffrents types de travaux. Devons-nous laisser une partie de l'quipe ddie la rponse aux questions directes (ractivit) et laisser le reste de l'quipe se concentrer sur les projets (pro-activit)? Nous avons d'abord essay le partage des responsabilits. Une des principales raisons tait que nous avions identifi que l'auto-organisation et l'augmentation du nombre de personnes dans les quipes taient indispensables pour soutenir la croissance. L'inconvnient avec ce choix tait que chacun pouvait subir d'ventuelles perturbations, mais cela a t la meilleure solution que nous avons pu trouver au dpart. Une petite remarque : lorsque nous avons men l'atelier, les quipes s'taient dj organises d'ellesmmes pour traiter cette problmatique. Une personne grait les demandes immdiates et le reste de l'quipe traitait les problmes de fond.
Le premier modle Kanban

Vous trouverez ci-dessous le modle de base que nous avons utilis comme Kanban. Notez que l'quipe a dcid de grer l'tat des lments du tableau du bas vers le haut (comme des bulles qui remontent la surface de l'eau) plutt que d'utiliser le modle typique o les lments circulent de gauche droite.
Figure 1. Ceci est notre premier modle de Kanban. Les priorits vont de gauche droite et le flux des items du bas vers le haut. Le TAF est comptabilis par le nombre total de tches prsentes dans la ligne Work in progress3 (entoure en rouge). Ce modle a t influenc par les diffrents retours d'exprience de Linda Cook.
NdT : travail en cours
CONSTRUIRE LE PREMIER TABLEAU | 73
Figure 3. Premier tableau Kanban pour l'quipe administration systme.
Lignes utilises
tat du workflow Backlog Prt pour le TAF Notre dfinition Stories dclares ncessaires par le manager Les stories sont estimes et dcoupes en tches d'une taille maximale de 8 heures La ligne disposant d'une limite de TAF. Nous avons dmarr en fixant la limite 2 x la taille de l'quipe - 1 (-1 pour la charge de collaboration). Donc une quipe de 4 personnes a une limite de TAF de 7. Excutable par les utilisateurs.
Travail en cours
Fini
Colonnes utilises
Type de travail Livraison Notre dfinition Assistance des quipes de dveloppement pour les activits de livraison du logiciel. Petites demandes des autres quipes. Travail non anticip ncessitant d'tre fait mais sans affectation claire. Par exemple, des amliorations mineures de l'infrastructure. Projet d'exploitation plus consquent, par exemple, changer le matriel d'un environnement de recette. Un autre projet plus consquent.
Support Non planifi
Projet A
Projet B
Les tableaux Kanban n'taient pas tous similaires. Tous ont dmarr avec un modle simple et se sont adapts au fur et mesure.
24
Fixer une limite de TAF la premire fois
Notre premire limite pour les travaux finir (TAF) tait assez gnreuse. Nous avons pens qu'en visualisant le flux nous verrions de faon concrte ce qui se passait et qu'il tait peu probable que nous soyons en mesure de deviner la meilleure limite ds le dpart. Au fur et mesure, nous avons ajust les limites de TAF chaque fois que nous avons trouv de bonnes raisons de le faire (tout ce que nous avions faire tait de l'indiquer sur le tableau). La premire limite de TAF que nous avons utilise tait 2n-1 (n = nombre de membres de l'quipe, -1 pour encourager la coopration). Pourquoi ? C'est simple, parce que nous n'avions pas de meilleure ide . En outre, cette valeur nous semblait incontestable. La formule fournissait une explication simple et logique toute personne tentant de donner du travail en surcharge l'quipe : donc tant donn que chaque membre de l'quipe peut travailler sur au plus deux choses la fois, une chose en cours et une chose en attente, pourquoi voudriez-vous qu'ils en prennent plus ? Avec le recul, n'importe quelle limite confortable aurait fait l'affaire au dmarrage. En observant le tableau Kanban, il est facile de faire ressortir les bonnes limites au fur et mesure.
75
Figure 4. Comment nous avons appliqu la limite de travail en cours pour les DBA et l'quipe d'administration systme : une limite partage pour tous les types de travail. Nous avons observ qu'il tait inutile de dfinir la limite de TAF en story points. C'tait tout simplement trop difficile d'en garder la trace. La seule limite assez facile suivre tait de simplement comptabiliser le nombre d'items (= tches parallles). Pour l'quipe support, nous avons dfini un TAF par colonne (donc par type de travail) parce que nous avions besoin d'une ractivit plus grande si la limite venait tre dpasse.
25
Respecter la limite de TAF
Respecter une limite de TAF semble facile en thorie, mais trs difficile dans la pratique. Cela signifie pouvoir dire non un certain stade. Nous avons essay diffrentes approches pour traiter ce problme.
En discuter devant le tableau

Lorsqu'une limite n'tait pas respecte, nous pouvions amener les parties prenantes devant le tableau et leur demander ce qu'ils souhaitaient terminer parmi les travaux en cours. Au dbut, le cas le plus frquent de non respect de la limite tait juste l'inexprience. Dans certains cas, nous sommes tombs sur des visions diffrentes des priorisations, un cas typique tant un spcialiste de l'quipe travaillant dans un domaine spcifique. Ce sont les seules fois o nous avons connu des confrontations, la plupart du temps les problmes ont t identifis et discuts devant le tableau.
Crer une colonne Dbordement

Comme dire non tait trop agressif et retirer des items du tableau tait trop compliqu, nous dplacions les items de priorit plus faible vers une colonne dbordement sur le tableau chaque fois que les limites de TAF taient dpasses. Deux rgles s'appliquaient dans ce cas : 1. Les items concerns n'ont pas t oublis; si nous avons du temps, nous les traiterons. 2. Quand nous les supprimons, nous le faisons savoir. Tout juste deux semaines aprs, il tait vident que les items en dbordement ne seraient jamais traits ; donc, avec l'appui du manager de l'quipe, nous les avons finalement supprims.
77
Figure 5. Une esquisse du tableau Kanban pour l'quipe support ; la colonne Dbordement est l'extrme droite.
26
Quelles tches afficher sur le tableau ?
Nous avons dcid trs tt de ne pas ajouter tout le travail effectu par l'quipe sur le tableau. Inclure des tches comme rpondre au tlphone ou prendre un caf transformerait le modle Kanban en un monstre administratif. Nous tions l pour rsoudre des problmes et non pour en crer . Nous avons donc dcid d'afficher sur le tableau uniquement les tches de taille > 1 heure, tout ce qui tait infrieur tant considr comme du bruit. La limite de 1h a effectivement assez bien fonctionn et a t l'une des rares choses qui soit demeure inchange. (Nous avons d revoir nos prvisions quant l'impact qu'avait rellement le bruit de fond, plus de dtails ultrieurement sur ce sujet.)
Figure 6. Nous avons dmarr en supposant que la capacit totale tait principalement consomme par deux types de travaux : dans une grosse proportion les projets, dans une moindre mesure le support. Estimer et suivre la vlocit sur les projets nous a donn une indication de la date de livraison lorsque c'tait ncessaire. Le bruit (demandes de support < 1h, runions, prendre un caf, aider les collgues) tait cens tre inclus dans la marge.
79
27
Comment estimer ?
C'est un sujet toujours ouvert, et il y a certainement plus d'une rponse : Estimer rgulirement. Estimer quand le besoin s'en fait sentir. Faire les estimations en jours idaux ou en story points. Si les estimations sont incertaines, utiliser des tailles de Tshirt (Small, Medium, Large). Ne pas estimer, ou estimer uniquement lorsque le cot d'un retard le justifie. Lgrement influencs par Scrum (puisque c'est l d'o nous venions, aprs tout) nous avons dcid de dmarrer les estimations avec des story points. Mais dans la pratique, les quipes ont trait les story points comme si c'tait des heures/homme (cela leur semblait plus naturel). Au dbut, toutes les stories taient estimes. Avec le temps, les managers ont appris que s'ils conservaient un nombre faible de projets mens de front, ils ne faisaient pas attendre les parties prenantes. Ils ont galement appris que dans le cas d'un changement soudain, ils pourraient revoir les priorits et traiter le problme. Le besoin de prvoir la date de livraison n'tait plus un vrai problme. Les managers en vinrent ne plus demander d'estimations pralables. Ils ne l'ont fait que lorsqu'ils craignaient de laisser des gens en attente. Au cours des premiers temps, un manager, stress suite un appel tlphonique, a promis la livraison d'un projet avant la fin de cette semaine. Le projet tant sur le tableau Kanban, il s'avra facile d'valuer l'tat d'avancement (comptabiliser les stories termines) et de conclure qu'il serait ralis environ 25% la fin de la semaine. Du coup, un dlai supplmentaire de trois semaines semblait ncessaire. Face ce constat, le manager changea la priorit du projet, stoppa les
81
autres travaux en cours et rendit ainsi la livraison possible dans les dlais prvus. Vrifiez toujours le tableau!
Que reprsente la taille estime ? Le temps de cycle ou le temps de travail ?

Nos story points refltaient un temps de travail, c'est dire le nombre d'heures de travail ininterrompu que cette story prendrait selon notre estimation ; et non pas un temps de cycle (ni le temps calendaire, ni le nombre d'heures d'attente). En mesurant le nombre de story points atteignant la ligne done (donc livrs) chaque semaine (vlocit), on pouvait en dduire le temps de cycle. Nous avons estim chaque nouvelle story une seule fois, nous n'avons pas revu les estimations des stories pendant leur traitement. Cela nous a permis de rduire au minimum le temps pass par l'quipe sur les estimations.
28
Alors, comment avons-nous travaill, concrtement ?
Le systme Kanban pose vraiment trs peu de contraintes, vous pouvez travailler de toutes sortes de faons. Vous pouvez laisser l'quipe s'appuyer sur un dclenchement planifi des activits ou vous pouvez choisir de commencer une activit lorsqu'elle est suffisamment prcise pour la justifier.
Figure 7. Quand trois tches sont places dans le backlog, cela dclenche une session d'estimation/planification. Nous avons dcid de programmer deux vnements rcurrents : Le point quotidien - avec toute l'quipe, devant le tableau, pour identifier les problmes et aider crer une vision transversale partage des tches des membres des autres quipes. Le planning hebdomadaire d'itration, avec pour objectifs la planification et l'amlioration continue.
83
Cela a bien fonctionn pour nous.
Le point quotidien
Le point quotidien tait similaire celui pratiqu en Scrum. Cela se droulait aprs la runion quotidienne de Scrum de Scrums qui impliquait toutes les quipes (dveloppement, tests, exploitation). Le Scrum de Scrums fournissait des entres importantes aux quipes Kanban, telles que l'identification des problmes traiter en premier ou l'quipe de dveloppement la plus en difficult ce moment l. Au dbut, les managers assistaient rgulirement ces points quotidiens, proposant des solutions et prenant des dcisions vis--vis des priorits. Au fil du temps, comme les quipes se sont amliores en terme d'auto-organisation, les managers ont espac leur prsence (mais n'taient jamais trs loin en cas de besoin).
La planification d'itration
Une fois par semaine, nous organisions une runion pour planifier l'itration. Nous avons conserv cette frquence d'une semaine car nous avons constat que si nous ne prenions pas ce temps pour planifier, il tait consomm par d'autres priorits . Et puis nous avions besoin de plus de discussions d'quipe. L'ordre du jour typique tait le suivant : Mettre jour les diagrammes et le tableau (les projets termins taient dplacs vers le Mur des Termins).
ALORS, COMMENT AVONS-NOUS TRAVAILL, CONCRTEMENT ? | 85
Bilan de la semaine coule. Que s'est-il pass ? Pourquoi cela s'est pass ainsi ? Que pourrions nous faire pour amliorer les choses ? Ajustement de la limite de TAF (si ncessaire). Rpartition des tches et estimation des nouveaux projets (si besoin tait).
En gros, la runion de planification d'itration tait une combinaison d'estimations et d'amlioration continue. Les problmes de petite ou de moyenne taille taient rsolus sur le champ avec l'appui des managers de premier niveau. Mais garder le rythme sur des problmes complexes d'infrastructure tait une preuve plus ardue. Pour grer a, nous avons introduit la possibilit pour chaque quipe de remonter 2 obstacles pour l'quipe son manager. Les rgles taient les suivantes : 1. Un manager peut travailler sur 2 obstacles en parallle. 2. Si les 2 places sont prises, on peut ajouter un nouvel obstacle condition de retirer celui d'importance la plus faible. 3. C'est l'quipe qui dcide quand un obstacle est limin.
Ce fut un changement positif. Tout coup, les quipes pouvaient voir que leurs managers travaillaient pour les aider, mme sur des problmes complexes. Ils pouvaient pointer le tableau des obstacles et demander comment a se passe ? Ils ne pouvaient plus tre oublis ou doubls par une nouvelle stratgie plus prioritaire. Un exemple d'obstacle srieux : l'quipe exploitation n'arrivait pas obtenir l'aide dont elle avait besoin de la part des dveloppeurs quand ils suspectaient un bug. Ils avaient besoin d'aide pour identifier quelle partie du systme tait responsable du problme ; mais comme les dveloppeurs
taient pris dans leur sprint dvelopper de nouvelles choses, les problmes continuaient s'empiler. Ce n'est donc pas tonnant que les exploitants aient eu l'impression que les dveloppeurs ne s'occupaient pas assez de la qualit. Quand cet obstacle a t mis en vidence, il a t remont, d'abord au manager de premier niveau, puis plus tard au manager de dpartement. Celui-ci a alors programm une runion avec le responsable des dveloppements. Dans les dbats qui suivirent, les managers dcidrent de mettre en priorit premire la qualit, et ils ont imagin une solution de support tournant, des dveloppeurs vers les exploitants - chaque sprint, une quipe de dveloppement serait joignable et se rendrait instantanment disponible pour assister l'exploitation. Aprs avoir obtenu le soutien de ses managers, le responsable des dveloppements a fourni une liste de contacts aux quipes de support. Ils ont test immdiatement la solution, suspectant qu'elle ne fonctionnerait pas. Mais les devoirs avaient t bien faits cette fois et le problme a t considr comme rsolu. Cela a t d'un grand secours pour les quipes d'exploitation.
29
Trouver un concept de planification qui fonctionne
Une histoire
Je me souviens d'une histoire qui a influenc le comportement de l'une des quipes. J'tais assis avec eux lors de leur deuxime session d'estimation. L'quipe tait bloque sur un projet qu'ils ne savaient pas comment estimer. Il y avait trop d'inconnues et la session d'estimation ralentit jusqu' s'arrter. Plutt que de rentrer dans le jeu et prendre les choses en main, je leur ai demand de retravailler leur processus pour trouver une meilleure solution. Conduits par leur manager, ils ont relev le dfi et ont commenc concevoir leur propre solution. Cet vnement a vraiment constitu un tournant, une victoire importante partir de laquelle ils ont vraiment constitu une quipe en confiance. partir de ce moment l, ils ont volu si rapidement qu'il a presque fallu que nous nous cartions de leur chemin ! Deux mois plus tard, leur manager s'est approch de moi aprs une rtrospective : J'ai un problme m'a-t-il dit en pointant le tableau de Kanban. Nous n'avons pas de vrais problmes, que devons-nous faire ?
Rinventer la planification
Les sessions d'estimation par planning poker impliquant l'ensemble des membres d'une quipe n'ont march pour aucune des quipes d'exploitation. Quelques explications : 1. La connaissance tait trop ingalement rpartie dans l'quipe. 2. La plupart du temps, une seule personne prenait la parole. 3. Les membres de l'quipe avaient l'esprit aux problmes urgents traiter leur bureau.
87
Mais, par l'exprimentation, les quipes ont construit indpendamment deux processus d'estimation diffrents. Chacun d'entre eux a bien fonctionn pour les quipes respectives.
Approche 1 - Echanger et revoir
Pour chaque projet/story, dsigner une paire senior + junior pour estimer (c'est dire une personne qui connait particulirement bien la story et une autre qui ne la connait pas bien). Cela aide diffuser la connaissance. Les autres membres de l'quipe choisissent quelle story ils veulent aider estimer (mais avec une limite de quatre personnes par story pour conserver une discussion efficace). Chaque quipe d'estimation dcoupe sa story en tches et, si ncessaire, l'estime. Puis, les quipes changent les stories et revoient le travail des autres (une personne par quipe tait dtache pour expliquer le travail de son quipe aux relecteurs). Termin !
En gnral, la session d'estimation durait environ 45 minutes et le niveau de concentration restait lev tout au long de la runion. 1 2 ajustements taient gnralement effectus lors de la rotation et revus par un ensemble de regards nouveaux.
TROUVER UN CONCEPT DE PLANIFICATION QUI FONCTIONNE | 89
Approche 2 - revue de haut niveau puis estimation

Deux membres expriments de l'quipe mnent une revue de haut niveau sur la story / le projet avant la planification. Ils analysent les solutions d'architecture et font un choix. Une fois lance, l'quipe dcoupe la story en tches en utilisant la solution propose comme point de dpart.
Figure 8. Dcoupage en tches avec revue par une autre quipe lors de la planification d'itration.
30
Quoi mesurer ?
De nombreux points pourraient tre mesurs : le temps de cycle (temps coul entre le moment o le besoin est dcouvert et o il est satisfait), la vlocit, les files d'attente, les burndowns La question essentielle est de savoir quels indicateurs peuvent tre utiliss pour amliorer le processus. Mon conseil est d'exprimenter et de trouver ce qui marche pour vous. Nous avons appris que les burndown charts taient surdimensionns pour les petits projets de 1 4 semaines. La progression peut tre examine en regardant le tableau Kanban (nombre de stories qui sont dans le backlog et nombre de stories qui sont termines). Indicateur propos Temps de cycle Pour Facile mesurer. Pas d'estimation requise. Dmarre et finit avec le client. Un indicateur brut mais facile pour mesurer l'amlioration et la variation. Plus prcis que la vlocit totale. Contre Ne tient pas compte de la taille.
Vlocit totale (agrge les types de travaux)
N'aide pas prvoir les dates de livraison pour des types de travaux spcifiques. Pour tre utile, ncessite d'tre mesure partir du besoin utilisateur jusqu' sa livraison. Prend plus de temps pour suivre l'volution que la vlocit totale. Cela ne vous dit pas si la cause est lie une demande ingale ou une capacit ingale. Une file d'attente vide
Vlocit par type de travail
Longueur des files d'attente
Un indicateur rapide pour mesurer la fluctuation des demandes. Facile visualiser.

91
Indicateur propos
Pour
Contre peut en ralit indiquer une surcapacit.
Nous avons commenc par mesurer la Vlocit par type de travail et la Longueur des files d'attente. La vlocit par type de travail est facile mesurer et est suffisante. La longueur des files d'attente est un indicateur de premier plan, car il peut tre repr instantanment (une fois que vous savez o regarder).
Figure 9. Goulets d'tranglement et opportunits. La zone rouge montre comment les files d'attente se sont accumules pour faire apparatre un goulet d'tranglement sur le test. L'absence de file d'attente dans la colonne backlog du support indique qu'il n'y a pas de temps d'attente pour une nouvelle demande de support. C'est bon signe pour un niveau de service lev. Nous n'avons pas utilis de diagramme de flux cumul, mais cela aurait t intressant.
QUOI MESURER ?| 93
Nous n'avons pas utilis les diagrammes de flux cumuls puisque le tableau Kanban et le graphe de vlocit nous ont donn suffisamment d'informations, tout au moins dans nos premires phases de monte en comptence. Les goulets d'tranglement, l'ingalit du flux et la surcharge de travail ont pu tre facilement identifis et la rsolution de ces choses-l nous a occups pendant les six premiers mois.
31
Comment les choses ont commenc changer
Trois mois aprs l'introduction de Kanban, l'quipe d'administration systme a t nomme quipe la plus performante du dpartement informatique par le management. Dans le mme temps, cette quipe a galement t lue comme l'une des trois expriences les plus positives au cours de la rtrospective de la socit, une manifestation l'chelle de l'entreprise qui a lieu toutes les six semaines. C'tait la premire fois qu'une quipe se plaait au top 3 ! Ceci alors qu'il y encore 3 mois, cette quipe tait reconnue comme un goulet d'tranglement dont la plupart des gens se plaignaient. La qualit de service s'est clairement amliore. Comment est-ce donc arriv ? Le moment essentiel a t quand tout le monde a commenc bouger ensemble dans le mme sens. Les managers ont donn une orientation claire et ont protg l'quipe du boulot qui ne la concernait pas, et les quipes se sont engages sur la qualit et les dlais. Il a fallu environ trois quatre mois pour en arriver l, mais aprs tout s'est pass en douceur. Ce n'est pas comme si tous les problmes avaient disparu dans le monde (si c'tait le cas, on serait tous au chmage n'est-ce pas ? ) - mais nous avons d relever de nouveaux dfis tels que comment garder une quipe motive pour s'amliorer (quand elle n'est plus le goulet d'tranglement) ? Une pice importante du puzzle de l'auto-organisation a t l'introduction du principe un contact de l'exploitation par quipe. Cela signifie que chaque quipe de dveloppement se voyait affecter leur propre interlocuteur au support exploitation. Kanban a rendu cela possible en permettant aux membres de l'quipe d'exploitation de s'auto-organiser autour du travail, de prvenir la surcharge de travail et de faciliter l'amlioration continue. Avant, une personne au hasard dpilait un problme de la file d'attente, essayait de le rsoudre au mieux de ses comptences et enchanait sur le problme suivant. Tout dfaut de communication signifiait qu'il fallait tout recommencer avec une nouvelle
95
demande de support. Lorsque le principe un-pour-un a t mis en place, l'quipe support eut tout coup l'opportunit de rpondre rapidement lorsque des donnes errones et des problmes de qualit menaaient le systme. Pour anecdote, aprs un certain temps, les procdures de communication ont volu vers des mthodes plus personnalises : les membres de l'exploitation ont commenc utiliser la messagerie instantane avec les dveloppeurs qu'ils connaissaient bien, le courrier lectronique pour ceux qui crivaient mieux qu'ils parlaient et le tlphone si c'tait le moyen le plus rapide pour rsoudre le problme
Avant
Figure 10. Avant : le manager en premire ligne est le point de contact principal pour l'quipe. Tout ce qui doit se faire et qui est important passe par lui. Les problmes de moindre importance, typiquement ceux des dveloppeurs, sont reus via le systme de suivi des problmes. Trs peu d'interactions directes entre les personnes.
COMMENT LES CHOSES ONT COMMENC CHANGER | 97
Aprs
Figure 11. Aprs : un contact de l'exploitation par quipe. Les quipes de dveloppement parlent directement une personne dfinie l'exploitation. Beaucoup d'interactions entre les personnes. Les membres de l'quipe d'exploitation organisent eux-mmes leur travail en utilisant le tableau Kanban. Le manager se concentre sur la priorisation des gros projets et sur le renfort de l'quipe lorsque des problmes difficiles se posent. Quels sont alors les impacts sur la performance de l'quipe ?
Figure 12. La vlocit totale et la vlocit projets, mesures en story points faits par semaine. La vlocit totale est la somme de toutes les colonnes, la vlocit projets reprsente la partie consacre aux projets (gros travaux, par exemple la mise niveau d'une plateforme matrielle). Les deux creux correspondent 1) une semaine o presque tous les membres de l'quipe taient en voyage et 2) une version majeure de l'quipe de dveloppement. Ainsi, l'quipe a affich une tendance globalement positive. Dans le mme temps l'quipe a lourdement investi dans le partage des connaissances en utilisant la programmation en binme.
COMMENT LES CHOSES ONT COMMENC CHANGER | 99
Jetons un coup d'il la performance de l'quipe des DBAs :
Figure 13. Vlocit totale et petites activits de support. Le creux du milieu correspond la priode de Nol. La vlocit totale a une tendance la hausse mme si la variance est significative. Ce qui a conduit l'quipe surveiller le nombre de petites tches de support (tches normalement trop petites pour tre affiches sur le tableau Kanban). Comme vous le pouvez le constater, le graphique montre une corrlation inverse entre le nombre de petites tches de support et la vlocit totale. L'quipe de support ayant commenc appliquer Kanban plus tard que les deux autres quipes, nous n'avons pas encore de donnes fiables pour le moment.
Mrissement
Lorsque nous avons commenc, trouver les zones de problmes a t facile. Mais trouver les plus grandes opportunits d'amlioration a t dur. Le tableau Kanban nous a apport un tout nouveau niveau de transparence. Non seulement il tait plus facile de reprer les problmes, mais d'importantes questions ont t souleves concernant le flux de travail, la variance et les files d'attente. Nous avons commenc utiliser les files d'attente comme un outil pour isoler les problmes. Quatre mois aprs avoir commenc appliquer Kanban, les gestionnaires partaient la chasse aux gnrateurs de variance qui perturbaient leurs quipes. Comme les quipes voluaient d'un niveau individuel vers un niveau autoorganis, les managers ont ralis qu'ils taient confronts de nouveaux
dfis en termes de leadership. Ils devaient davantage s'occuper des problmes des gens - traiter les rclamations, dfinir des objectifs partags, rsoudre les conflits et ngocier des accords. Ce ne fut pas une transition sans douleur - ils ont ouvertement fait remarquer que l'apprentissage exigeait comptences et nergie. Mais ils ont relev le dfi et ont fini par devenir de meilleurs leaders.
32
Leons apprises
Des contraintes mergent lorsque le travail faire diminue
Toutes les quipes ont commenc avec des limites de TAF assez confortables. cette poque, les efforts ont t employs pour crer un flux de travail et pour s'assurer que l'organisation obtenait le soutien dont elle avait besoin. Au dbut, les managers voulaient avoir de nombreux projets en parallle, mais aprs quelques semaines il devint vident qu'il n'y avait pas la capacit suffisante pour traiter les projets de plus faible priorit. Il a suffi de jeter un rapide coup d'il au tableau pour constater qu'aucun travail n'tait dmarr sur les projets de faible priorit. Cela a incit les managers rduire le nombre de projets par quipe. Au fil du temps, le flux devenant de plus en plus stable pour les travaux prioritaires, nous avons commenc resserrer les limites de TAF. Cela a t ralis en rduisant le nombre de projets en cours (colonnes) de trois deux, puis un. ce moment l, des contraintes extrieures l'quipe commencrent apparatre. Certains membres d'quipes signalrent qu'ils ne recevaient pas d'aide dans les temps, si bien que les managers commencrent y prter attention.
101
Une autre chose qui est remonte la surface a t quel point la mauvaise qualit des livrables produits par d'autres quipes pouvait dgrader les performances. Il a t difficile de maintenir un flux de travail rgulier et rapide lorsque les lments en entre avaient en permanence besoin d'tre corrigs. Ces problmes taient connus avant que nous commencions. La question tait alors de savoir quel problme traiter en premier et ceci avec l'accord de tout le monde. l'aide du tableau Kanban, tout le monde a pu se rendre compte du problme spcifique qui impactait le flux, ce qui a permis de bnficier de l'effort commun pour traiter la question globalement quelles que soient les diffrentes entits en prsence.
Le tableau va changer en cours de route, ne figez pas sa conception

Tous les tableaux Kanban changent en cours de route. La conception du tableau est gnralement revue deux ou trois fois avant qu'une quipe le considre fonctionnel. Donc, investir beaucoup de temps dans la premire version du tableau est sans doute inutile. Assurez-vous que vous pouvez rorganiser le tableau facilement. Nous avons utilis des bandes de ruban noir pour les bordures du tableau. C'tait facile rorganiser et utilisable aussi bien sur les murs que sur les tableaux blancs. Un autre moyen possible est de dessiner le tableau avec des marqueurs pais (mais assurez-vous qu'ils soient effaables ! ) Vous trouverez ci-dessous un exemple typique d'une optimisation de la conception d'un tableau. L'ordre des priorits changeaient souvent au dbut, donc afin d'viter d'avoir dplacer des colonnes entires de post-
LEONS APPRISES | 103
its, l'quipe a choisi d'afficher un numro de priorit au dessus de chaque colonne.
Figure 14. Tableau Kanban avec des autocollants pour voir les priorits
N'ayez pas peur d'exprimenter et d'chouer

La leon que je tire de cette aventure est que c'est sans fin. Nous n'avons pas russi voir une fin. Il y a uniquement un mode d'exprimentation et d'apprentissage qui ne s'arrte jamais. Ne jamais chouer signifie ne jamais apprendre. Nous avons chou plusieurs reprises le long de la route (mauvaise conception des tableaux, mauvaises estimations, burndown redondants, ) mais chaque fois nous avons appris quelque chose de nouveau et d'important. Si nous avions cess d'essayer, comment aurions-nous pu apprendre ? Le succs de Kanban a motiv les quipes de management et les quipes de dveloppement Scrum exprimenter les tableaux Kanban. Peut-tre que ce livre vous y aidera !
Points retenir
Commencez par des rtrospectives !
Beaucoup de choses auxquelles il faut penser hein ? Esprons que ce livre ait permis dclaircir ce qui tait nbuleux. En tout cas, a a fonctionn pour nous Si vous tes intresss par le changement et l'amlioration de vos processus, permettez-nous de prendre une bonne dcision pour vous ds maintenant. Si vous ne faites pas de rtrospectives rgulirement, alors commencez par a ! Et assurez-vous qu'elles dbouchent sur un vritable changement. Faites appel un facilitateur externe si ncessaire. Une fois que vous avez mis en place des rtrospectives efficaces, vous commencez un voyage pour voluer vers le processus parfaitement adapt votre contexte quil soit bas sur Scrum, XP, Kanban, une combinaison de ceux-ci, ou quoi que ce soit d'autre.
N'arrtez jamais d'exprimenter !

Kanban ou Scrum n'est pas l'objectif final, c'est l'apprentissage continu qui l'est. L'un des grands principes dans le monde du logiciel est le feedback trs rapide : c'est la cl de l'apprentissage. Donc utilisez ce feedback ! Posez des questions sur tout, exprimentez, chouez, apprenez, puis exprimentez nouveau. Ne vous inquitez pas de bien faire les choses ds le dbut, parce que vous ne russirez pas ! Il suffit de commencer un endroit et de progresser partir de l. Le seul vritable chec est de ne pas russir apprendre de ses checs. Mais bon, vous pouvez aussi apprendre en le sachant. Bonne chance et profitez du voyage ! Henrik & Mattias, Stockholm le 24/06/2009
105
H : C'est tout ce que nous avons ? M : Je pense que oui. Arrtons-nous ici. H : Peut-tre devrions-nous leur dire qui nous sommes ? M : Exact. Si nous le faisons, nous passerons pour des gars sympas et on nous proposera peut tre des missions de consultant. H : Alors on le fait ! Ensuite, on s'en va. M : Oui, on a autre chose faire, ainsi que nos lecteurs d'ailleurs. H : En fait, mes vacances commencent maintenant. M: OK, n'insiste pas.
Les Auteurs
Henrik Kniberg et Mattias Skarin sont des consultants de la socit Crisp Stockholm. Ils aident les entreprises russir dans le dveloppement logiciel la fois sur les plans techniques et humains. Ils ont aid des dizaines d'entreprises mettre en uvre les principes Lean et Agile pour travailler efficacement. Henrik Kniberg Au cours de ces dix dernires annes, Henrik a t Directeur Technique de 3 socits informatiques sudoises et en a aid bien d'autres amliorer leur processus. Il est Certified Scrum Trainer et travaille rgulirement avec les pionniers du Lean et de l'Agile tel que Jeff Sutherland, Mary Poppendieck et David Anderson. Le prcdent livre de Henrik Scrum et XP depuis les Tranches a conquis plus de 150 000 lecteurs et est l'un des livres les plus populaires sur le sujet. Il a t distingu plusieurs reprises en tant que meilleur orateur lors de confrences internationales. Henrik a grandi Tokyo et vit maintenant Stockholm avec son pouse Sophia et ses trois enfants. Il est musicien ses heures perdues, compose et joue de la basse ainsi que du clavier avec des groupes locaux. henrik.kniberg<at>crisp.se http://blog.crisp.se/henrikkniberg http://www.crisp.se/henrik.kniberg
107
Mattias Skarin Mattias travaille en tant que coach Lean et fait profiter les entreprises des avantages du Lean et de l'Agile. Il coache toutes les couches, des dveloppeurs aux managers. Il a aid une socit qui dveloppe des jeux rduire son temps de dveloppement de 24 mois 4 mois, a restaur la confiance dans un dpartement de dveloppement entier et fut l'un des pionniers de Kanban. En tant qu'entrepreneur, il a cofond et dirig deux entreprises. Mattias a un diplme d'ingnieur qualit et a travaill pendant 10 ans comme dveloppeur sur des systmes critiques. Il vit Stockholm et adore danser le rock n'roll, courir et skier. mattias.skarin<at>crisp.se http://blog.crisp.se/mattiasskarin http://www.crisp.se/mattias.skarin
Les Traducteurs
Claude Aubry Dveloppeur en SSII, architecte logiciel, chef de projet puis consultant, Claude Aubry a cr sa socit de conseil en 1994. Depuis 2005, il se consacre Scrum et aux mthodes agiles. Il est prsident de lassociation toulousaine SigmaT ddie la promotion des mthodes agiles, et membre du bureau du Scrum User Group franais. Il est galement professeur associ pour lIUP ISI l'Universit Paul Sabatier de Toulouse (o il enseigne Scrum) et linitiative du logiciel OpenSource IceScrum (ddi Scrum). Il est lauteur dun blog de rfrence Scrum, Agilit et Rock'n roll qui a reu en moyenne 6000 visites par mois en 2009. Vous pouvez galement le suivre sur Twitter @claudeaubry. Il vit Castanet-Tolosan, prs de Toulouse, avec Ruth. Maintenant que les enfants ont quitt la maison et qu'il ne reste que Suissi (le chat), il a plus de temps pour se consacrer Scrum, au rugby (aprs une carrire modeste d'ailier, il soutient le Stade Toulousain au stade ou devant la tl avec des amis et des bires) et au rock'n roll. http://www.sigmat.fr/ http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group http://www.iupisi.ups-tlse.fr/ http://www.icescrum.org/ http://www.aubryconseil.com/ http://twitter.com/claudeaubry
Frdric Faure Architecte Java/JEE avec plus de 10 ans d'exprience, Frdric Faure a dcouvert l'agilit en 2006 au sein du groupe Excilys Il a cr Equitalis en 2007 pour porter le modle Excilys et promouvoir l'agilit dans la rgion bordelaise. Il est devenu par exprience consultant agile tout en gardant un pied dans la technique. Il s'investit dans diverses communauts informatiques sur bordeaux: French Scrum User Group, Okiwi. Il a activement particip l'Agile Tour 2009 Bordeaux en tant que sponsor, co-organisateur et intervenant ! Vous pouvez le suivre sur Twitter @ffaure32. Il vit dans la rgion bordelaise avec sa petite famille (mari, 2 jeunes enfants). Pour tre cohrent avec sa passion pour Scrum, il pratique aussi rgulirement que possible le rugby https://www.excilys.com http://groups.google.fr/group/sug-bordeaux?hl=fr http://www.okiwi.org/ http://www.agiletour.org/fr/at2009_bordeaux.html http://twitter.com/ffaure32
LEONS APPRISES | 111
Antoine Vernois Antoine a un doctorat de l'ENS Lyon en Informatique et se spcialise dans les systmes distribus. Il pratique intuitivement les grands concepts de l'agilit pendant plusieurs annes avant d'en dcouvrir leurs formalisations en 2008. Il devient alors ScrumMaster et s'implique activement dans les communauts Agile et Scrum. Il est notamment membre de l'association SigmaT et membre du conseil d'administration du Scrum User Group France. Il a galement implment le Nokia Test/Scrum But. Il vit actuellement sur Toulouse, mais qui sait o il sera demain ? Il s'intresse la photographie et aux littratures de l'imaginaire. Vous pouvez le suivre sur son blog personnel o l'on parle parfois d'agilit "Mon blog moi que j'ai" et sur Twitter @avernois. http://www.sigmat.fr http://www.frenchsug.org http://antoine.vernois.net/scrumbut http://antoine.vernois.net/dotclear http://twitter.com/avernois
Fabrice Aimetti Fabrice est passionn par l'Agile et par Scrum en particulier. Il est impliqu dans des communauts telles que le Scrum User Group bordelais, Okiwi et SigmaT. Rgulirement, il publie un billet de rtrospective ou une traduction sur son bloc-notes agile. Il vit Bordeaux avec son pouse Stphanie et ses deux enfants. De temps en temps, il fait une pause en pratiquant l'Akido ou en dgustant un bon Single Malt :-o fabrice.aimetti <at> gmail.com http://groups.google.fr/group/sug-bordeaux?hl=fr http://www.okiwi.org/ http://www.sigmat.fr/ http://www.fabriceaimetti.fr/dotclear/index.php?tag/R%C3%A9trospective http://www.fabrice-aimetti.fr/dotclear/index.php?pages/Traductions-agiles http://www.fabrice-aimetti.fr/dotclear/index.php?tag/Agile

KanbanAndScrum FR

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

KanbanAndScrum FR

Загружено:

Авторское право:

Доступные форматы

Kanban et Scrum tirer le meilleur des deux

Lead time MMF scrum

Prface de Mary Poppendieck

Prface de David Anderson

1re Partie - Comparaison

4 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

NdT : le livre a t traduit en franais : http://www.infoq.com/resource/news/2007/06/scrum-xpbook/en/resources/ScrumAndXpFromTheTrenches_French.pdf

QUE SONT SCRUM ET KANBAN ? | 5

6 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Vous trouverez des liens utiles sur Kanban : http://www.crisp.se/kanban

8 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Aucun outil n'est complet, aucun outil n'est parfait

QUELS SONT LES LIENS ENTRE SCRUM ET KANBAN ? | 9

Scrum est plus normatif que Kanban

10 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Ne vous limitez pas lemploi dun seul outil !

QUELS SONT LES LIENS ENTRE SCRUM ET KANBAN ? | 11

12 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

quipe n (rythme unique) 1

16 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

quipe n (trois rythmes) 2

quipe n (rythme essentiellement pilot par les 3 vnements)

18 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

20 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

LES DEUX SONT EMPIRIQUES | 21

22 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Exemple : exprimentez les limites de TAF avec Kanban

LES DEUX SONT EMPIRIQUES | 23

24 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

LES DEUX SONT EMPIRIQUES | 25

Exprimentez ! Ou, comme les Scrumologistes le disent : Inspectez & Adaptez !

28 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Et que dirait l'quipe Kanban ?

32 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Voici deux exemples :

36 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

38 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

ou en ajoutant des lignes de nage :

40 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Scrum recommande un backlog produit prioris

42 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Scrum impose des points quotidiens

Scrum recommande des burndown charts

DES DIFFRENCES MINEURES | 43

44 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

46 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

RSUM SCRUM VS KANBAN | 47

Flux une pice

48 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Un jour au pays de Kanban

RSUM SCRUM VS KANBAN | 49

50 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

RSUM SCRUM VS KANBAN | 51

Est-ce que le tableau Kanban doit ressembler a ?

54 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

RSUM SCRUM VS KANBAN | 55

2me Partie - tude de cas

62 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Vision de l'exploitation par les dveloppeurs

Vision du dveloppement par l'exploitation

64 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

68 |KANBAN ET SCRUM TIRER LE MEILLEUR DES DEUX

Travail en cours vs dbit du flux de travail Thorie des contraintes