Tag Archives: kanban
Image

Free eBook: Essential Kanban Condensed by David J Anderson and Andy Carmichael

12 Nov
Get the book for free on line

Get the book for free on line

 

Enregistrer

découvrez Prince2 Agile dans cette vidéo

28 Oct


PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».

Partenaire de DantotsuPM

Partenaire de DantotsuPM

PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:

  1. Transparence
  2. Collaboration
  3. Communication
  4. Auto Organisation
  5. Exploration
Partenaire de DantotsuPM

Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Comment gérer le ventre mou de l’IT, les demandes d’évolutions logicielles en mode #Agile ? Par Gaël Gomez

24 Oct
Gaël Gomez

Gaël Gomez

Rétrospective d’Évolutions

Tout a commencé il a environ 3 ans, début 2014, lorsque mon manager a voulu que je prenne en charge le pôle des Évolutions. Je vais tâcher de vous raconter les changements mis en place au sein de ce département qui ont contribué à améliorer la satisfaction clients tout en délivrant de la qualité. Ces évolutions, telles que l’implémentation d’indicateurs, d’un kanban ou encore d’un planning poker, ont clairement  fait progresser la perception utilisateurs et ont su faire évoluer mon mode de fonctionnement aussi côté projets.

Au sein de l’IT dans les entreprises, il y a les projets, la maintenance et le ventre mou, les évolutions. Ces demandes utilisateurs dont on ne sait que faire, pas suffisamment importantes pour les faire passer en projet et où les budgets à allouer, sont toujours plus ou moins compliqués à mettre en place.

Ces demandes ont un coût variable entre un et quarante jours. Elles sont priorisées au sein d’un comité chez LeasePlan France qui a lieu mensuellement. Un représentant de chaque direction vote pour les demandes qu’il qualifie par ordre d’importance. Une moyenne est établie et donne un ordonnancement pour les traiter. A chaque comité sont priorisées dix demandes utilisateurs qui viennent se mettre en backlog du Kanban avec une limite de dix dans le pipe à traiter.

un-seul-kanban

une limite de dix dans le pipe à traiter (colonne la plus à gauche)

En amont de ces comités, j’allais voir chaque utilisateur qui présentait une évolution qui allait être soumise au vote, pour pouvoir y attribuer un chiffrage grossier en fonction du besoin. Ici, le « je » est important car vous allez voir par la suite comment amener l’équipe à s’engager.

Deux questions se posaient, la première, comment rendre plus Lean le process, et la deuxième, comment quantifier la valeur que chaque demande apporte, ou comment apporter de la valeur le plus rapidement possible. En effet, en premier lieu, je me suis rendu compte que passer du temps avec chaque utilisateur en amont du comité était, non une perte de temps, si ce n’est pour ma connaissance personnelle, mais non nécessaire (toutes les demandes n’étant pas priorisées dû à la limite du backlog).

Pour répondre à cette première question et ne pas avoir à chiffrer et analyser des demandes non priorisées, j’ai déporté cette phase d’échange post comité.

Simultanément, j’ai mis en place deux jours avant comité, une revue de chiffrage avec l’équipe dans laquelle toutes les demandes étaient passées en revue pour pouvoir y attribuer un chiffrage moyen établi en consensus. Le tour était joué. Le simple fait de faire participer l’équipe dans l’analyse grossière les stimulait, leur avis étant pris en considération. Qu’y a-t-il de plus essentiel pour une personne que de se sentir importante et impliquée ? Vous y gagnerez en engagement.

L’utilisation du Kanban, insufflé par mon manager et connu de tous, était simple : un backlog, analyse, développement, User Acceptance Testing (UAT) et production. La première pierre était posée.


Après huit mois d’historique, de statistiques et de dérives, deux choses ressortaient. Le chiffrage réel différait du chiffrage initial lors du traitement de la demande et le résultat attendu lors de la mise en UAT amenait souvent des questions ou retours en développement. Force était de constater, on le sait malheureusement, le besoin n’est pas toujours exprimé correctement ou avec les bons mots et même si durant les phases de design nous rencontrons les métiers, nous ne parlons pas toujours le même langage.

Comment quantifier la charge sur une évolution et être sûr de comprendre la même chose que le Métier ?

Deux notions ont été intégrées, une insufflée par mon manager,

  1. les « Efforts » avec la suite de Fibonacci et
  2. la phase dite de « Validation de design » que j’ai introduite.

bonhom-calculatorLa première consiste à mettre un effort sur une demande, de prendre une évolution compréhensible par tous et d’obtenir un consensus en équipe.

Ensuite, les autres demandes qui sont passées en revue sont notées en fonction des précédentes. La note est attribuée en fonction du niveau de complexité, de la qualité rédactionnelle et de la compréhension de chacun tout en gardant à l’esprit la charge plus ou moins importante qu’elle peut représenter. Le but de ces sessions pré comité était de voir, aussi, les grands items qui se dégageaient de chaque évolution, de la pré-découper en tâches car plus les items sont petits, plus la marge d’erreur est réduite et vous pourrez être prédictible concernant la charge réelle.

La deuxième notion consiste à sélectionner une évolution et voir avec le métier, durant la phase de design, si ce qu’il a exprimé correspond réellement à son besoin (phase d’Assistance à Maîtrise d’Ouvrage, AMOA). Cela permet de définir ou redéfinir le design et d’en faire un compte rendu effectué par l’IT, synthèse non technique qui décrit ce qui va être fait lors de la livraison en UAT.

démonstrationPlusieurs objectifs :
  • Délimiter un périmètre qui doit respecter approximativement le besoin initial,
  • Déterminer ce qui ne sera pas fait de ce qui le sera,
  • Démarrer les développements une fois la validation de l’utilisateur reçue,
  • Dématérialiser la phase de design pour une question de traçabilité, de gestion et de négociation (on le sait, une fois livrée en UAT, il manque toujours le petit quelque chose auquel l’équipe projet n’avait pas pensé),
  • Découper en items/user stories, fonctionnelles et/ou techniques,
  • Chiffrer les items,
  • Être prédictible concernant la date de mise en UAT
Les bénéfices de cette phase ont été divers :
  • Faire prendre de la hauteur à certains membres de l’équipe qui ont été capables d’en tirer, profit, être totalement autonome, analyser les process métiers en omettant le technique pour trouver la meilleure solution,
  • Identifier ceux qu’il a fallu accompagner,
  • Livrer en UAT ce qui correspond à la demande utilisateur, sans surprise quelconque et de ce fait, limiter les retours en développement,
  • Développer une satisfaction métier accrue.

Comment déterminer le degré d’efficacité des phases de design et contrôler la qualité des livrables ?

bonhom-thumb-upCertes, le métier était satisfait, mais cela restait une impression, notre perception. Comment pouvait-on la mesurer ? Huit autres mois se sont écoulés et c’est à se moment là que j’ai décidé de nous mettre en risque (mesuré).

Premièrement, nous avons comptabilisé le nombre de retour d’UAT en développement en les catégorisant :
  • Les retours dit « anomalie » causés par l’IT liés aux développements et/ou environnements
  • Les retours dit « cosmétique » qui sont inférieurs à une demi-journée de développement
  • Les retours dit « évolution » qui sont supérieurs à une demi-journée car l’équipe projet (métier-IT) est passée au travers du sujet
Deuxièmement, nous avons comptabilisé le nombre de WFT (Write First Time, évolution livrée en UAT ne nécessitant pas de développement supplémentaire) et le nombre d’anomalies générées liées à nos mises en production.
Enfin, un questionnaire de satisfaction était envoyé à chaque évolution livrée avec une notation sur 10 au « key user » :
  • L’évolution livrée correspond elle à votre besoin ?
  • Êtes-vous satisfait de l’accompagnement en UAT ?
  • Des améliorations vous ont-elles été proposées durant la phase de design ? Si oui, lesquelles ?
deux-kanbansLe fait de cadrer au mieux durant les phases de design, de faire une « démo » utilisateur à la livraison en UAT et d’accompagner le métier nous ont permis d’obtenir ces résultats sur 75 demandes :
  • 85 % des demandes ont été comptabilisées en WFT
  • Plus de 90% des demandes n’ont eu aucun retour d’UAT
  • Moins de 3% des demandes ont générées un bug en production
  • Une moyenne supérieure à 9 concernant les questionnaires de satisfaction
Simultanément, nous avons introduit le planning poker lors des comités :
cards-in-your-hand

planning poker (précédent billet)

Dans les faits, chaque responsable métier attribue à une évolution une note prise sur la suite de Fibonacci et une moyenne est effectuée. En fin de séance, l’IT donne les efforts de chaque demande et le ratio valeur/effort détermine l’ordonnancement des évolutions. Le but étant ici d’apporter la plus grande valeur, le plus tôt possible. Certes, la valeur qu’apporte la livraison d’une évolution est subjective en fonction de chacun, mais cela permet néanmoins de partager les points de vue et soulève des débats.

La vie côté projets après deux années aux Évolutions

En ce début d’année, avril pour être exact, j’ai basculé côté projets et mon manager me disait : « continue à faire ce que tu as fait et ça se fera tout seul». Cela veut dire tellement de choses à la fois lorsque j’y repense.

Un bon manager essayera de vous insuffler des idées. Toutefois, la capacité de chacun à entendre, à se remettre en question, à réfléchir par soi-même ou encore à faire évoluer sa perception des choses ne sont pas donné à tout le monde. C’est ce que vous en faites qui contribuera à votre évolution si vous en avez toutefois l’envie.

J’ai appris à manager une équipe, en tirer le meilleur avec les qualités et défauts de chacun, à obtenir une émulation que je ne soupçonnais pas ou encore à gérer des personnes avec lesquelles je ne m’entendais pas. On ne nait pas fédérateur, on le devient, c’est mon avis.

sharing experienceAujourd’hui, j’ai gardé le meilleur de ces deux dernières années et en ai tiré des leçons.

Nous découpons en équipe un projet pour en obtenir des « items/users stories » les plus petits possibles, et ce, dès la phase de « define » pour engager l’équipe.

Cela permet déjà d’être plus ou moins prédictible quant aux UAT en mettant bout à bout tous les items, de voir les modules indépendants et de les livrer plus tôt, indépendamment de tout le projet.

Le but est d’obtenir des items avec un effort maximum de 5 car mes statistiques me font dire qu’en général, la charge correspond à l’effort multiplié par 1,5. Cela reste approximatif mais a fait ses preuves ces deux dernières années. Au-delà, un item avec effort 8 consommera entre 8 et 20 jours, et un item à 13 entre 20 et 40 jours. Plus l’effort est grand, plus il y a de risques, de points d’attention ou d’incompréhensions.

Chaque item fait office « d’évolution », de ce fait, il est analysé avec le métier avec une phase de validation de design, document une fois réconcilié avec les autres, qui serviront à faire un passage à la maintenance.

Ces trois dernières années m’ont permis d’appréhender des concepts de SOA, d’architecture globalisée, une gestion de fournisseurs ou encore de méthode de management. Il m’a fallu une perpétuelle remise en question et une envie démesurée pour obtenir le meilleur des gens, IT ou non d’ailleurs.

S’il fallait résumer

  • A few videos to get started on Agile, Scrum and Kanban

    A few videos to get started on Agile, Scrum and Kanban

    Le kanban est un outil très utile au management visuel,

  • Les « stand up », s’ils ne sont pas utilisés à outrance, permettent d’avoir un suivi et un partage au sein de l’équipe. Pour ma part, ils se limitent à deux par semaine, voire trois en fonction des jalons, risques et mises en production,
  • Les workshops avec l’équipe permettent d’obtenir un engagement des collaborateurs et une vision partagée pour en tirer la meilleure émulation possible,
  • Les projets doivent être découpés au niveau le plus fin, s’ils le permettent, pour une meilleure visibilité,
  • Le management est un concept difficile s’il est bien fait, car oui, le manager paternaliste est mort !

En espérant que cela puisse vous servir ou vous inspirer…

Gaël Gomez, Chef de projet informatique au sein de LeasePlan France

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

29-30 Novembre – Paris – LeanKanban France

9 Oct

Des sessions à ne pas manquer: Personal Kanban, Mon 1er Kanban, Kanban policy game…

Avec Jim Benson, Monsieur Personal Kanban « en personne » !!

personal kanbanfor1 board

Pour les débutants: Mon premier Kanban en 10 leçons ! avec Stéphane Wojewoda

kanbanPour les expertsKANBAN POLICY GAME avec Dimitar Bakardzhiev

The Kanban Policy Game is a fun way to experience how policies affect productivity i.e. number of work items produced per unit time. The game has rules and policies. Rules are fixed and cannot be changed. Policies are changeable and that’s the main idea!

Et près de 30 autres orateurs, Français et internationaux.

Détails et inscriptions

14 Septembre – Montréal (#PMI ®) – #Kanban – La seule méthodologie quantitative de gestion de projet Agile

30 Août

Pourquoi adoptent-ils Lean Kanban partout ? Propos chocs !

A few videos to get started on Agile, Scrum and Kanban

A few videos to get started on Agile, Scrum and Kanban

Première Matinée de l’automne du PMI® Montréal!

Lean Kanban est le chemin alternatif à l’agilité et la seule méthode qui peut vous aider à atteindre le niveau 5 de CMMI. Fondée sur la science, Kanban est une méthode sans méthodologie, à double boucle, aidant l’entreprise à gérer sa gestion évolutive du changement.  Elle offre des résultats prévisibles qui bâtissent et maintiennent un haut climat de confiance.

Cette présentation au contenu avancé vous tiendra en haleine. Tout d’abord nous distinguerons Lean et Agile au niveau des filtres de prise de décision propres à chacun. À partir de ces filtres de décision, nous verrons comment l’autre et l’un traitent des coûts de transaction, des coûts de coordination et des coûts de correction. Puis nous plongerons très profondément dans les différences philosophiques qui distinguent les deux courants sur la valeur du respect et certains concepts afférents à la fragilité des équipes !

Kano chartEnsuite, nous verrons plusieurs optiques favorisant et supportant la pertinence de Lean Kanban comme une approche supérieure. Également, nous ferons un parallèle avec la valeur Agile de ‘confiance’ et confronterons ce paradigme avec l’efficacité Lean Kanban et l’efficience Agile; tout ça sous les rayons éclairants d’une variation du modèle KANO.

D’autres sujets avancés seront abordés : l’antidote Kanban à la résistance au changement faisant de cette méthode une approche humaine, la tyrannie du timeboxing, les valeurs sociales de Kanban, le dogmatisme, etc.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

Saviez-vous que 3 des termes de PRINCE2 sont agiles ?

23 Août

En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet.

http://www.alctraining.com.au/4-prince2-terms-you-may-not-know-are-agile/ par ALC Group

Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.

3 termes Agile Prince2En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Premier terme Agile – Initiation

A few videos to get started on Agile, Scrum and Kanban

A few videos to get started on Agile, Scrum and Kanban

Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.

Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.

De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.

Second terme Agile – Work package (Lot de travail)

Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des  frontières comprises et communicables.

Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.

Troisième terme Agile – Tolérance

prioriser2Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.

Produit Viable Minimum (MVP)

Produit Viable Minimum (MVP)

La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.

Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.

Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

14-15 Octobre – Rennes – Agile Tour

17 Août

La billetterie vient d’ouvrir, profitez des tarifs early-birds jusqu’au 15 août !

Inscriptions et détails

Inscriptions et détails

Agile tour Rennes est un événement « #notheme as a theme » afin de vous laisser l’opportunité de développer votre créativité au travers des conférences ou des ateliers que vous proposez.

Du coup nous avons déjà une belle richesse de thèmes abordés

Transformation Kanban ManagementPensée positiveSAFe SoftWareCraftsmanship Lean StartupLeadership Collaboration Communication Non ViolenteAgilité côté persoFacilitation graphique

Nous sommes toujours en recherche de diversité, voici une liste des sujets sur lesquels nous aimerions avoir des propositions

Open InnovationCulture collaborativePédagogie et AgilitéAméliorer les interactionsEthnologieHistoire de l'agilitéPartage de connaissanceÉtude de psycho-sociologieEntreprise libéréeRetours aux basiquesAteliers pratiques (backlog, user story et tests)Retours aux pratiques de développement

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Et encore une fois, ne nous limitons pas…

Merci par avance pour vos propositions de conférences inspirantes et pour vos retours d’expériences qui viendront alimenter les réflexions de tous les acteurs Rennais.

Enregistrer

Enregistrer

Enregistrer

30 Juin – Laval (France) – 4ème conférence Agile

8 Juin

L’agilité avec l’ensemble de ses valeurs, de ses principes, de ses méthodes et pratiques, se diffuse progressivement dans nos environnements de travail et dans l’enseignement.

détails, programme, inscription...

détails, programme, inscription…

La 4ème édition de la conférence AgileLaval 2016 sera encore cette année l’évènement agile incontournable de la région. C’est le rendez-vous pour tous les professionnels, les enseignants et les étudiants qui souhaiteraient savoir comment s’y prendre, découvrir, échanger, apprendre, expérimenter, tester, approfondir leurs connaissances, ou simplement discuter autour de l’agilité.

Novices ou experts, curieux ou praticiens, venez donc partager et échanger sur des thématiques agiles telles que le Management Agile, la programmation agile, le Lean IT, Lean Startup, Scrum, Kanban, eXtreme Programming … ou encore l’enseignement en mode Agile.

Renseignements et inscription gratuite ici.

16-17 Juin – Paris – Agile France 2016

28 Mai

Découvrir, échanger et s’améliorer entre praticiens

Réservez votre place au plus vite !

Au programme cette année, voici quelques-unes des session prévues :

La grande conférence agile francophone, de la communauté pour la communauté

Agile France est une conférence qui offre un espace de respiration et d’oxygénation de nos pratiques, dans l’ambition de faire progresser la communauté sans être élitiste.

  • On y parle de méthodes agiles…
  • On y parle d’intelligence collective et de facilitation…
  • On y parle de motivation, d’émotions et de bien-être au travail…
  • On y parle de développement de logiciels, de technique, d’artisanat…
  • On y parle de produit, d’expérience utilisateur et d’innovation…
  • On y parle d’organisations, de gouvernance et de management…

…mais pas seulement. On y parle de soi, de ses expériences, de ses échecs, de ses idées. Et on ne parle pas de business.

Scrum… Vraiment

13 Avr

agile-on-the-beachScrum… Really

http://www.scrumexpert.com/videos/scrum-really par Amy Thompson à Agile on the Beach 2015

Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.

Amy Thompson

Amy Thompson

Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?

J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.

L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)

%d blogueurs aiment cette page :