Le praticien agile, c’est qui  ?

Il a lu « Scrum & XP from the trenches » un soir, il l’a gardé 2 semaines comme livre de chevet, il l’a rangé, et il a participé à un ou plusieurs projets agiles au sein de sa DSI. il a atteint un certain niveau de maturité sur les projets agiles et a pris du recul sur la méthode. Il se pose aujourd’hui des questions comme « Peut-on vraiment concilier TMA et agilité? »ou alors « Comment pérenniser la dynamique d’amélioration continue au sein de mes équipes » ou bien encore « Comment fluidifier les process en amont et en aval de mon équipe Scrum? », etc.

Le format Open Space c’est quoi ?

C’est un format ouvert sur une demi journée, où les participants proposent et choisissent eux-mêmes les sujets sur lesquels ils vont ensuite travailler par petits groupes lors de sessions de 40 minutes. A l’issue de chaque session, chaque groupe présente à l’ensemble de l’assemblée un compte-rendu des échanges. La philosophie de l’exercice est très bien décrite ici.

Et pourquoi un Open Space pour praticiens agiles ?

Parce que la communauté de praticiens agiles est de plus en plus grande et que nous, OCTO, constatons que les questions qui reviennent chez nos clients Agiles sont souvent focalisées autour des mêmes problématiques.

Après avoir organisé plusieurs ateliers découvertes de l’agile sur le format Open Space ces dernières années, nous avons donc organisé et animé une première session dédiée au praticiens agiles le 24 Novembre dernier, à laquelle ont participé des acteurs comme Médiametrie, FigaroCMS, Viadeo, Danone et Allocine.

Nous avons eu le privilège d’accueillir l’illustratrice Véronique Olivier-Martin (vous trouverez une présentation de ses interventions par Pierre Haski sur Rue89) dont le rôle consistait à capter en direct et faire émerger sur une fresque murale géante les principaux échanges au sein des groupes de travail : le résultat est détonnant et nous souhaitions partager le fruit de ce travail collaboratif riche avec vous.Vous pouvez télécharger la fresque en qualité originale ici. Et pour le plaisir, voici ci-dessous quelques illustrations issues de cette fresque et très représentatifs de nos échanges :

Waouh ça déchire ! La prochaine session c’est quand ?

Nous avons donc décidé de pérenniser l’événement sur le fond et sur la forme ! La prochaine session aura lieu Mardi 14 Février de 14h à 18h chez OCTO.

Super, je suis praticien agile et je souhaite prticiper, comment je m’inscris ?

Vous pouvez d’ores et déjà confirmer votre inscription ici!

Suggestion d'articles :

1. Open Space OCTO : nouvelle session praticiens agiles le 14 Février
2. Open Space pour les praticiens agiles le 24 novembre chez OCTO
3. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »

C’est votre 10eme itération, vous êtes en plein stand-up et Roger le nouveau ne sait toujours pas quel post-its prendre. Il faut dire que Roger n’arrête pas de vous demander quelle tâche de développement il doit prendre aujourd’hui.

Vous êtes tech –lead sur un nouveau projet et vous recherchez un nouveau framework de test en Javascript.

Vous êtes RH, et vous êtes en train de rédiger une fiche de poste pour ce curieux métier qu’est le « product owner ».

Vous êtes responsables produit d’une grande assurance et on vous demande de rédiger un backlog.

Vous avez envie d’en parler, venez le 27 Septembre à l’Apéro Agile !

Autour d’un verre, nous discuterons de l’état de l’Agile, de carrière, de pratiques, de techniques et de vos réussites.
Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

Pour venir à l’apéro agile, inscription ici.

Suggestion d'articles :

1. Apéro Agile, le retour !
2. Octo présente cinq sessions dans le cadre de la conférence Agile France
3. OCTO chez Google !

Situation n°1 : Vous regardez votre agenda, combien de réunions ont déjà été posées pour résoudre les problèmes en cours. Vous vous dites que « Ca fait beaucoup pour la journée »  en terminant votre tasse de café. Et d’ailleurs combien de fois avez-vous posé une réunion pour comprendre ce problème sur la vélocité de cette équipe ? Une vélocité qui ne décolle toujours pas, mais ces réunions vous auront permis, au choix, de rajouter des développeurs, de changer des développeurs, de changer d’architecture. Beaucoup de décisions pour, au final se rendre compte que la vélocité n’augmente toujours pas … Bref, le problème est toujours là.

Situation n°2 : C’est la fin de l’année, combien de produits avez vous lancé ? Combien de ses produits ont apportés de la satisfaction pour un client ? Et combien de réunions avez vous fait pour définir ces produits ? Combien de brainstorms et d’ateliers ? Beaucoup et à chaque fois énormément d’idées et de concepts sur comment tout ça va s’articuler, pour au final se rendre compte que peu de personnes utilisent vos produits …

Si vous avez rencontré l’une des situations présentées, et qu’après toutes ces réunions vous vous demandez encore ce qui se passe réellement, alors il est temps de sortir votre chapeau de détective privé pour aller enquêter sur le terrain !

Aller sur le terrain, mais pour faire quoi ? Pour résoudre les problèmes et trouver de nouvelles idées pardi ! En Lean Management (et plus particulièrement chez Toyota) on parle de Gemba, que l’on peut traduire en français par « Là où se trouve la réalité ». Essayons de déconstruire le mot « réalité » tout en gardant une perceptive liée au lean management. Cela signifie que c’est l’endroit où la valeur ajoutée est créée, c’est aussi l’endroit où les problèmes apparaissent et enfin c’est là où votre client obtient de la satisfaction.

Et pour bien comprendre ce qu’il se passe sur le Gemba, il va falloir utiliser votre chapeau de détective !

Comment utiliser le chapeau de détective ?

1. Quand le problème apparaît, ne tentez pas de le résoudre tout de suite, en travaillant à distance.
2. Vérifiez les éléments corrects du terrain en faisant une collecte méthodique des données.
3. Investiguer en ayant l’attitude d’un détective privé, d’un enfant curieux ou d’un journaliste.
4. Poser des questions de préférences ouvertes.
5. Souligner les différences sans heurter.

Exemples 1 : Pour comprendre cette histoire de vélocité qui n’augmente pas, allez binômer avec un développeur. Il est fort possible qu’il travaille sur du code legacy qui a une forme similaire à celle-ci :

try {
            final String[] proprietes = Synonymes.AppelSynonyme("fourchette");
            for (final String element : prop) {
                for (final String element2 : proprietes) {
                    final RE exp = new RE(digit + "\\s?" + element2 + "\\s?" + digit + "\\s?" + element, RE.REG_ICASE);
                    final REMatch fourchette = exp.getMatch(texte);
                    if (fourchette != null) {
                        final RE num = new RE(digit, RE.REG_ICASE);
                        final REMatch[] data = num.getAllMatches(fourchette.toString());
                        v[0] = data[0].toString();
                        v[1] = data[1].toString();
                    }
                }
            }
        } catch (...) {

Posez les questions suivantes :

• « Peux-tu m’en dire plus sur le code que tu es en train de refactorer ? »
• « Quelle est l’intention du refactoring sur lequel nous sommes en train de   binômer ? »
• « Quel est la plus petite amélioration du que tu souhaites introduire dans le logiciel ? »
• « Quelles sont les règles de développement de l’équipe ? »
• …

Exemples 2 : Sur le prochain incrément à développer, passer une journée chez votre client, celui qui utilise votre application :

• Restez un observateur passif et noter ce que vous voyez
• Participez à leurs différentes activités
• Binômer avec eux sur leurs tâches quotidiennes

Posez les questions suivantes :

• « Peux-tu m’en dire plus sur l’utilisation que tu as du logiciel ? »
• « Quelles sont les types utilisateurs de cette application ? »
• « Quelle serait l’idée complètement farfelue qu’il serait intéressant de développer ? »
• « Quel est le comportement que tu trouves le plus aberrant dans ce logiciel ? »
• …

Source du pattern : « More Secrets Of Consulting » Gerald Weinberg

A Retenir :

Nom : Le chapeau du détective

Motivation : Le chapeau du détective nous permet, sans jugement, d’observer et collecter des données, d’analyser, de trier des entrants et des options, de chercher à comprendre et de venir avec des explications rationnelles.

Forces : Permet d’obtenir l’information la plus riche sur votre projet avec le plus grand respect pour l’équipe que vous observez.

Applicabilité : Utiliser le chapeau du détective quand vous manquez d’information pour résoudre un problème.

Conséquences :

• Permet à un manager, un coach ou un tech-lead de trouver la source d’un problème
• Permet à un manager, un coach ou un tech-lead de connaître les points de satisfaction d’un client
• Permet à un manager, un coach ou un tech-lead de fonctionner en empathie avec son équipe

Implémentations :

• Le demandeur débute en posant la question par « Peux tu m’en dire plus à propos du [sujet important sur lequel il faut plus d’information] ? »
• Continuer en ne posant que des questions ouvertes
• Celui qui répond aux questions peut en passer certaines si ça l’embarrasse trop
• Le demandeur s’arrête quand il n’a plus de question
• A la fin si le demandeur a une suggestion à proposer, il demande à la personne si elle souhaite l’entendre

Suggestion d'articles :

1. OCTO Day, ca porte finalement bien son nom : une journée, organisée par les OCTOs, pour les OCTOs

Nous vous proposons ici de découvrir quelques aspects du lean en citations. Ces citations sont importantes, car pendant une expérimentation lean, elles amélioreront la compréhension et l’apprentissage des pratiques et outils lean. Elles agiront comme des moyens mnémotechniques en plaçant des refrains à nos chansons lean du quotidien.

Pour une présentation du lean, je vous conseille la lecture de cet article introductif : « Qu’est-ce que le Lean? ». J’aborde ici les principes et outils lean suivants :

• Le respect des gens
• L’élimination du gaspillage sur le flux de valeur
• L’amélioration continue

Le respect des gens

Le respect des individus est le principe le plus essentiel du Lean. Il vise à contribuer à l’épanouissement de chacun des collaborateurs à travers la mise en œuvre des conditions de ce développement personnel.

« Since it is people that manufacture things, manufacturing is impossible unless people are developed » -  Toyota « Developing People First » philosophy.

Au-delà de la mise en œuvre de mesures contribuant à cet épanouissement, il convient,  lorsqu’un problème survient, non pas de remettre en cause les personnes mais au contraire de questionner d’abord le système et d’identifier ses défaillances qui pourraient être à l’origine du problème.

« Don’t blame the individual, fix the system for them » -  William Edwards Deming

En effet,

« A bad system will defeat a good person every time » -  William Edwards Deming

Ainsi, loin de suspecter les individus au moindre dysfonctionnement, il s’agit de responsabiliser les collaborateurs, de les encourager, et de les aider à résoudre eux-mêmes les problèmes qu’ils rencontrent dans leur travail quotidien.

L’élimination du gaspillage sur le flux de valeur

Eliminer le gaspillage sur le flux de valeur constitue un objectif du lean. Celui-ci suppose d’identifier la valeur pour laquelle le client de l’entreprise est prêt à payer.

“It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages” -  Henry Ford

L’ensemble de l’entreprise est au service de cette création de valeur, qui se fait le long d’un flux de transformation. Or, tout au long de ce flux de transformation sont également réalisées des choses qui ne concourent pas à créer de la valeur : ce sont des gaspillages. On identifie 7 types de gaspillage : Surproduction, délai, stock, transport, mouvement inutile, processus inutile et défaut.

« The best approach is to dig out and eliminate problems where they are assumed not to exist » -  Shigeo Shingo

L’amélioration continue

« It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change » -  Charles Darwin

Cette loi de la sélection naturelle dans un environnement changeant s’applique aussi bien aux espèces qu’au secteur entrepreneurial. Comme vous pouvez l’imaginer, cette  nécessité de changer – perçue par Toyota – est commune à bon nombre d’entreprises.

Or pour changer, il faut agir :

« The definition of insanity is doing the same thing over and over again and expecting different results » -  Albert Einstein

Et il y a trois façons d’agir pour changer :

• Innover : faire quelque chose de nouveau
• Imiter : reprendre quelque chose qui a déjà fonctionné ailleurs
• Améliorer en continu pas à pas : partir de la situation actuelle et la changer petit à petit en s’assurant que chaque changement est une amélioration

La solution retenue par Toyota et consacrée dans le lean est l’amélioration continue. Cette solution est peu risquée car à petits pas mais nécessite un engagement de chacun et une discipline qui assure que chaque pas fait est bien une amélioration.

« Tirer le profit le meilleur de ce qui est: s’ingénier à l’améliorer plutôt que de chercher à le changer » -  André Gide (Journal, 4 juillet 1933)

L’avantage de l’amélioration continue à petits pas est également de permettre l’observation rapide des premières améliorations.

« Even a journey of one thousand miles begins with a single step. » -  Lao Tzu

Cette nécessité de s’améliorer est souvent résumée par la célèbre phrase de Hiroshi Okuda : « Failure to change is a vice ». En effet, l’inaction est le plus grave des gaspillages. La plupart du temps, il vaut mieux se tromper que ne rien faire.

Mais on oublie souvent la seconde partie de cette phrase que je juge toute aussi pertinente :

« Failure to change is a vice! I want everyone at Toyota to change and at least do not be an obstacle for someone else who wants to change » -  Hiroshi Okuda, Chairman of Toyota Motor Corp

Encore s’agit-il d’évoluer dans le bon sens. Pour cela, le lean propose une technique : le PDCA que nous ne détaillerons pas ici, popularisé dans les années 50 par W.E Deming à travers l’illustration de la méthode :  la roue de Deming.

« Let’s stop and understand the root cause of problems » -  Larman, Vodde

Gemba

Gemba signifie en japonais « là où se trouve la réalité ». C’est l’endroit où est créée la valeur ajoutée, l’endroit où apparaissent les problèmes, là où le client obtient sa satisfaction : c’est le terrain.

Autrement dit, c’est l’atelier ou le poste de travail dans l’usine. Dans nos métiers de la DSI, ce sont les réunions, les documents d’architecture, la documentation et même le code de nos logiciels…

« Go to the source to find the facts to make correct decisions, build consensus, and achieve goals at our best speed » -  Toyota Way 2001

C’est sur le terrain que l’on va identifier les fameux gaspillages que l’on souhaite supprimer.

« The most dangerous kind of waste is the waste we do not recognize » -  Shigeo Shingo

J’espère que ces citations vous aiderons et vous donnerons l’envie d’en savoir plus. Si j’ai oublié votre citation lean favorite, n’hésitez pas à commenter cet article. Voici une dernière idée pour la route, que je vous laisse interpréter :

« Never mistake motion for action » -  Ernest Hemingway

 

 

Suggestion d'articles :

1. Du Lean Software Development au Lean IT
2. Mon action lean du jour
3. Petit-déjeuner Lean Management et Systèmes d’Information, le 19 mai

Depuis la présentation retentissante de John Allspaw à Velocity 2009 sur la collaboration entre dev et ops, où il explique que chez Flickr le rythme de déploiement en production dépasse les 10 par jour, on entend beaucoup parler de « continuous delivery » et « continuous deployment ». Ce dernier se différencie par une automatisation complète de la chaîne de fabrication et déploiement entre le commit du développeur et le déploiement en production, alors que le « continuous delivery » préconise des interventions manuelles (simples « push-button ») pour approbation humaine de certaines étapes : tests fonctionnels manuels, test d’usabilité, contrôle des déploiements par le marketing, etc. J’emploierai le terme « déploiement continu » dans cet article pour regrouper les deux notions. Quelques sociétés nous font part de leur retour d’expérience : pour exemple un présentation du QCon San Francisco 2010 où il est cette fois question de 50 déploiements par jour! (rien que ça…) Ou encore plus récemment le talk de Facebook sur la culture et les outils qui leur permet de déployer tous les jours.

Comme beaucoup, je me suis d’abord demandé plusieurs fois : “Franchement… quel est l’intérêt de déployer tous les jours ?”. Je suis aujourd’hui convaincu que ce n’est pas un délire de geek ou une volonté d’être inscrit aux Guinness World Records. Voici les 5 raisons majeures de s’y intéresser.

1. L’innovation au cœur de la stratégie concurrentielle

Tout va très vite de nos jours; la concurrence est rude, les besoins évoluent rapidement, les modes se font et se défont sur le web… dans certains contextes, si vous n’êtes pas « time to market », vous êtes morts! Alors évidemment le déploiement continu n’aide pas à coder plus rapidement pour s’adapter à ces changements. L’idée est de construire constamment une application prête pour la production, afin de se donner les moyens de pouvoir la déployer à tout instant et de ne plus être nécessairement contraint par un planning sur 6 mois qui définit des lots de fonctionnalités impliqués dans telles versions majeures. De plus, il nous permet d’optimiser le lead time en réduisant les coûts de transactions et ainsi de répondre facilement à cette question que nous pose Mary Poppendieck :

How long would it take your organization to deploy a change that involves just one single line of code?

Sans tomber dans la dizaine de déploiements quotidien, le déploiement fréquent est un bon outil pour expérimenter des fonctionnalités, de préférence sur un groupe d’utilisateurs avant de déployer plus largement. En effet, à la manière des méthodes de développement agiles qui permettent de réduire la boucle de feedback et ainsi réduire le risque que l’application ne réponde pas aux spécifications au bout du tunnel (ou que finalement les spécifications n’étaient pas bonnes au vu du résultat…), le déploiement continu permet d’obtenir un feedback terrain extrêmement précieux issu de l’utilisation réelle de l’outil en production. Bien sûr le déploiement en lui-même n’est pas suffisant, il faut y ajouter une bonne dose de supervision applicative rendant possible l’analyse des comportements utilisateurs et la performance métier. Le concept Lean Startup repose d’ailleurs essentiellement sur cette boucle de feedback :

Illustration issue d’une présentation de Eric Ries (fondateur du Lean Startup)

2. Eliminer les gaspillages (Lean)

Voici un extrait issu d’un article de notre blog « Qu’est-ce que le Lean ? » :

Eliminer le gaspillage sur le flux de valeur. Il faut se concentrer sur ce qui crée la valeur pour laquelle le client de l’entreprise est prêt à payer. Toute l’entreprise est au service de cette création de valeur. Elle est créée le long d’un flux de transformation. Dans l’idéal, ce flux est tiré et sans stock pour réagir aux fluctuations de la demande et minimiser l’investissement. Cela signifie que l’on ne commence à produire quelque chose que lorsqu’il y a une demande. On ne produit alors que ce qu’il faut pour cette demande.

En effet, du code non déployé n’est rien de plus que du stock puisqu’il n’apporte aucune valeur pour le client. Il ne rapporte donc aucun bénéfice pour l’entreprise.

3. Evolution incrémentale (plutôt que radicale) du produit

En tant qu’utilisateur, vous préférez :

• les applications type “béta permanente” qui vous livrent régulièrement des nouvelles fonctionnalités ?
• ou l’approche “brand new app” tous les 6 mois/un an avec changement d’ergonomie et un lot de nouvelles fonctionnalités qui nécessitent une formation de 2 jours pour vous y adapter ?

J’ai vécu la deuxième approche régulièrement dans une vie antérieure pour des applications de gestion internes… c’était à chaque fois un supplice pour moi de devoir me réadapter à l’outil et perdre un temps fou en productivité. Et oui, l’homme n’aime pas les gros changements quand ils sont imposés et que le gain apporté par l’évolution n’est pas significatif.

A l’inverse, le déploiement continu ne doit pas faire apparaître trop de changements fréquents à l’utilisateur qui risque de se sentir perdu à chaque visite. Mais ce risque est mineur, ce n’est pas parce que vous déployez 10 fois par jour que les développeurs vont implémenter 10 nouvelles fonctionnalités par jour! Cela ne doit pas remettre en cause la définition d’un planning de déploiement des fonctionnalités.

4. Plus de deploy = moins de code = moins de risque = plus de stabilité !

Comme dans tout système dynamique, l’équilibre entre le changement et la stabilité est une question délicate. On a tendance à croire instinctivement que plus on introduit du changement dans un système, plus on risque de compromettre sa stabilité. En fait, ça dépend de la nature du changement… Par contre, John Allspaw fait le constat suivant : plus les déploiements sont espacés dans le temps, plus la quantité de changement est importante, et plus le temps de résolution (TTR) de problème est long. Il démontre donc que déployer plus fréquemment (donc moins de ligne de code par déploiement) permet de réduire le TTR de façon conséquente :

Illustration issue d’une présentation de John Allspaw

Pourquoi? Deux raisons à cela :

• moins il y a de lignes de code déployées, plus le temps de détection (TTD) de l’origine du problème est rapide
• le même enjeu qui nous pousse à faire plus de test pour avoir du feedback plus rapide (« fail fast ») : plus un bug est découvert tard, plus il est couteux à corriger.

Il va sans dire que le déploiement continu permettra de réduire encore le TTR en déployant le fix (rollback ou rollforward) en un clic! :)

5. Même pas peur de déployer en prod

Sans rentrer dans le détail de l’implémentation qui fera l’objet d’autres articles, il est évident que cette démarche repose essentiellement sur l’automatisation. C’est grâce à cette automatisation qu’on arrive à transformer le processus de déploiement, habituellement jugé délicat, voire risqué, en ce qu’on peut appeler un « non-évènement ».

Lorsque l’on déploie en production plus d’une dizaine de fois par jour, il faut :

• non seulement que le processus de fabrication soit fiable, c’est à dire que l’application soit constamment prête pour être déployée en production avec un niveau de qualité requis, garanti par une bonne couverture de tests automatisés
• mais également que le processus de déploiement soit le plus rapide, fiable et répétable possible pour limiter au maximum les indisponibilités et risques de panne.

En effet, plus on pratique cet exercice, plus on ressent le besoin de l’automatiser car trop laborieux manuellement, moins on a cette impression de naviguer vers l’inconnu car l’opération devient fiable et donc moins de raison de craindre le fameux « last mile ». Cela présente donc au final un autre avantage et pas des moindres pour tous les acteurs de la livraison en production : diminuer le stress et les sueurs froides.

Conclusion

Le déploiement continu peut jouer un rôle majeur dans la performance d’une entreprise. Vous l’aurez compris, cette technique est particulièrement adaptée pour des applications Web. Déployer une application « client lourd » 50 fois par jours n’est clairement pas une bonne idée, mais différents mécanismes (détaillés dans cet article) offrent néanmoins la possibilité d’accélérer le rythme des mises à jour.

Malheureusement, la démarche de déploiement continu est loin d’être simple à mettre en œuvre, dépendante de l’organisation en place et du niveau de coopération entre les différents acteurs du delivery. Elle est par exemple très adaptée aux entreprises de type startup. En revanche l’appliquer dans des grandes entreprises nécessitera un bon niveau de maturité, de communication et de confiance entre les équipes de développement/test (build) et de production (run) : leitmotiv du mouvement DevOps. Les outils jouent également un rôle majeur pour industrialiser le processus, nous aurons tout le loisir d’y revenir d’en d’autres articles!

Suggestion d'articles :

1. Le déploiement continu par Thoughtworks : Go!
2. Déployer les applications .NET sur cloud
3. Mes bonnes pratiques en PowerShell v2

On a maintenant l’habitude de voir des principes du Lean Management derrière beaucoup des pratiques Agiles. Par exemple :

• Les tests unitaires et l’intégration continue, sorte de Andon et de Poka Yoke à la fois ;
• Les rétrospectives, support privilégié du Kaizen, sorte de cercle de qualité des équipes de développements ;
• Les taskboards, « kanban boards » et autres radiateurs d’information comme outil de management visuel ;
• etc.

Plus intéressant est l’exercice de voir les bonnes pratiques DevOps comme des instanciations du Lean Management aux activités de livraison, intégration, tests, déploiement, suivi du run.

Les analogies et principes sous-jacents du Lean pouvant alors nous aider à mieux comprendre la « magie » des pratiques DevOps ou même à en imaginer de nouvelles !

Les pratiques DevOps comme instanciation du Lean

Jidoka, l’autonomation

Le Jidoka est le premier pilier du Système de Production Toyota. C’est l’automatisation avec une touche humaine, ou comment automatiser les opérations simples et répétitives, tout en conservant un contrôle humain pour orchestrer tout cet outillage, et prendre en main les situations complexes. La légende veut qu’un fondateur Toyoda ait ajouté un système de détection d’anomalie et d’arrêt automatique sur des métiers à tisser.

En IT, DevOps poursuit la même démarche en poussant au maximum l’utilisation des robots d’intégration continue, de déploiement automatique, de configuration ou de supervision. Tools matter.

Just in Time, le juste à temps

Le Just in Time est le second pilier du Système de Production Toyota. C’est la mise en flux pour livrer juste à temps (ni avant ni après) le produit demandé, dans la quantité demandée. Les outils du Jidoka sont le lissage, la réduction de la taille des lots (livrer plus souvent de plus petits lots) et surtout la diminution du coût de traitement d’un batch avec SMED.

La comparaison avec DevOps saute aux yeux lorsqu’on cherche à mettre en production plus régulièrement de plus petits lots de fonctionnalité.

Une fois le principe du JIT saisi, nous avons entre nos mains les outils théoriques pour mieux comprendre nos problèmes de fréquence de livraison, notamment :

• débusquer les opportunités de « SMED » et de diminution du coût de traitement d’un lot dans notre process dev⇒prod afin de diminuer le coût d’un déploiement, pour tendre vers le déploiement en continu ;
• déterminer la taille de batch optimale, i.e. la taille de MEP optimale pour un niveau d’outillage et de process donnés (à optimiser par SMED en parallèle).

Kaizen, l’amélioration continue

Pilier du Modèle Toyota, le Le Kaizen, consiste à tirer des leçons des problèmes, enrichir notre « système » et ceci à travers une démarche structurée et des outils d’analyse éprouvés (PDCA, 5 pourquois, diagramme de Pareto etc). On a tous envie de s’améliorer, le Kaizen nous aide à structurer et rendre efficace ces efforts d’amélioration.

La communauté DevOps n’est pas en reste et reconnaît qu’elle fait face à des systèmes complexes qui échoueront tôt ou tard, les champions étant ceux qui tireront vite et bien les leçons des échecs petits et grands. A titre d’illustration, le livre Web Operations y dédie un chapitre entier : « How to Make Failure Beautiful: The Art and Science of Postmortems ».

L’autre aspect souvent négligé ou mal compris de l’amélioration continue en DevOps vient de la réduction de la taille des lots (i.e. l’augmentation des livraisons de plus petit « batch » de code). Le Lean prend l’image suivante : diminuer le niveau de l’eau fait apparaître les rochers entre lesquels ils faut naviguer.
L’eau c’est le stock, dans notre cas tout ce qui n’est pas déployé, les rocher sont les problèmes. Quand on livre plus souvent on découvre plus souvent des problèmes. On peut dire qu’on met aussi en flux la découverte/résolution de problème !
Les problèmes sont plus fréquents, plus visibles, plus petits (moins de code), plus maitrisables.

Management de la performance

Le Lean Management, comme d’autres corpus de management insiste sur la pré éminence des métriques, les fameuses « KPI », pour factualiser la performance actuelle et l’écart à l’objectif et ainsi mieux piloter le navire. Gardons aussi à l’esprit la mise en garde de Deming qui nous explique que gérer une entreprise seulement par des métriques fait partie des 7 « maladies du management ».

DevOps insiste sur l’importance des métriques, aussi bien sur le système technique (utilisation des ressources, temps de réponse..) que sur le processus (« Time to Diagnose » d’incidents, Lead Time dev⇒prod etc). Mesurons plus nous disent les top performers du web.

Equipe pluridisciplinaire

Dans l’industrie Toyota a initié les cellules en U dans lesquelles un opérateur est multi compétent, passant d’un poste à l’autre, en suivant la pièce le long de la chaîne (à l’opposé du Charlot mono tâche des Temps Modernes).
En Lean Product Development, Toyota a réduit à l’extrême ses délais de conception, notamment en rapprochant designers, motoristes et ingénieurs responsables de la production en série.
DevOps : des dev plus ops, des ops plus dev, des dev et des ops qui binôment.

Conclusion

Il reste un dernier rapprochement entre devOps et le Lean. Womack et Jones ont inventé le terme « Lean » (« léger », « maigre » en anglais) car il trouvait la méthode japonaise plus légère que ses concurrentes occidentales (par exemple ISO), plus explicable, plus « maniable ». C’est ce même caractère de pragmatisme et d’utilisabilité qui frappe quand on compare DevOps à ITIL. Sur les problématiques communes DevOps/ITIL (notamment gestion des changements, gestion des alertes, capacity planning, amélioration continue…), les intentions sont identiques et les recommandations se recouvrent parfois. N’empêche : dans un cas le corpus de pratique est organique et actionnable, dans l’autre il est complexe et nécessite une expertise et une exhaustivité intimidante.

Redécouvrir et approfondir les principes et pratiques du Lean Management nous permet alors d’apporter des gains substantiels au traitement des problématiques DevOps.

Les gurus de la communauté Lean (par exemple Jez Humble, auteur de Continuous Deployment ou les top performers de Wealthfront ou IMVU) ne s’y sont pas trompés lorsqu’ils basent leurs réflexions DevOps sur des outils du Lean comme le Value Stream Mapping, placent la littérature Lean en bonne place dans leur bibliothèque, ou envisagent les problèmes DevOps avec les mots et les concepts du Lean.

Ces derniers mois, les consultants OCTO ont régulièrement pioché dans la « mallette Lean » afin de rendre encore plus efficaces leurs interventions touchant au domaine DevOps.

En définitive, on redécouvre l’étonnante réponse à la question « qu’est-ce que des techniciens de l’industrie automobile peuvent apprendre aux stars de l’IT ». Beaucoup.

Suggestion d'articles :

1. OCTO accueille le 3ème meetup devops parisien le 16 mars
2. 2ème compte rendu du séminaire « Lean dans les Services »
3. Du Lean Software Development au Lean IT

OCTO accueille le troisième meetup devops parisien, le mercredi 16 mars à 19h.

Au programme, de courtes présentations sur la culture devops (déjà évoqué sur ce blog ici et là), et plus précisémment les méthodologies, process et outils permettant de favoriser la coopération entre études et production.
Il est notamment prévu :

• une introduction orientée organisationnel
• un retour d’expérience sur la mise en place d’un processus de déploiement continue avec les outils Rundeck et Jenkins.

C’est aussi et surtout l’occasion d’échanger avec des gens intéressés par le mouvement : développeurs, exploitants, architectes, testeurs, managers, etc.
Donc venez avec vos sujets, vos questions et vos retours d’expérience, on fera le programme ensemble !

Pensez à vous inscrire et notez bien l’adresse :
OCTO Technology
50 avenue des Champs Elysées (métro Franklin Roosvelt) - 5ème étage

Suggestion d'articles :

1. OCTO accueille le Drupal Meetup le 9 mars : présentation d’un REX sur la réalisation d’une base de connaissances
2. Petit-déjeuner « Agilité et ERP » avec le témoignage de Danone, le 22 mars
3. DevOps : le mouvement qui tend à “Agilifier” votre DSI

Le 15 et 16 Octobre ont eu lieu les DevOpsDays 2010 à Hamburg. Cette conférence est l’occasion de réunir les DevOps désireux d’apprendre des retours d’expérience et surtout d’échanger via des Open Spaces. Si le terme DevOps est nouveau pour vous, je vous conseille de lire cet article d’introduction.

Un an après la première édition en Belgique, et un passage aux quatre coins du globe (US, Australie et Brésil), on peut dire que le mouvement prend de l’ampleur : le retour en Europe fût un réel succès ! Je vous propose ici un résumé de ces deux jours passionnants autour de 4 axes : des outils, des processus et méthodologies, de l’architecture, et enfin la culture et le facteur humain.

Des outils pour automatiser, tester et superviser l’infrastructure

Spike Morelli nous a présenté les concepts de déploiement d’infrastructure mis en œuvre sur Second Life (une dizaine de milliers de machines à exploiter). Il s’est amusé à comparer les fermes de serveurs à des fermes agricoles. Les agriculteurs ont deux problèmes majeurs : les insectes et les mauvaises herbes. Côté IT, les insectes (enfin… les bogues) sont traités à coup de tests et d’intégration continue. Les mauvaises herbes sont tous ces changements qui modifient l’état du système au cours du temps… difficiles à maitriser. Le problème de fond soulevé par Spike est qu’il n’existe aucune couche d’abstraction pour les changements niveau système, ils dépendent directement du système d’exploitation. Pour y remédier, la solution mise en œuvre sur Second Life est de déployer une infrastructure basée sur des images et d’interdire tout changement sur ces images. Ces images sont construites et packagées avec KVM sur la plateforme d’intégration continue à chaque modification de code de l’application. Elles contiennent alors l’application dès sa construction. C’est bien la même image qui est déployée sur les différents environnements : dev, recette, pré-prod et prod. Pour cela, il faut que l’image soit entièrement stateless, la configuration doit donc être stockée en base de données. Plusieurs avantages à cette approche dont une meilleure répétabilité et un renforcement de la collaboration entre études et prod. Quelques difficultés à souligner : beaucoup d’efforts pour rendre les services adaptés à ce type d’infrastructure, plus gros artifacts à télécharger (ce qui pousse à passer à une solution type BitTorrent comme Murder utilisé par Twitter). Par contre, je me demande bien combien de temps prend leur build et combien de téraoctets fait leur référentiel d’artifacts…

Un des sujets souvent abordés lors de la conférence, que ce soit au travers des Talks ou des Open Spaces, est la gestion de la configuration. Une des questions soulevées à plusieurs reprises est : doit-on tout packager (au sens package RPM ou Debian) ? La réponse : ben… ça dépend ! Les Ops y sont évidemment plutôt favorables… De mon point de vue, dans les cas fréquents d’application simple, la valeur ajoutée peut paraître faible comparée à un zip. OK, ça permet d’économiser l’écriture d’un script qui décompresse le zip au bon endroit, change des droits sur des fichiers et exécute d’autres scripts avant et après l’installation. Mais, à l’exception des projets sous Maven qui peuvent automatiser la génération des packages avec rpm-maven-plugin et deb-maven-plugin, il faut bien avouer que l’automatisation du packaging est une tâche complexe pour les Devs. Par contre, si le nombre de composants installés et la compatibilité entre eux deviennent trop complexes, les packages restent la meilleure solution (standard et outillée) pour gérer les dépendances et versionning de packages.

Pour les rares participants comme moi qui ne connaissaient Puppet et Chef que de nom, nous avons eu le plaisir d’assister à quelques démos très intéressantes. Beaucoup de retours d’expérience positifs même si quelques problèmes restent à résoudre, en particulier la testabilité du code utilisant ces technologies. Comment faire pour bouchonner des services externes ? Comment simuler une panne ou une dégradation des temps de latence ? Il n’existe pour le moment rien de très outillé pour répondre à ces problématiques…  Sur le même thème, Nikolay Sturm nous a présenté cucumber-puppet ; un outil permettant de tester les spécifications d’un catalogue Puppet en language naturel. C’est encore en alpha mais l’idée d’uniformiser l’outillage de test (tests fonctionnels et non-fonctionnels en Cucumber) me paraît intéressante et une nouvelle opportunité de favoriser les échanges entre études et production.

Beaucoup d’autres outils ont été mentionnés lors de la conférence, difficile de tous les présenter sur ce post : Vagrant pour créer et gérer des environnements virtuels, AppDynamics pour superviser des applications JEE, Grinder pour tester en charge, etc.

Des processus et méthodologies pour fluidifier les interactions autour du produit

Le Talk d’ouverture proposée par Stephen Nelson-Smith (à l’origine du post What is Devops thing, anyway?) était l’occasion d’apprendre d’un retour d’expérience où Stephen a dirigé l’équipe de production sur le site du gouvernement anglais. Le principal message qui est ressortit de cette présentation est que l’utilisation d’outils comme Puppet renforce l’idée que l’infrastructure est du code. Et pour garantir la stabilité et la fiabilité des plateformes, ce code doit être traité de la même manière que le code de l’application qui y sera déployé, suivant les méthodologies agiles : test driven development, intégration continue, refactoring, pair programming, code review, etc. L’infrastructure doit également se construire de manière incrémentale, en corrélation avec la roadmap du produit en priorisant sur les MMF déclinés sur des besoins d’infrastructure et mettre en place des rituels comme les standup meeting et démonstrations. Bref, autant de bonnes pratiques issues du Dev et sur lesquelles les équipes de production sont encore en phase d’appropriation.

Une autre présentation orienté processus, plus transverse cette fois-ci, était présentée par Jezz Humble (consultant ThoughtWorks). Celle-ci était consacrée au « Continuous Delivery », un processus qui repose essentiellement sur la mise en place d’un « pipeline » de livraison continue d’applications prêtes pour la production. Livrer fréquemment permet d’avoir du feedback rapide, de réduire les risques de déploiement (car plus petits changements) et de voir l’application évoluer progressivement. Jezz a beaucoup insisté sur les pré-requis : intégration continue, check-in sur une branche principale, tout stocker dans le gestionnaire de source, stratégie de tests (Agile Testing Quadrant), automatiser presque tout, etc. En gros, le principe est que chaque build de l’application est une « release candidate » qui traverse les différents sas du « pipeline » (de manière automatisée ou manuelle si une validation est nécessaire pour passer à l’étape suivante à travers de simples « push-button »). Par exemple :

• construction de l’application (compilation, exécution des tests unitaires, packaging, etc.)
• déploiement automatique en environnement de développement
• exécution des tests fonctionnels automatisée
• déploiement automatique en environnement de recette
• exécution des tests manuels (exploratoires, usabilité, etc.)
• déploiement en pré-prod sur « push-button »
• tests de besoins non-fonctionnels (performance, sécurité, etc.)
• déploiement en prod sur « push-button »

Le pipeline est l’épine dorsale du processus permettant de réunir les différentes équipes autour du produit et de modéliser un flux de la construction de l’application jusqu’à sa mise en production. Chaque story est alors considérée comme « DONE » lorsqu’elle est « released ». Les différentes opérations du pipeline doivent être répétables et fiables, donc automatisées (« automation over documentation »). L’objectif ultime de ce processus est de donner plus de contrôle aux testeurs et au marketing afin qu’ils puissent déployer eux-mêmes à tout moment une version sur un environnement ! Si vous êtes intéressé par le sujet je vous recommande son livre, très complet, avec des bonnes pratiques à tous les niveaux (gestion de configuration, intégration continue, stratégie de tests, packaging, déploiement, gestion des dépendances,  infrastructure, base de données, etc.).

Pour finir autour du thème processus et méthodologies, David Anderson a répondu à quelques questions autour d’un « Fishbowl » sur la mise en place de Kanban dans les équipes de production. Contrairement aux études, une des difficultés majeures rencontrée par les équipe de production est d’être souvent dépendants d’acteurs externes : équipe de développement, fournisseurs de service, fournisseur de hardware, etc. Pour cela, David Anderson propose de stocker toutes stories en attente de l’extérieure dans une boite et d’estimer un SLA pour chacune de ces stories, c’est à dire un engagement que peut prendre l’équipe sur la « livraison » de cette story. Celles-ci doivent être revues chaque jour en standup meeting pour suivre leur avancement et lever des alertes en cas de dépassement de SLA. Une autre difficulté rencontrée par la production est de devoir gérer des types de tâches très hétérogènes, plus ou moins longues et plus ou moins critiques. David est revenu sur le principe de classes de services pour améliorer la priorisation des tâches.
Plus tard durant la conférence, nous avons également discuté de la solution optée chez Spotify : le « goalie ». Le principe est simple, chaque semaine un des membres de l’équipe de production est responsable d’intercepter toutes les demandes entrantes et de traiter directement celles qui sont rapides et/ou urgentes pendant que les autres peuvent travailler sur des tâches de plus longue haleine sans interruptions.

De l’architecture pour fédérer les équipes et supporter les livraisons fréquentes

Chris Read et Sam Newman (respectivement de DWR et ThoughtWorks) nous ont fait part de leur retour d’expérience sur un moteur de recherche anglais où ils ont apporté cette culture DevOps pour palier aux problématiques de silotage des équipes projets. L’architecture du site était, comme d’habitude, à l’image de l’organisation, composée de 15 applications ! La conséquence de ces silos : peu de réutilisation de code, peu de cache, déploiements compliqués, peu de monitoring, etc. Les problèmes de performance ont nécessité la refonte du cache web (passage à Squid) ce qui a été l’occasion de réunir tout le monde (dev et ops de chaque projet) autour du produit. C’était le point de départ d’une étroite collaboration entre les équipes, ce qui leur a permis par la suite de fusionner les équipes (et donc les applications) pour ensuite attaquer d’autres problèmes dont la réutilisation de code. La présentation était très axée sur les problèmes de performances causées par le manque de cache. Pour la petite histoire, l’architecture finale du cache est composée de deux machines exécutant deux instances Squid, ce qui leur permet aujourd’hui de tenir 2,8 millions de requêtes par heure en pic, 3000 hits/sec et 1400 misses/sec. J’ai beaucoup aimé le sujet car je suis convaincu que la mise en place de composants d’architecture tels que le cache web nécessite une forte collaboration entre les deux mondes (étude et production). Cette collaboration doit être initiée le plus tôt possible ! Souvent elle intervient en phase d’optimisation, juste avant la mise en production, ce qui est déjà trop tard…

La présentation de Jezz Humble sur « Continuous Delivery » a également été l’occasion d’aborder les quelques concepts d’architecture essentiels pour soutenir un rythme de livraisons élevé. En effet, il est souvent difficile de concilier « check-in fréquent » avec le fait de construire continuellement une application prête pour la production. Le développement d’une fonctionnalité nécessite parfois plusieurs jours de travail, alors comment faire pour que ces développement ne soient pas visibles de l’utilisateur s’il elles ne sont pas « DONE » ? L’utilisation de « feature branch » ou « feature team » implique l’utilisation de branches sur le référentiel de sources, ce qui est contradictoire avec la pratique d’intégration continue. La technique de plus en plus utilisée est de brancher dans le code via l’utilisation de ce qu’on appelle des « feature bits » (ou « feature flags » selon Flickr). Ces « flags » permettent d’activer ou désactiver une fonctionnalité via une configuration stockée en base de données, modifiable au runtime. En gros, il s’agit d’un simple « if » conditionnant l’affichage d’un bouton, d’un menu, d’une partie d’un écran ou d’autres couches techniques s’il s’agit d’un traitement non visible de l’utilisateur mais qu’on ne souhaite pas activer (par exemple : service REST, batch, etc.). La technique de « branch by abstraction » est également intéressante pour effectuer de gros refactoring sur l’application sans pour autant impacter son bon fonctionnement.

Une culture et des Hommes avant tout

Vous l’aurez remarqué, jusqu’ici rien de révolutionnaire : quelques nouveautés technologiques pour automatiser toujours plus et donc améliorer la réactivité face aux nouveaux besoins, un élargissement des principes Agiles au delà des frontière des équipes de développement, des concepts d’architecture pour garantir que l’application est toujours « production ready », etc. Mais dans le fond ces principes sont connus depuis un certain temps maintenant. DevOps est avant tout une culture ! John Willis (évangéliste Chef chez OpsCode, et co-animateur du podcast DevOps Cafe avec Damon Edwards) a d’ailleurs fait une remarquable présentation à ce sujet. Les divers retours d’expérience ont mis en évidence la difficulté de changement culturel, la nécessité de provoquer les rencontres entre études et production, de consacrer plus temps au « team building ». Comme l’a démontré le Talk de Chris Read et Sam Newman, il est fondamental de trouver un point de départ à cette dynamique et obtenir des résultats concrets pour que les équipes prennent conscience des enjeux de la démarche.

Pour introduire cette culture dans les entreprises, il faut aussi et surtout des hommes passionnés désireux de monter en compétence autant sur le plan technique que méthodologique. Pour résumer, un DevOps doit être capable de comprendre les enjeux du produit, faire abstraction des frontières organisationnelles, proposer des solutions transverses aux problèmes de silos, communiquer et être ouvert à la collaboration et la coopération. C’est donc aussi et surtout quelqu’un ayant suffisamment de leadership pour souder les équipes entre elles et forcer les rencontres à travers des points d’avancement réguliers.

Conclusion

Au cours de cette conférence, un constat est apparu comme une évidence pour tous : il est encore difficile de répondre à la question « C’est quoi DevOps ? ». Chacun a sa propre définition et beaucoup d’idées fusent dans tous les sens, ce qui est plutôt positif mais à tendance à brouiller le message originel. De ce constat est né l’idée de rédiger un Manifesto. Jezz Humble a initié un Open Space à ce sujet, le draft est disponible ici. Certains pensent que cette initiative peut créer de la confusion et voient plutôt DevOps comme une évolution du Manifesto Agile. Affaire à suivre…
Pour ma part, peu importe la forme que cela doit prendre, l’essentiel est d’éclaircir le message pour diminuer le FUD et faire comprendre que DevOps est tout sauf une mode ou un mouvement de geeks pour les geeks. Tout l’enjeu est bien d’améliorer les performances des entreprises. Comme le dit Damon Edwards dans le dernier podcast DevOps Cafe : « DevOps is a business problem. ». Aujourd’hui, les quelques entreprises qui l’ont compris prennent de l’avance concurrentielle. Je pense par exemple à Google et Amazon qui sont capables de livrer une nouvelle fonctionnalité en production en quelques semaines seulement. Moi ça me fait rêver… et vous ?

Suggestion d'articles :

1. De retour du Mule Summit Paris 2010
2. OCTO accueille le 3ème meetup devops parisien le 16 mars
3. Le Cloud selon Microsoft, retour de TechEd 2010

Benoît Guillou et Ismaël Héry partageront leur retour d’expériences sur l’utilisation de la méthodologie Kanban le 11 novembre 2010 au Kanban Coach Camp à Stockholm.

Ce retour d’expériences se focalisera sur les principes et pratiques de mise en flux issus du Lean et appliqués aux activités  » amont  » : marketing, conception, usabilité, IHM.

Plus d’information sur le Kanban Coach Camp ici.

Suggestion d'articles :

1. Annonce : Kanban depuis les tranchées à Agile Grenoble 2010
2. Kanban Workshop with David Anderson in Paris
3. Formation Kanban avec David Anderson 27-28 Octobre 2010

Après le succès de la première édition, OCTO et David Anderson renouvellent l’expérience et organisent ensemble une formation Kanban qui se déroulera les 27 & 28 Octobre 2010.

A l’instar d’outils de gestion de flux Toyota et des taskboard agiles, les tableaux Kanban sont une façon simple de mieux maitriser la chaine de création de valeur au sein de votre DSI en appliquant les principes fondamentaux du Lean :
- visualiser la production
- lisser l’activité et mettre en place un flux tiré
- traiter les goulets d’étranglement
- améliorer le système en continue
Pour les participants français, cette formation peut être prise en charge par l’organisme de formation de votre entreprise et dans le cadre du DIF (Droit Individuel à la Formation).
Cette formation est dispensée en Anglais. En voici le contenu.

OCTO and David Anderson are pleased to announce a Kanban workshop on October 27th and 28th.
This intensive 2-day Kanban workshop with the Kanban pioneer provides an introduction to Lean, Pull Systems and Kanban and will explain how established industrial engineering theory can apply to software development process.

Description

Participants in the workshop will learn how to use the simple process of limiting work-in-progress as a driver of change. Kanban is a change management method and a different approach to striking agreements between IT and the business.
You’ll learn how to define the policies that constrain the collaborative game of software development. You’ll learn how to use those policies to manage risk and to reset negotiations and recast them as collaborative problem solving.
Used effectively, Kanban will change you and your organization. If your workplace has been stagnating and you are looking for new ideas to unleash productivity, innovation, collaboration and creativity, take 2 days and come along.

What you will learn ?

• An introduction to Lean, Pull Systems and Kanban
• 4 areas of focus to deliver success
• Value Stream Mapping
• Process Flow Tracking
• Implementing different classes of service
• Implementing a culture of continuous improvement (Kaizen)
• Applying established industrial engineering theory to software development process
• Controlling Work In Progress
• Identifying, classifying and managing bottlenecks
• Defining release and input cadence for a kanban system
• Using Metrics and Reporting to drive continuous improvement
• Establishing policies to prevent abuse and gaming of the kanban system

How you will learn ?

• Case studies
• Work group exercices on real examples
• Sharing experiments with one of the Kanban community leaders

Is this for you ?

If you are a software development executive, project manager, development manager, project lead or developer and you would like to learn how Lean, Pull Systems and Kanban can provide a useful perspective to consider the entire value chain beyond the pure software development, this Kanban workshop is for you!

About the presenter

David has been part of the agile and lean methodology movement since 1997 when he participated in the team that developed Feature Driven Development at United Overseas Bank in Singapore. He has 26 years experience in the software development starting in the computer games business in the early 1980’s. As a pioneer in the agile software movement David has managed teams at Sprint, Motorola and Corbis delivering superior productivity and quality. At Microsoft, in 2005, he developed the MSF for CMMI Process Improvement methodology – the first agile method to provide a comprehensive mapping to the Capability and Maturity Model Integration (CMMI) from the Software Engineering Institute (SEI).

His first book, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, published in 2003 by Prentice Hall, introduced many ideas from Lean and Theory of Constraints in to software engineering. His new book, KANBAN, Successful Evolutionary Change For Your Technology Business, explains why and shows you how to get started using it right now.

David was a founder of the APLN, a not for profit dedicated to promoting better standards of leadership and management in the technology sector.
David is a popular and entertaining conference speaker. He has written or co-authored many articles and papers and is best known for his Agile Management blog. Most recently, David co-authored a Technical Note from the Software Engineering Institute titled, CMMI and Agile: Why not embrace both!

Schedule

Registration: 8:30-9am
Workshop: 9am – 5pm

Location

50, Avenue des Champs-Elysées, Paris, France
Cost
1500€ for the 2 days workshop.

Registration

Please download one of those forms :

• French form – Formulaire Français
• Kanban Class Details

Contact, Information

formation@octo.com

Other Kanban Resources

• Scrum sans itérations
• MMF ou incrément
• Université du Système d’information : Kanban in operations

Kanban external resources

• David Anderson’s web site
• Kanban vs Scrum by Henrik Kniberg
• Kanban Software Engineering website

Suggestion d'articles :

1. Kanban Workshop with David Anderson in Paris
2. Annonce : Retour d’expérience sur « Kanban amont » au Stockholm Kanban Coach Camp
3. Formation TDD le 24 et 25 Octobre